BlazeDS é uma aplicação Java opensource mantida pela Adobe, sob licensa GNU Lesser General Public License, Version 3 (LGPL v3), que fornece um conjunto de serviços, todos sobre o protocolo HTTP(Hyper Text Transfer Protocol), para permitir uma aplicação Flex fazer chamadas a serviços remotos Java, retornando os dados tanto de forma assíncrona como em tempo real.
Por utilizar o formato de dados binário chamado AMF(Action Message Format) para a serialiazação e deserialização de dados, a comunicação entre uma aplicação Flex e o servidor Web se torna muito otimizada. Existem estudos feitos comparando as diversas tecnologias, como o Jamesward, mostrando o potencial do AMF.
Outra grande vantagem quando usamos o BlazeDS é a facilidade de ter classe Java automaticamente convertida para uma classe ActionScript e vice-versa.
O BlazeDS pode ser baixado do site da Adobe em dois formatos:
Turnkey – Versão que já vem com exemplos e servidor tomcat pré configurado
Entendendo os arquivos de configuração do BlazeDS
A estrutura de arquivos do BlazeDS é bem simples, quando descompactamos o blazeds.war, presente na versão binária, podemos ver a seguinte estrutura:
Devemos nos atentar a duas pastas. A pasta lib, que contém todos os jars necessários, e a pasta flex, que contém todos os arquivos de configuração do BlazeDS. Vamos ver o que cada arquivo significa:
services-config.xml: É neste arquivo que estão as principais configurações do BlazeDS como segurança, logging, serviços disponíveis (Canais), fábricas para a integração com Frameworks Java como Spring e EJB3 e as referências para os outros três arquivos de configuração.
remoting-config.xml: É nesse arquivo que iremos configurar os serviços Java para serem “consumidos” pela aplicação Flex. Sempre quando configuramos este arquivo, iremos trabalhar com o componente Flex chamado RemoteObject.
message-config.xml: Aqui é configurado tudo o que for relacionado com mensageria, sempre necessário quando trabalhamos com os componentes Flex Consumer e Producer. Um exemplo da utilização desta tecnologia seria fazer um bate bapo, ou até mesmo aplicações colaborativas, onde é desejável a iteração simultânea de diversos usuários.
proxy-config.xml: Além da possibilidade de utilizarmos o componente RemoteObject, o Flex disponibiliza mais duas formas de integração: O HTTPService e o WebService. Porém, por questões de segurança, os serviços só podem ser chamados quando os mesmos estão no mesmo domínio que a aplicação, ou que exista uma configuração específica que permita um cliente Flex fazer a consulta (esta configuração é feita por um arquivo chamado crossdomain.xml e está sempre no servidor onde está o serviço chamado). Caso uma das duas condições acima não seja satisfeita, deveremos utilizar o BlazeDS como proxy , e é ai que configuração deste arquivo se torna necessário.
Feito os downloads e a instalação do Eclipse e FlashBuilder, vamos iniciar o FlashBuilder para criar o projeto.
Antes de criar o projeto, vamos configurar o Tomcat:
Nas preferências do Eclipse, vá em Server — Runtime Environments e clique em Add…
Na pasta Apache selecione Apache Tomcat v6.0 e clique em Next
Selecione a pasta onde você descompactou o Tomcat e clique em Finish
Feito a configuração do Tomcat, vamos criar o projeto:
Vá em File – New – Flex Project
Preencha os dados do primeiro passo como na imagem abaixo e clique em Next
Neste passo vamos configurar os dados do servidor. Deixe tudo configurado como na imagem e clique em Next
Para selecionar o “Target Runtime”, clique em New e depois escolha o Apache Tomcat 6, como na imagem abaixo.
No último passo não será necessário mudar nada, clique em Finish
Agora vamos criar a classe Java que terá o serviço para retornar a string “HelloBlazeDS”
Crie uma classe Java br.com.dclick.service.RemotingService
Agora vamos configurar o BlazeDS para disponibilizar o serviço que acabamos de criar.
Abra o arquivo remoting-config.xml que está na pasta WebContent/WEB-INF/flex
Para que seja possível chamar os métodos da classe Java, precisamos configurar um destination. Isso é necessário para cada classe Java.
O arquivo fica assim:
Durante o ando de 2010 diversos leitores me escreveram solicitando alguma forma de “receita de bolo” para a criação de projetos em Flex. Estavam buscando uma maneira de criar uma aplicação de forma que fosse mais correta e mais fácil, baseada em padrões de projeto e definida através de uma estrutura que facilitasse o desenvolvimento.
No início de 2011 comecei a pensar mais no assunto, pois irei implementar estas regras nos próximos livros, chegando a uma série de “regras” das quais estarei apresentando neste artigo. Inicialmente, queria dizer que eu não sou o dono da verdade, e estou longe de criar alguma regra que se não usada irá causar o seu insucesso. Estou disposto a receber críticas que sejam construtivas, com o intuito de melhorar o sistema cada vez mais, possibilitando assim que a comunidade tenha em mãos um bom documento para consulta.
PHP ou Java?
Uma das perguntas que mais recebi ao longo de 2010, por isso estarei discutindo um pouco sobre qual linguagem de servidor usar. Inicialmente você deve saber que não é a linguagem que vai fazer você ter sucesso ou não em um sistema, e sim o quanto você conhece a mesma. Por exemplo, se você conhece muito bem PHP, porque aventurar-se em Java se dá conta do recado? O mesmo vale para o Java, mas não recebi emails de nenhum programador Java querendo mudar para php… (sic.. hehe).
O que? é fato nesta “briguinha” é que, não existe melhor ou pior. Java é mais complexo que php, exige mais atenção mas traz muitos benefícios, até financeiros (sim você ganha mais). PHP é mais fácil, você cria tudo mais rápido e com isso fica mais feliz Qual você vai escolher? Escolha a que te faz mais feliz.
Zend_AMF ou AMFPHP ?
Outra dúvida muito comum entre os programadores PHP. Eu costumo selecionar um ou outro dependendo do projeto em sí. Se o seu projeto vai usar alguns recursos do Zend Framework, e são muitos, utilize o Zend_AMF. Caso contrário, use AMFPHP.? Aqui chegamos a um impasse do qual julgo ser mais importante do que a briga entre Zend e AMFPHP: você ainda pensa em criar um projeto sem o Zend Framework? Você irá criar tudo que precisa “na mão” ou vai usar componentes de terceiros? Falo isso porque se um projeto em PHP é iniciado, o uso do Zend Framework irá acelerar muito o processo do mesmo. Rotinas como enviar email, acessar a sessão do php, gerenciar usuários com ACL, persistência de dados, acesso ao twitter… são todos muito bem implementados com o Zend e o Zend Framework é mantido pela mesma empresa que mantém o PHP, então não existe biblioteca mais segura em termos de continuidade do que esta.
E quais tecnologias vamos usar nas “melhores práticas” ?
Agora que discutimos as duas perguntas mais perguntadas em 2010 vamos a esta solução que julgo, pessoalmente, ser muito boa:
Certifique-se de ter tudo instalado, para que possamos dar prosseguimento no artigo.
Estrutura de pastas e projetos
Outra dúvida comum dos usuários, é definir a estrutura de pastas do projeto. Como instalamos o WAMP Server, ele nos fornece uma pasta onde é possível ter acesso pelo nacegador, através do endereço “localhost”. Isto é, ao acessarmos http://localhost/ o WAMP Server cuida de apontar para o diretório c:wampwww (que é o que chamamos de “document root”). Para que possamos entender a estrutura do projeto, é necessário compreender uma particularidade do Flex. Diferentemente do PHP, os arquivos que estão dentro do projeto Flex não precisam ser enviados ao servidor (os arquivos mxml, as, etc). veja que o Flex compila todos os mxml/as do projeto e gera um único arquivo swf. Este arquivo sim DEVE estar no diretório web do projeto!
Vamos então criar o projeto “melhoresPraticas” da seguinte forma:
Crie a pasta c:wampwwwmelhoresPraticas Este é o diretório público do projeto, acessado através de http://localhost/melhoresPraticas?????????
Crie a pasta c:wampwwwmelhoresPraticasclasses Este é o diretório onde iremos criar as nossas classes PHP
Crie a pasta c:wampwwwmelhoresPraticasvos Este é o diretório onde as classes VOs serão criadas
Crie a pasta c:wampwwwmelhoresPraticasZend Aqui você copia/cola o Zend framework, de forma que o arquivo melhoresPraticasZendLoader.php esteja acessível
No Flash Builder, crie o projeto “melhoresPraticas”. Você pode deixar o DefaultLocation como está. Não clique em Finish, clique em Next, até chegar na configuração do “Compiled Flex application location”. Ou seja, aqui você irá informar para onde os aquivos compilados do flex irão ficar. Coloque o seguinte caminho: c:wampwwwmelhoresPraticasbin-debug. Não clique em Finish, clique em Next, e em Library Path, adicione a biblioteca swiz (o arquivo swc). Em “Output folder URL”, coloque: http://localhost/melhoresPraticas/bin-debug
No Netbenas ou no eclipse, crie o projeto php apontando para c:wampwwwmelhoresPraticas
Testando a conexão
Com os projetos prontos, iremos inicialmente realizar uma simples conexão entre o Flex e o PHP. Isso é útil para que possamos começar com trabalho “pesado”. Para conectarmos o Flex no PHP, preciamos criar uma classe de conexão no Flex, que iremos chamar de ServiceBase, e um arquivo que recebe esta conexão no PHP, que chamaremos de gateway.php.
Para criar a classe ServiceBase, use o Flash Builder e acione o menu File > New > ActionScript Class e crie a classe de acordo com a imagem a seguir:
Classe ServiceBase:
package services { ??? import mx.controls.Alert; ??? import mx.rpc.events.FaultEvent; ??? import mx.rpc.remoting.RemoteObject; ??? ??? public dynamic class ServiceBase extends RemoteObject ??? { ??????? public function ServiceBase(classe:String) ??????? { ??????????? super(“zend”); ??????????? ??????????? /* ???????????? * Como o arquivo swf está na pasta bin-debug,? ???????????? * precisamos subir um nível para chegarmos ao ???????????? * arquivo gateway.php ???????????? */ ??????????? this.endpoint = “../gateway.php”; ??????????? ??????????? this.source = classe; ??????????? this.addEventListener(FaultEvent.FAULT,OnFault); ??????? } ??????? ??????? protected function OnFault(e:FaultEvent):void ??????? { ??????????? Alert.show(e.fault.faultString,”Erro” ); ??????? } ??? } }
Esta classe tem como principal objetivo estabelecer o endpoint, que é o gateway.php que ainda vamos criar. O atributo source define qual a classe que iremos acessar na pasta classes. Também adicionamos um listener genérico caso haja alguma falha na conexão. Veja que a classe é dinâmica (dynamic), ou seja, podemos chamar métodos da classe sem que eles estejam implementados na classe. Isso é útil pois os métodos chamados nesta classe serão os métodos remotos do PHP.
No servidor, temos que criar o arquivo gateway.php, com o seguinte código:
//Adiciona o autoloader do Zend Framework // Assim todas as classes do framework //? serão carregadas quando precisarem require_once “Zend/Loader/Autoloader.php”; Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);
//Instancia o servidor Zend_AMF $server = new Zend_Amf_Server();
//Habilita o modo de desenvolvimento, retornando // mensagens de erro. Comente esta linha quando //?? estiver em modo de produção $server->setProduction(false);
//Adiciona este diretorio como um diretorio de // classes que podem ser usadas pelo Flex $server->addDirectory(dirname(__FILE__).”/classes”); set_include_path(dirname(__FILE__).”/vos”);
//TODO: Adicionar VOs
//Dependendo da requisição do Flex, irá // chamar a classe correspondente, respondendo //?? em formato AMF o que a classe responder. echo $server->handle();
//Não fechar a tag PHP, nunca !!
?
O arquivo gateway.php é o ponto de entrada para as classes em PHP. Veja que inicialmente fazemos um include do Autoloader.php para que todas as classes do Zend Framework sejam instanciadas sem a necessidade de realizar requeires. Criamos então a instância do Zend_AMF_Server, que irá cuidar para que o flex consiga conversar com o PHP via AMF. Adicionamos o diretório classes como um diretório do AMF, onde as classes serão expostas ao flex e usamos o set_include_path para adicionar as classes que estão na pasta “vos” no path global do php, para que não precisamos fazer include das mesmas. Depois adicionaremos mais código sobre as classes VOs.
Na pasta “classes”, criamos a classe Teste, e o método sayHelloWorld. O nome do arquivo tem que ser o mesmo nome da classe, ou seja, Teste.php.
class Teste { ??? public function sayHelloWorld($name) ??? { ??????? return “Hello World $name”; ??? } }
//Não feche a tag PHP!
?
Agora voltaremos ao Flex para que ele possa acessar a classe teste. No arquivo melhoresPraticas.mxml, adicionamos o seguinte código:
Como estamos realizando um teste, fazemos o acesso ao PHP no evento creationComplete da aplicação. Criamos a variável testeService que é do tipo ServiceBase, repassando o parâmetro que é o nome da classe no PHP, ou seja, “Teste”. Também criamos a variável serviceHelper que pertence ao Swiz e é um facilitador de acessos ao PHP. Usamos no serviceHelper? o método executeServiceCall, que irá chamar remotamente o método sayHelloWorld repassando o parâmetro “Daniel” e quando concluído, executará a função que está no segundo parâmetro, realizando um Alert.
Ao executar esta aplicação, quando é carregada surgirá a mensagem de retorno do PHP:
?
Criando as classes em Service
Com o teste de conexão realizado, podemos avançar mais no código! A primeira refatoração que faremos é em relação as classes que estão na pasta service. Até agora criamos o seguinte código:
??? var testeService:ServiceBase = new ServiceBase(“Teste”);
Ao invés de criar a instância de ServiceBase repassando uma string que é o nome da classe, iremos criar a classe TesteService, da seguinte forma:
package services { ??? public dynamic class TesteService extends ServiceBase ??? { ??????? public function TesteService() ??????? { ??????????? super(“Teste”); ??????? } ??? } }
Veja que, ao criarmos a classe TesteService, podemos alterar o código da aplicação principal da seguinte forma:
var testeService:TesteService = new TesteService();
Implementando o SWIZ
Um dos melhores benefícios que o SWIZ traz é a possibilidade de separar todo o código Flex em camadas, assim como é feito no padrão MVC. Se você ainda não conhece SWIZ, é melhor conhecer, pois se está lendo este artigo está procurando criar aplicações com uma qualidade melhor e não há como chegar a esse nível sem um framework. O Swiz é o o melhor em termos de custo/benefício, porque nao é o mais fácil de aprender nem o mais complicado, e nao é o mais simples e nem o mais completo. É o meio termo em tudo.
Para usarmos o SWIZ, preciamos estabelecer algumas pastas dentro do projeto Flex, que serão nossas camadas. São elas:
config: contém os arquivos que chamamos de “bean”, que são os arquivos que fornecem informações para serem injetadas em outras classes
controllers: contém os arquivos que “ditam” a dinamica da camada de visualização
services: contém os arquivos que fazem o acesso ao PHP
events: contém eventos que podem ser disparados e mediados pelo flex
valueObjects: são os VOs que iremos usar na aplicação
views: contém os formúlários, é a camada de visão
Na pasta config, iremos criar o arquivo Bean.mxml, com o seguinte código:
Neste bean, criamos a variável “testeService”, que é o tipo TesteService. Atenção quando ao uso de letras maiúsculas e minúsculas.? Sempre voltaremos no Bean.mxml para adicionar mais variáveis e com isso, injetá-las nos formulários e controllers da aplicação. Precisamos ainda configurar o Swiz no projeto principal da aplicação (melhoresPraticas.mxml):
Esta configuração, adicionada dentro do fx:Declarations, realiza uma configuração padrão no SWIZ. Basicamente adicionamos o Bean que criamos e definimos onde as classes relacionadas a eventos e formulários ficarão. Também definimos um LOG que será apresentado na aba Console do Flex se estiver rodando em modo de Debug.
Após a configuração
Podemos por exemplo criar a tela de login, e outras telas do sistema. Deixarei o código fonte da aplicação para que você possa olhar com calma.
A lista a seguir é um resumo de melhores práticas que julgo importantes
Use módulos/sub applications somente se precisar mesmo. Não comece um projeto de 10 telas querendo usar módulos para cada tela.
Separe sua aplicação em camadas. Você escreve mais e cria mais artigos, mas o projeto fica mais consistente.
Você não precisa criar o arquivo services-config.xml para conectar sua app no servidor. Pode-se criar uma classe cujo o endpoint é um caminho RELATIVO ao gateway.
Use o caminho RELATIVO sempre, para faclitar o deploy da sua app. Isto é, use “../gateway.php” ao invés de “http://localhost/gateway.php”.
Injete o controller na view, para passar dados à ela. Se deseja enviar mensagens para a view, então use eventos
Não injete a view no controller.
Use o dispatcher do SWIZ.
Use o serviceHelper do SWIZ.
Quando criar um formulário na view, faça o databind com uma variável do controller.
Use eventos com moderação. Particularmente eu uso os eventos para notificar a view de alguma mudança, nunca para passar dados, que é função do controller.
Se você quer chamar um método da view pelo controller, use eventos.
Today the Flex tip will talk about the usage of the local SharedObject object and how to implement it to store simple data objects.
When you create a SharedObject obejct the Flash Player also creates an empty *.sol file that stores the SharedObject data limited up to 100 KB per domain. If you try to saving bigger data the user must to authorize this process through a Local Storage dialog box. The supported types are: Number, String, Boolean, XML, Date, Array and Objects. You can also store typed ActionScript instances by callling the flash.net.registerClassAlias() function in order to preserve the class type of an object when the object is encoded in AMF.
Use the SharedObject.getLocal() method for create a SharedObject object:
In order to store these information into a SharedObject you must use the property data:
sharedObject.data.information = "the information goes here";
The method flush() causes Flash Player to write the information in the respective data file. In case you don’t call it directly, the data will be persisted once you close the browser. Therefore, it’s a good practice to call it.
sharedObject.flush();
The clear() method clears the file and removes it from the local disk.
Tudo bem eu sei que isto aqui já não é mais novidade, porém apenas para documentar um vídeo de zueira que o pessoal da comunidade criou, baseando-se na Lady Gaga, dai surgindo a Lady Java. Achei interessante também a letra da música hehe
O Zend AMF é uma implementação feita em PHPpara se trabalhar com o protocolo de comunicação binário AMF(Action Message Format) fazendo parte do ZendFramework. Precisei implementar um sistema de upload de arquivos que fosse um pouco diferente do que normalmente é usado no Adobe Flash, sendo que essa funcionalidade precisava ser integrada no Zend AMF.
Pesquisando um pouco na net, achei a solução que foi mais simples do que eu imaginava baseada nesse artigo com algumas poucas adaptações.
Começaremos pelo nosso gateway que será usado como endpoint no Adobe Flex.
Algumas linguagens de programação possuem o recurso de se trabalhar com exceções como PHP, ActionScript 3.0, Java, C# etc. É um recurso que se for bem usado, torna-se poderoso e ajuda a evitar futuras dores de cabeça para seu sistema. Uma exceção nada mais é que a possibilidade de tratar um erro sem necessariamente parar totalmente seu programa.
O suporte a exceções foi adicionado no PHP a partir da versão 5, e pode ser usando em conjunto com o Adobe Flex, neste caso utilizarei o Zend AMF, uma implementação do protocolo AMF para se trabalhar em conjunto com a Flash Platform e seu server-side rodando PHP fazendo parte do ZendFramework.
Considera-se uma boa prática você criar sua classe de exceção extendendo a classe Zend_Exception.
Por enquanto só isso basta, podemos implementar mais métodos de acordo com a necessidade de nosso sistema.
Agora criaremos uma classe para disparar a exceção, no PHP isso é feito usando a palavra reservada “throw”.
Nossa atenção se voltará para o FaultEvent, ele é responsável por capturar as exceções vindas do servidor. Basicamente só precisaremos mostrar ao usuário o faultString.
Translate to English. Um problema comum é trabalhar com datas entre diferentes linguagens de programação, pois cada uma trata seu objeto do tipo Date de forma diferente. Neste artigo vou mostrar como faço quando trabalho com Flex, AMFPHP e MySQL. No artigo anterior Serializando objetos entre Flex e PHP usando AMFPHP onde mostrei como mapear [...]
Translate to english Atendendo ? pedidos, segue outro artigo sobre como serializar objetos (mapear VOs ou DTOs) entre Flex e PHP usando AMFPHP. O processo é muito simples, o AMFPHP já faz tudo sozinho, mas há detalhes importantes no processo. Crie o diretório ‘vo’ dentro da pasta ‘services’ do teu AMFPHP. Por padrão, o AMFPHP [...]
BlazeDS é uma implementação feita em Java para se trabalhar com o protocolo AMF(Action Message Format) e facilitar a comunicação entre o swf e seu server-side em Java.
Quando você começa a utilizar um recurso diferentemente da maioria das pessoas, pode achar algums problemas dificeis de resolver. Com Java e Flex o velho problema é o Lazy Loading, que ja foi assunto de varias discurssões entre eu e o Wenderson. Eu deixei esse assunto de lado para focar em outras coisas. No entanto o Wenderson conseguiu achar uma solução, veja o artigo completo com a solução. Adobe Flex, BlazeDS, Gilead, LazyLoading Resolvido(LazyLoading Solved)
Seguindo o artigo anterior, iremos agora utilizar o Flex em conjunto com o PHP para salvar as imagens no servidor. A conexão entre o Flex e o PHP será realizada pelo AMFPHP.
Este artigo teve uma grande ajuda do Bruno Santana, que nos mandou o código sobre a gravação do arquivo pela webcam.
Teste a aplicação. Veja inicialmente se a aplicação abre com o endereço "localhost" e não "c:….". Clique no botão e verifique se a mensagem "Hello World from AMFPHP" surgir. Se for algum erro, você precisa investigar o erro através da mensagem de erro padrão do log de erros do wamp (c:wamplogsapache_error.php). Se não achou nada, use o Firefox+Firebug+Flashbug ou então use o Charles Proxy(http://www.charlesproxy.com/)
Configurando a WebCam
Esta parte é tranquila, já que vimos isso no artigo anterior. Apague o “hello world” do teste de conexão e faça:
Até aqui apenas exibimos a câmera e o botão salvar. Vamos agora dar a funcionalidade necessária para enviar a imagem da WebCam para o servidor. Crie o arquivo Foto.php na pasta services, com o seguinte conteúdo:
<?php
class Foto
{
function __construct()
{
}
function Save($fotoAsString)
{
//obtém um id unico para o arquivo
$nomeArquivo = uniqid();
//configura o nome do arquivo
$nomeImagem = "imagem/{$nomeArquivo}.jpg";
//abre o arquivo. A opção w vai criá-lo, caso nao exista
$arquivo = fopen($nomeImagem, 'w');
//escreve no arquivo
fwrite($arquivo, base64_decode($fotoAsString));
return "ok";
}
}
Aqui, criamos no método Save uma rotina para salvar a imagem no disco. Isso é feito graças a transformação da foto em string e na sua volta, pelo método base64_decode.
Exibindo as imagens gravadas no Flex
Assim que a foto é gravada, a reqisição feita pelo Flex volta, com um "ok". Então podemos usar outra rotina para ler todas as imagens e apresentá-las no flex:
No código acima, criamos uma lista do tipo tile, cujo o itemrenderer é um componente do tipo image.
Para preencher esta lista, usamos o seguinte código:
protected function OnGetAll(event:ResultEvent):void
{
exibirImagens.dataProvider = new ArrayList((event.result as Array));
}
Ou seja, sempre que chamamos o método GetAll, o php se encarrega de obter uma lista de imagens e retorná-la para o Flex. Com esta lista preenchemos o dataProvider da lista de imagens que possui o itemRenderer.
O redeRIA não é nada mais que um agregador de feed's que disponibiliza o conteudo de varios blogs e autores ao redor do mundo RIA, actualmente agregamos mais de 2791 entradas vindas de 53 blogs especializados em ria’s, pelo que só fica a ganhar em assinar o feed ou seguir a comunidade no twitter.
Se acha que o seu blog ou um blog de um amigo é interessante e util para os leitores o redeRIA, faça a sua submissão aqui.
Qual você vai escolher? Escolha a que te faz mais feliz.
O Zend AMF é uma implementação feita em 
