Archive for the ‘Frameworks’ Category

« Older Entries

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% [?]

read more 20 comments

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

PLAIN TEXT
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

PLAIN TEXT
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

PLAIN TEXT
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.

PLAIN TEXT
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% [?]

read more 9 comments

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

PLAIN TEXT
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:
PLAIN TEXT
XML:
  1. <!-- estado service -->
  2.     <mx:RemoteObject id="estadoService"
  3.                      destination="EstadoService"
  4.                      channelSet="{myAmfChannel}"/>

Então quando fazemos isso:

PLAIN TEXT
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

PLAIN TEXT
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% [?]

read more 2 comments

TUTORIAL JAVA + FLEX NA PRÁTICA 3/6

maio 15th, 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

Na terceira a sexta(Final) parte do nosso tutorial vamos ser mais detalhado, explicando um pouco mais o que vamos fazer, até mesmo que o obejtivo principal do tutorial é daqui para frente.

Antes de mais nada crie mais um projeto chamado CrudFlex(Flex Project), este nosso projeto todo codificado vai ficar assim:

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


FRONTEND – FLEX BUILDER 3 + MVC COM SWIZ FRAMEWORK

Sobre o Adobe Flex nem preciso falar muita coisa já que a quantidade de material é satisfatória, só vale ressaltar que o beta do Flex 4 (Gumbo) já saiu mais neste projeto não atualizei, ok!

SWIZ FRAMEWORK

Esse é o principal motivo deste tutorial, mostrar para vocês um bom MVC para se utilizar em Adobe Flex, de uma linha de aprendizado rápido principalmente para quem vem do Java e está acostumado com o Spring Framework(IOC)

No Site oficial já se tem uma pequena demostração muito útil para entender como funciona o Swiz Framework (daqui pra frente o swiz).

Vamos ao que interessa, vamos a prática. ;)

CONFIGURANDO O SWIZ FRAMEWORK

Antes de mais nada vamos fazer o download do swiz-x.x.x-data.swc (quando fiz este tutorial o arquivo era swiz-0.0.5-010609.swc). Depois de feito o download vamos colocar o nosso swiz.swc no pasta lib do nosso projeto CrudFlex.

Como disse inicialmente uma das grandes vantagens do Swiz é a similaridade com o Spring Framework, na configuração não poderia ser diferente, o conceito é baseada em cima de Beans, que vai mapear onde fica nossos services, delegates, controllers. Etc...

Vejamos o código do nosso Beans.mxml que fica na pasta raíz (src) do nosso projeto flex:

Beans.mxml

PLAIN TEXT
XML:
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <beanLoader xmlns="org.swizframework.util.*"
  3.             xmlns:mx="http://www.adobe.com/2006/mxml"
  4.             xmlns:controllers="com.saberprogramar.controllers.*"
  5.             xmlns:delegates="com.saberprogramar.models.delegates.*">
  6.  
  7.     <!-- custom channel set, because I am not compiling against services.xml -->
  8.     <dynamicChannelSet id="myAmfChannel">
  9.         <serverPort>8080</serverPort>
  10.         <contextRoot>/CrudJava</contextRoot>
  11.     </dynamicChannelSet>
  12.  
  13.     <!-- estado service -->
  14.     <mx:RemoteObject id="estadoService"
  15.                      destination="EstadoService"
  16.                      channelSet="{myAmfChannel}"/>
  17.  
  18.     <!-- delegate for the estado controller -->
  19.     <delegates:EstadoDelegate id="estadoDelegate"/>
  20.  
  21.     <!-- estado controller -->
  22.     <controllers:EstadoController id="estadoController"/>
  23.  
  24. </beanLoader>

Vamos explicar:

BeansLoader – ao criar nosso arquivo e declará-lo como BeansLoader estamos dizendo para o Swiz que é aqui que fica o mapeamento dos nossos componentes, neste caso os seguintes componentes:

DynamicChannelSet – é onde vamos mapear o nosso projeto feito em Java informando o nome do projeto (CrudJava) e a porta onde está instalado o Web Container ou Application Server (no meu caso Tomcat – porta 8080) .

RemoteObject – aqui vamos informar algumas propriedades como
id - o nome que vamos referenciar dentro do nosso projeto flex os services ; destination - que é o id que colocamos no arquivo remoting-config.xml dentro do nosso projeto Java, para lembrar:

PLAIN TEXT
XML:
  1. <destination id="EstadoService">
  2.         <properties>
  3.             <factory>spring</factory>
  4.             <source>EstadoService</source>
  5.         </properties>
  6.     </destination>

E também informamos o nosso channelSet, neste caso o id do nosso DynamicChannelSet

Delagates e Controllers– onde vamos mapear as classes que ainda vamos criar na próxima Parte deste Tutorial ( não vamos entrar em detalhes agora ).

Feito isso vamos informar para nossa aplicação que existe um BeanLoader do swiz, só colocar na nossa aplicação principal CrudFlex.mxml ou no meu caso que renomeei para índex.mxml, o código vai ficar assim:

Índex.mxml

PLAIN TEXT
XML:
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
  3.     preinitialize="{iniciar(event)}">
  4.  
  5.     <mx:Script>
  6.         <![CDATA[
  7.             import org.swizframework.Swiz;
  8.             import mx.events.FlexEvent;
  9.  
  10.             private function iniciar(event:FlexEvent):void{
  11.                 Swiz.setStrict(false).loadBeans( [Beans] );
  12.  
  13.             }
  14.  
  15.  
  16.         ]]>
  17.     </mx:Script>
  18.  
  19. </mx:Application>

E por último no que diz respeito a configuração mais não menos importante vamos ter que adicionar no compiler do nosso projeto a configuração necessária para que futuramente as anotações do swiz possam ser ouvidas pelo nosso projeto Flex (sendo que testei sem esta configuração e também funcionou)

Botão direito do mouse no projeto CrudFlex – properties – Flex Compiler, e no campo onde se encontra o valor

-locale en_US

colocar

-locale en_US -keep-as3-metadata+=Autowire.

Bem é isso, na próxima vamos codificar o M(Models) do nosso MVC.

Vlw e até a próxima.

Popularity: 61% [?]

read more 5 comments
« Older Entries