Archive for the ‘Spring’ Category

TUTORIAL JAVA + FLEX NA PRÁTICA 7/6 – Bônus

julho 20th, 2009, posted in #JAVA + FLEX NA PRÁTICA, Adobe Flex, Blazeds, Hibernate, Java, MVC, Spring, Swiz Framework

Esse artigo é continuação do
TUTORIAL JAVA + FLEX NA PRÁTICA 1/6
TUTORIAL JAVA + FLEX NA PRÁTICA 2/6
TUTORIAL JAVA + FLEX NA PRÁTICA 3/6
TUTORIAL JAVA + FLEX NA PRÁTICA 4/6
TUTORIAL JAVA + FLEX NA PRÁTICA 5/6
TUTORIAL JAVA + FLEX NA PRÁTICA 6/6

Não definitivamente você não está delirando e nem eu esqueci conceitos simples da matemática, realmente criei mais um tutorial, a 7/6, o que estou considerando Bônus, para fazer algumas modificações e implementar algumas funcionalidades.

Antes gostaria de agradecer pela participação do pessoal, muitos entenderam o objetivo do tutorial e com certeza fizeram bom proveito, fiquei sabendo este mês de julho que alguns mudaram a forma de trabalhar com Java + flex através deste tutorial :P . Através do mesmo recebi ótimos contatos e oportunidades profissionais, porém, como sempre há alguém que quer mais e gostaria de mais um empurram, então vamos direto ao assunto que tempo é dinheiro.

Essa parte vamos tratar mais de relacionamentos entre tabelas, como tratar esses relacionamentos no Flex e como mostrar mais de um objeto no datagrid… vamos a prática.

Popularity: 48% [?]

TUTORIAL JAVA + FLEX NA PRÁTICA 6/6

maio 28th, 2009, posted in #JAVA + FLEX NA PRÁTICA, Adobe Flex, Blazeds, Data Service, Frameworks, Hibernate, Java, MVC, Spring, Swiz Framework

Esse artigo é continuação do
TUTORIAL JAVA + FLEX NA PRÁTICA 1/6
TUTORIAL JAVA + FLEX NA PRÁTICA 2/6
TUTORIAL JAVA + FLEX NA PRÁTICA 3/6
TUTORIAL JAVA + FLEX NA PRÁTICA 4/6
TUTORIAL JAVA + FLEX NA PRÁTICA 5/6

Na última parte do nosso tutorial vamos fazer a V(View) do nosso MVC, no caso são 2 tipos de arquivo, a interface em si e a Ação da mesma, lembrando que essa separação não é necessária, eu faço porque gosto de tudo bem dividido, isso ajuda e muito na manutenção ou até mesmo na alteração do Layout, uma vez eu já expliquei o porque disso no artigo Separando MXML do Action Script.

Para terminar com chave de ouro vamos ao código:

Popularity: 46% [?]

TUTORIAL JAVA + FLEX NA PRÁTICA 5/6

maio 25th, 2009, posted in #JAVA + FLEX NA PRÁTICA, Adobe Flex, Blazeds, Data Service, Frameworks, Hibernate, Java, MVC, Spring, Swiz Framework

Esse artigo é continuação do
TUTORIAL JAVA + FLEX NA PRÁTICA 1/6
TUTORIAL JAVA + FLEX NA PRÁTICA 2/6
TUTORIAL JAVA + FLEX NA PRÁTICA 3/6
TUTORIAL JAVA + FLEX NA PRÁTICA 4/6

Como tenho feito nos outros artigos que fazem parte deste tutorial vou colocar o projeto para vocês não se perderem

package crudFlex TUTORIAL JAVA + FLEX NA PRÁTICA 5/6

EVENTS

Eventos é forma que encontramos de criar uma comunicação entre Objetos que não tem ou não podem se comunicar de uma forma direta. Algumas coisas são muito bonito falar porém é muito Simples fazer, um exemplo típico são os eventos customizados em flex, como o tutorial é NA PRÁTICA vamos ao código:

EstadoEvent.as

ACTIONSCRIPT:
  1. package com.saberprogramar.events
  2. {
  3.     import flash.events.Event;
  4.  
  5.     public class EstadoEvent extends Event
  6.     {
  7.  
  8.         public static const SAVE:String = "saveEstado";
  9.         public static const REMOVE:String = "removeEstado";
  10.  
  11.  
  12.         public function EstadoEvent(type:String)
  13.         {
  14.             super(type);
  15.         }
  16.  
  17.  
  18.     }
  19. }

Os eventos são muito utilizados no Flex e recomendo por todos que procuram um código limpo, como você consegue perceber declaro variáveis Static com o nome de "SAVE" e "REMOVE", neste caso representa os métodos que será necessário disparar eventos, a necessidade de ter esses eventos no nosso caso de um MVC é que a Controller ele não pode mudar um status na view, isso é responsabilidade da própria view, por isso a necessidade de ter eventos. A view fica a escuta deste evento, então quando a controller dispara esse evento a própria view muda o seu status.

Para criar um evento customizado é só criar uma sub-classe da Classe "Event", na construtora da nossa classe recebemos como parâmetro uma String, que no caso é uma das nossas variáveis que declaramos como static na mesma classe (Mais a frente você verá a utilização da nossa classe e vai entender mais).

CONTROLLER

Agora vamos falar da C(Controller) do nosso MVC, essa parte é a melhor de todas, Aliás é a parte da implementação do MVC mais importante.

A Controller recebe requisições da View e passa para Model e o mesmo acontece no sentido contrário, além disso a Controller dispara os eventos que acabamos de criar no ínicio deste tutorial.

Se você analisar a figura acima vai perceber que existem duas classes na nossa Controller uma interface e a implementação da mesma, vamos ao código:

IEstadoController.as

ACTIONSCRIPT:
  1. package com.saberprogramar.controllers
  2. {
  3.     import com.saberprogramar.models.entitys.Estado;
  4.  
  5.     import mx.collections.ArrayCollection;
  6.  
  7.     public interface IEstadoController
  8.     {
  9.  
  10.         function get estadoList():ArrayCollection;
  11.  
  12.         function findAll():void;
  13.  
  14.         function findByName(nome:String):void;
  15.  
  16.         function save(estado:Estado):void;
  17.  
  18.         function remove(estado:Estado):void;
  19.  
  20.     }
  21. }

Uma simples interface sem muitas explicações que é implementada pela:

EstadoController.as

ACTIONSCRIPT:
  1. package com.saberprogramar.controllers
  2. {
  3.     import com.saberprogramar.events.EstadoEvent;
  4.     import com.saberprogramar.models.delegates.EstadoDelegate;
  5.     import com.saberprogramar.models.entitys.Estado;
  6.  
  7.     import mx.collections.ArrayCollection;
  8.     import mx.controls.Alert;
  9.     import mx.rpc.events.FaultEvent;
  10.     import mx.rpc.events.ResultEvent;
  11.  
  12.     import org.swizframework.Swiz;
  13.     import org.swizframework.controller.AbstractController;
  14.  
  15.     public class EstadoController extends AbstractController
  16.         implements IEstadoController{
  17.  
  18.         [Bindable]
  19.         public var estadoList:ArrayCollection;
  20.  
  21.         [Autowire(bean="estadoDelegate")]
  22.         public var estadoDelegate:EstadoDelegate;
  23.  
  24.         public function EstadoController()
  25.         {
  26.             super();
  27.         }
  28.  
  29.         public function findAll():void{
  30.             executeServiceCall(estadoDelegate.findAll(),onFindAll,onError);
  31.         }
  32.  
  33.         public function findByName(nome:String):void{
  34.             executeServiceCall(estadoDelegate.findByName(nome),onFindByName,onError);
  35.         }
  36.  
  37.         public function save(estado:Estado):void{
  38.             executeServiceCall(estadoDelegate.save(estado),onSave,onError);
  39.         }
  40.  
  41.         public function remove(estado:Estado):void{
  42.             executeServiceCall(estadoDelegate.remove(estado),onRemove,onError);
  43.         }
  44.  
  45.         //*************** Handle Results ************************//
  46.  
  47.         public function onFindAll(event:ResultEvent):void{
  48.             estadoList = ArrayCollection(event.result);
  49.         }
  50.  
  51.         public function onFindByName(event:ResultEvent):void{
  52.             estadoList = event.result as ArrayCollection;
  53.         }
  54.  
  55.         public function onSave(event:ResultEvent):void{
  56.             Swiz.dispatchEvent(new EstadoEvent(EstadoEvent.SAVE));
  57.         }
  58.  
  59.         public function onRemove(event:ResultEvent):void{
  60.             Swiz.dispatchEvent(new EstadoEvent(EstadoEvent.REMOVE));
  61.         }
  62.  
  63.         private function onError(event:FaultEvent):void{
  64.             Alert.show(event.fault.message,"ERROR");
  65.         }
  66.  
  67.  
  68.  
  69.  
  70.     }
  71. }

Vamos a algumas explicações:

AbastractController -> uma classe que faz parte do Framework Swiz, ao estendermos esta classe além de ter a mesma funcionalidade que ganhamos no caso do Delegate podemos usar um método que facilita e muito a forma de tratar as funções, o método executeServiceCall.

executeServiceCall - > recebe como parâmetro um método, o nossa função que vai receber o retorno em caso de sucesso e a nossa função que vai receber o retorno no caso de algum erro.

Na linha abaixo adicionamos uma escuta para nosso bean criado no Bean.mxml chamado de estadoDelegate que mapea e instancia a nossa classe já criada e explicada EstadoDelegate.

ACTIONSCRIPT:
  1. [Autowire(bean="estadoDelegate")]
  2. public var estadoDelegate:EstadoDelegate;



//*************** Handle Results ************************//


Desta linha para baixo estão todas as nossas funções que trata o retorno que vem do nosso Delegate, pode perceber no caso onSave e OnRemove eu disparo o Nosso Evento Criado no ínicio deste artigo pelo framework Swiz e não pelo dispatchEvent do SDK padrão do Flex(Flash), esse disparo de Evento é necessário para que a view saiba que ocorreu tudo certo e mude o seu “status” atual.

OK, na próxima parte vamos mostrar a View feita em Flex, a view que vai ser responsável por “consumir”(se comunicar) com o nosso Controller.

Espero o feedback de vocês galera, se está bom, ruim, péssimo. Podem ficar a vontade para comentar no blog e se gostarem divulgar, o intuito é ajudar quem quer usar um MVC no Flex, espero está ajudando alguém ;)

Vlw e até a próx.

Popularity: 36% [?]

TUTORIAL JAVA + FLEX NA PRÁTICA 4/6

maio 18th, 2009, posted in #JAVA + FLEX NA PRÁTICA, Blazeds, Data Service, Frameworks, Hibernate, Java, MVC, Spring, Swiz Framework

Esse artigo é continuação do
TUTORIAL JAVA + FLEX NA PRÁTICA 1/6
TUTORIAL JAVA + FLEX NA PRÁTICA 2/6
TUTORIAL JAVA + FLEX NA PRÁTICA 3/6

Vamos falar hoje do M(Models) do nosso MVC , MVC este que fica dentro da camada de apresentação do nosso projeto.

Algo que traz muita confusão é o conceito de MVC, muitos ainda confundem o conceito de MVC com Programação em camadas... perceba bem... neste exemplo que estou colocando o código aqui eu programo em multi-camadas(4 para ser mais exato) camada de Dados, infraestrutura, Business(JAVA) e Apresentação(FLEX), neste caso o MVC fica alocado na camada de Apresentação... acho que o grande complicador é que na faculdade se ensina MVC sem camadas, então o MVC acaba que concidindo de por exemplo Models está junto com a Dao... um dia destes falei sobre MVC aqui no blog... MVC da teoria para a prática.

Vamos ao que interessa, No nosso Model como podem perceber na arquitetura abaixo comtém duas pastas, uma o delegates e outra a entitys.

package crudFlex TUTORIAL JAVA + FLEX NA PRÁTICA 4/6

Vamos ao código e logo abaixa a explicação:

EstadoDelegate.as

ACTIONSCRIPT:
  1. import com.saberprogramar.models.entitys.Estado;
  2.  
  3.     import mx.rpc.AsyncToken;
  4.     import mx.rpc.Responder;
  5.     import mx.rpc.events.FaultEvent;
  6.     import mx.rpc.remoting.RemoteObject;
  7.  
  8.     import org.swizframework.delegate.AbstractDelegate;
  9.  
  10.     public class EstadoDelegate extends AbstractDelegate
  11.     {
  12.  
  13.         [Autowire(bean="estadoService")]
  14.         public var estadoService:RemoteObject;
  15.  
  16.         public function EstadoDelegate()
  17.         {
  18.             super();
  19.         }
  20.  
  21.  
  22.         //AS OPERAÇÕES CRUD
  23.         public function findAll():AsyncToken{
  24.             return estadoService.findAll();
  25.         }
  26.  
  27.         public function findByName(nome:String):AsyncToken{
  28.             return estadoService.findByName(nome);
  29.         }
  30.  
  31.         public function save(estado:Estado):AsyncToken{
  32.             return estadoService.save(estado);
  33.         }
  34.  
  35.         public function remove(estado:Estado):AsyncToken{
  36.             return estadoService.remove(estado);
  37.         }
  38.  
  39.  
  40.     }

Na classe acima temos muito o que entender:

  • primeiro é que ela extende uma classe AbstractDelegate, classe esta pertencente ao framework Swiz, quando for feito uma escuta (Autowire) no nosso delegate essa super classe(classe "Pai") é responsável por instanciar nossa classe (humm! Se não entendeu mais a frente vamos entender);
  • Algo a se comentar também é que esta classe faz uma escuta (Autowire) ao Nosso serviço externo mapeado no nosso BeansLoader, não Lembra:
XML:
  1. <!-- estado service -->
  2.     <mx:RemoteObject id="estadoService"
  3.                      destination="EstadoService"
  4.                      channelSet="{myAmfChannel}"/>

Então quando fazemos isso:

ACTIONSCRIPT:
  1. [Autowire(bean="estadoService")]
  2.         public var estadoService:RemoteObject;

a mágica acima explicada ocorre ;)

Perceba que declaramos um RemoteObject porém não intanciamos em momento algum, é reposnabilidade da nossa escuta (Autowire ) ir no nosso BeansLoader ,procurar um bean como o nome solicitado, no caso o “estadoService” e instanciá-lo, o que chamamos de Injeção de Dependência (IOC), essa é a tal similaridade entre o Swiz e Spring, o fácil uso de IOC usando anotações (@... no java e [...] no ActionScript).E por último perceba que toda função no nosso delegate espera como retorno um AsyncToken, isso porque um RemoteObejct sempre retorna um AsyncToken.

  • E por último toda função do nosso delegate espera como retorno um AsyncToken, isso porque um RemoteObejct sempre retorna um AsyncToken.

Além do nosso delegate temos também a nossa Entity, que funciona como um clone do nosso entity feito no java:

Estado.as

ACTIONSCRIPT:
  1. [RemoteClass(alias="com.saberprogramar.business.entitys.Estado")]
  2.     [Bindable]
  3.     public class Estado
  4.     {
  5.  
  6.         public var idEstado:Number;
  7.         public var nome:String;
  8.         public var uf:String;
  9.  
  10.     }

Para quem leu o artigo do Rodrigo Fraga como mencionado na 1 parte do Tutorial não precisa de nenhuma explicação sobre as entitys.

Só abro aqui um parênteses porque muitos ainda confundem e aqui chamariam a nossa Entity de VO ou DTO, vamos refletir a tradução de VO (ValueObjects) já diz tudo, classes para serem qualificadas como VO tem que ser classes que não possuem uma entidade, ou seja, o Estado é único, podem até existir vários Rio de Janeiro, porém o Rio de Janeiro que possui um entidade ( algumas características que provam que ele é único tipo "favela"(esse todos tem rs), Cristo Redentor, Copacapana só o Rio tem) no mundo da programação “normalmente” o que qualifica uma entidade são os ID (AutoIncrement), vamos a um exemplo de uma vez por todas para parar com esta palhaçada de chamar Entidades de VO ou DTO, você quer saber onde tem praia por perto, aí sim você pode ter uma PraiaVO, um obejto que retorne para você as praias, não interessa qual, é um objeto de valor, que “normalmente” serve apenas como consulta, sem tabelas no banco de dados, sem função para salvar, atualizar, apenas uma consulta de n Objetos que resulta na formação de um objeto com tempo de vida curto.

Bem é isso na próxima parte e provavelmente a penúltima vou falar de controllers, Events, por útimo deixarei a view.

Até a próx.

Popularity: 34% [?]