Olá pessoal!
Essa semana um artigo meu foi publicado pela Flash and Flex Developer Magazine. O artigo trata de como construir uma publicação Flex Mobile utilizando o framework Swiz e o framework FlexORM, se você tem algumas dúvidas sobre persistência e gerenciamento de aplicações Flex utilizando algum framework, convido você a ler meu artigo. A revista é eletrônica, você pode conferir o artigo clicando na imagem abaixo.
Espero que o artigo lhe ajude no desenvolvimento Flex Mobile.
[PT-BR]
Criei uma biblioteca q pode ser muito util para quem trabalha com projetos usando Swiz. O projeto ainda é beta, mas já coloquei no github para vcs poderem acompanhar evoluções/correções. Por favor, leiam o arquivo README (html ou RichText).
Valeu!
[EN-US]
I’ve created a simple project named [DynamicService] custom metadata for Swiz Framework (Adobe Flex) and I’ve posted on github. Let you know that’s a beta project, but you can download it. Please read the README file (html or rtf extension).
Github link: https://github.com/mariojunior/DynamicServices-Custom-Metadata
Thanks.
Olá pessoal, nesse breve artigo eu irei falar um pouco sobre as Metadata Tags.
[Importante]
A partir da versão 4.5 do flex as Metadatas customizadas não precisam ser declaradas para o compilador nos projetos Flex, o conhecido “-keep-as3-metadata”, quem trabalha com Frameworks de terceiros entende bastante isso.
Notei na nova versão do Swiz Framework que existe também uma complementação do código para metadatas personalizadas como “Inject e EventHandler”. Depois de vasculhar os fontes do Swiz Framework encontrei o arquivo metadata.xml que é o responsável pela declaração de todas essas metadatas.
Se você está criando uma biblioteca que possui suas próprias metadatas e deseja criar uma complementação do código, basta seguir os passos da documentação da própria Adobe, é bem simples.
Esse é um exemplo desse arquivo de configuração.
Você pode se basear pelo arquivo do próprio framework do flex. Fica na pasta: sdks4.5.0frameworksmetadata.xml
Espero que a informação tenha sido útil.
Abaixo seguem alguns links interessantes relacionados ao assunto.
Hoje vou falar sobre um pattern muito importante e que é muito usado no Flex(client) chamado de Delegate. Para quem nunca ouviu falar vou resumir da seguinte forma:
“Delegate é o pattern que indica a comunicação do cliente com as regras de negócio sem a necessidade do cliente conhecer as regras de negócio.”
Explicação Abstrata – Todo sistema possui suas regras de negócio, que normalmente são expostas através de serviços. o Delegate tem justamente esse papel, centralizar um local no cliente(aplicação frontend) para essa chamada ao serviço que expôe as regras de negócio do sistema. Uma coisa muito importante nesse pattern é que ele não deve conhecer as regras de negócio em si, normalmente consomem serviços mas não sabem o que realmente eles fazem.
Explicação Concreta - Em 90% dos projetos em que trabalho cujo o frontend é em Flex o backend é em Java, toda a lógica do sistema(Regras de Negócio) ficam no java. No Java possuo um Serviço que via Blazeds é disponibilizado para ser consumido no Flex. Com esse cenário costumo ter uma classe Delegate no lado do flex que consome o serviço disponibilizado pelo blazeds através de RemoteObject.
Na teoria é tudo muito funcional e faz sentido, porém na prática sempre existe a dúvida se realmente vale a pena ter mais esse nível de conceito e organização no flex, então vou colocar 2 pontos positivos para estimular essa boa prática:
Definição de uma padrão na comunicação com backend – a partir de hoje quando você analisar um código em flex que possui um classe com parte do seu nome Delegate você terá a certeza que toda a comunicação com o backend se encontra ali, não precisa que ninguém te mostre ou que desenhe pra você 
Grande Facilidade para usar os Mocks – Outro ponto positivo que está diretamente ligado a minha opinião é o uso de Mocks, para quem não sabe o que é Mocks precisa de um tapa na orelha..rs brincadeira 
. Mocks são dados que são gerados de forma “falsa” para testar ou simular uma parte de um sistema, normalmente uso muito no flex para simular uma chamada ao serviço do backend, isso é bom porque não preciso de um servidor rodando para testar(me refiro a teste funcional) se o client(flex) está funcionando corretamente.
Vou terminar com 2 exemplos práticos de como o uso do Delegate me ajudou a padronizar meu projetos e a usar os mocks:
Flex 4 + Swiz – neste Tutorial Básico Swiz Framework 1.0 uso o conceito de Delegate como pode ser analisado nesse pacote e Também os Mocks(no caso dos Mocks uso o utilitário do próprio swiz para criar mocks) que é justamente a classe ContactDelegateFake.as.
Flex 4 + Springas – neste Tutorial Spring ActionScript uso o conceito de Delegate como pode ser analisado nesse pacote e também os Mocks(No caso dos Mocks uso o utilitário do springas para criar mocks) que é justamente a classe ContactDelegateFake.as.
Em ambos os casos acima na controller(que é onde fica a classe que faz referência ao delegate) é feito apenas referência a uma interface IContactDelegate, então fica fácil mudar de mock para o Delegate que realmente invoca o backend, se a comunicação com backend já fosse feita no controller essa mudança de mock para o real ficaria muito mais difícil.
Bem, bons estudos e espero ter justificado o porque que em meus exemplos aqui no blog costumo usar o pattern delegate 
Cumps.
Similar Posts:
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.
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.
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.
Agora que discutimos as duas perguntas mais perguntadas em 2010 vamos a esta solução que julgo, pessoalmente, ser muito boa:
No cliente:
No servidor:
?
Certifique-se de ter tudo instalado, para que possamos dar prosseguimento no artigo.
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:
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:
?
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx” minWidth=”955″ minHeight=”600″>
???
??????? ??????????? import mx.controls.Alert;
??????????? import mx.rpc.events.ResultEvent;
???????????
??????????? import org.swizframework.utils.services.ServiceHelper;
???????????
??????????? import services.ServiceBase;
??????? ]]>
???
???
???
??????? ???????????
??????????? var testeService:ServiceBase = new ServiceBase(“Teste”);
??????????? var serviceHelper:ServiceHelper = new ServiceHelper();
???????
??????? serviceHelper.executeServiceCall(
??????????? testeService.sayHelloWorld(“Daniel”),
??????????? function(e:ResultEvent):void{
??????????????? Alert.show(e.result.toString());
??????????? });
???????
??????? ]]>
???
???
?
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:
?
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();
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:
Na pasta config, iremos criar o arquivo Bean.mxml, com o seguinte código:
??? xmlns:s=”library://ns.adobe.com/flex/spark”
??? xmlns:swiz=”http://swiz.swizframework.org”
??? xmlns:services=”services.*”
??? >
???
???
???
?
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):
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx”
?????????????? xmlns:swiz=”http://swiz.swizframework.org”
?????????????? minWidth=”955″ minHeight=”600″ xmlns:config=”config.*”>
???
???
???????
???????????
???????????????
???????????
???????????
???????????
???????????????
??????????????????? viewPackages=”views.*”
??????????????????? />
???????????
???????????
???????????
???????????????
???????????
???????????
???????
???
???
?
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.
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
Bem, estou muito feliz por esse início de ano 100% Flex, seja tirando dúvidas, desenvolvendo ou corrigindo alguns detalhes em aplicações, enfim, é muito bom voltar com o flex na minha carga horária 
#FlexNaVEIA
Bem, nesse início de ano a coisa que mais me perguntaram foi, o swiz vale a pena? tem como fazer um exemplo usando o novo swiz? então resolvi fazer esse tutorial onde tentarei ser o mais básico possível, espero justificar o porque é bom ter o Swiz como uma alternativa de Framework para você usar em suas aplicações Flex.
Embora esteja fazendo esse ABC é bom que todos divulguem os excelentes materias que já foram disponibilizados sobre o assunto como a próprio Wiki do Swiz que é bem completo, esse material do nosso amigo Mario Junior ( Swiz + Modules ) , o material também disponibilizado pelo nosso amigo Erko Bridee ( [Flex & AIR] Swiz Framework + Presentation Model : Exemplo de Projeto ), tem também os que disponibilizei no Flexmania no ano de 2010 ( #flexmania 2010 – disponibilizando código fonte ). Além desses links tem o que criei no curso de Design Patterns ( flexdp ), onde sou o instrutor, fiz um exemplo com flex4 + swiz + presentation model, é baseado nesse modelo um pouco mais simplificado e sem tratar os design patterns que vou fazer esse tutorial para vocês . Let’s go
Para quem ainda não conhece o swiz framework, ele é um framework para Action Script 3(Portanto usamos no Flex tranquilamente), e como todo bom framework o swiz cuida de algumas partes chatas enquanto nos preocupamos mais com o nosso modelo de negócio. Vou me basear nesses 3 pontos que considero bons motivos para usar o Swiz:
Irei explicar com calma cada item deste citado acima principalmente quando for mostrando o código fonte, porém vale ressaltar que um dos melhores pontos é o baixo acoplamento entre o framework e nossa aplicação, com o bom uso de metadatas o swiz consegue nos auxiliar na construção de uma aplicação e não se meter na forma como organizamos o projeto. O Swiz em suas versões mais novas não é mais um framework MVC como já disse em outro post no blog ( http://www.jandersonfc.com/swiz-nao-e-framework-mvc/ ) , o swiz se concentrou em ser um IOC e DI eficiente que vamos conhecer mais detalhadamente a partir de agora
Não tem nada melhor para aprender algo do que um exemplo prático, no nosso caso um CRUD, depois do “Hello Word” é a forma mais requisitada que conheço, vamos fazer um cadastro de Contatos , bem simples e só a parte do Flex(e sem se preocupar com o layout no momento)… vamos usar um recurso do próprio Swiz (MockDelegateHelper)para simular as chamadas aos serviços no backend.
Aqui está o projeto rodando
aqui está o código fonte do projeto ( https://github.com/jandersonfc/ContactSwiz )
Para não ficar muito extenso vou postar parte do código que apenas seja útil para entender o Swiz, qualquer dúvida podem usar o comentário a vontade para isso.
uma das grandes vantagem de usar o Swiz é o suporte que ganhamos para tratar nossos eventos, através do uso de metadatas [EventHandler] podemos deixar nosso código bem desacoplado de quem envia para quem recebe os eventos, vamos ao exemplo do nosso tutorial:
perceba que desacoplamos completamente nosso Presentation Model(ContactPM) do resto da aplicação, ele só dispara um evento e através do swiz nosso Controller(ContactController) será invocada.
Obs. Perceba essa primeira variável,a dispatcher, ela usa um metadata do Swiz [Dispatcher], o framework recomenda trabalhar dessa forma embora usando eventos com bubles também funcione.
Agora vamos analisar esse trecho da nossa Controller :
Quando disparamos o evento ContactEvent.GET_CONTACTS em nosso Presentation Model(ContactPM) o Swiz irá invocar esse método getContacts() do nosso ContactController, isso porque esse método possui um metadata do swiz [EventHandler] com o tipo do evento que ele fica na escuta, nesse caso o event=”ContactEvent.GET_CONTACTS”. A mágica fuciona tão bem que nossa PM(Presentation Model) e Controller não se conhecem, e é esse o grande ganho que temos em usar esse EventHandler do Swiz, baixo acoplamento o que ajuda e muito na manutenção de nossa aplicação.
Mas toda mágica para funcionar precisa de um truque, e com o Swiz não é diferente, por isso existe o seu arquivo de configuração que mostro abaixo.
para essa mágica funcionar precisamos informar esses atributos eventPackages e viewPackages para o swiz:
Obs. Observe esse
Além da forma como Swiz nos ajuda a trabalhar com os eventos, o que já considero um ganho e tanto, o Swiz possui um excelente IOC container e DI através do metadata [Inject], vamos mais uma vez analisar nosso Controller:
perceba o [Inject] em cima dos atributos do nosso controller, isso quer dizer que quando nossa aplicação for iniciada o swiz vai procurar referências em seu container desse objeto e vai injetá-lo em nosso Controller. Mais uma linda mágica
Como assim? Como o Swiz vai saber por exemplo que esse contactDelegate que é uma Interface (IContactDelegate) qual implementação(ContactDelegate e ContactDelegateFake) usar na hora de criar a instancia desse objeto? Aí vem mais um truque, o nosso arquivo que citei mais acima, o nosso Beans.mxml, é o que chamamos de IOC container do swiz:
É aí que você vai mapear os objetos que você quer que quando a aplicação for iniciada o swiz crie instancias desses objectos. Bem, ainda não entendeu? O fluxo é esse.
É por isso que em nenhum momento na nossa ContactController foi preciso instanciar o atributo contactDelegate, o swiz cuidou disso pra nós, e isso chamamos de DI, quando a responsabilidade de instanciar suas dependências não é do próprio objeto, no nosso caso a Controller não instancia a suas dependências e sim o Swiz. Uma coisa interessante que gostaria que vocês observassem é que nesse exemplo existe duas implementações do IcontactDelegate, o ContactDelegate e ContactDelegateFake, está ativo no exemplo o Fake mas para mudar para o Delegate que usa o RemoteObject é só mudar de:
para:
ou seja, alteramos no arquivo de configuração do swiz e não precisamos mudar nada no código da nossa aplicação, isso tudo porque na Controller mencionamos apenas uma interface e não a sua implementação que só é definida em tempo de execeção pelo Swiz.
algo muito útil também no swiz é seu serviceHelper que nos auxilia na comunicação com o nosso backend, que na maioria das vezes é feito via RemoteObject, vamos analisar na nossa Controller:
é bem simples o seu uso e de fácil entendimento, ao chamar o método executeServiceCall passando 3 parametros já é
o suficiente para o swiz fazer a requisição no backend ou chamar quem faça(no nosso caso o Delegate que faz isso) e mapear qual função vai tratar o retorno do nosso RemoteOject em caso de sucesso ou em caso de erro.
Espero com esse exemplo e rápida explicação tenha te incentivado a usar o mesmo, e lembre-se, o swiz não impôe uma forma de estruturar sua aplicação, nada impede de você injetar a Controller no Presentation Model e diminiur a quantidade de eventos disparados na aplicação por exemplo, nem de usar MVC ou não em sua arquitetura.
Uma coisa que sempe digo é que antes de usar algo que facilite seu desenvolvimento você precise aprender sem as facilidades, eu tive que aprender como mapear o Hibernate com XML para depois perceber o ganho que tinha com os Annotations, talvez você precise aprender como funciona os eventos em actionScript para perceber o ganho que terá usando os [EventHandler] do Swiz por exemplo
O swiz possui mais algumas funcionalidades, mas essas são as básicas para você já começar a usá-lo, então faça bom proveito
Cumps.
Similar Posts:
Também fiz alguns treinamentos:
Entre outros:
A todos os envolvidos meus sinceros agradecimentos.
E deixo também aqui o meu desejo de um Feliz e Próspero 2011 para todos.
Que venha novos desafios.
Planejamento, Prototipação e Execução de um projeto Flex/Swiz Framework e PHP/MySQL from e-Genial on Vimeo. O documento apresentado no webminar pode ser baixado aqui.
Esse post vai para galera do Flex e tem esse Título com um certo tom de contradição justamente para alertar sobre alguns equívocos que cometemos por não conhecer de verdade como um framework funciona e qual é o seu real Objetivo. Vou mostrar o caso do swiz só para vocês meditarem sobre isso.
SWIZ FRAMEWORK
Swiz é um framework muito bem organizado, podemos dizer que o swiz é:
IOC(Inversion of Control) containers – o arquivo Swiz(Classe do core do framework) é o ioc containers, que por sua vez carrega os BeanLoaders que é onde podemos colocar qualquer classe (da nossa aplicação ou não) para ser instanciada pelo swiz , quando a aplicação flex for iniciada o swiz cria intancia dos beans colocados no containers que por padrão usam o design patterns singleton para garantir apenas uma instancia desses beans(por default já que podemos escolher o padrão prototype para esse caso também). Normalmente no nosso BeanLoaders colocamos nossos RemoteObject, controladoras, delegates, presentation Model, etc…
IOC como o próprio nome diz significa que algumas responsabilidades não será da nossa aplicação mas sim do Framework, basicamente todo framework é um IOC já que ele em algum momento assume responsabilidade sobre uma atividade na aplicação, porém nem todos frameworks tem um container como é o caso do swiz, esse container deixa o framework mais dinâmico, podemos informar as classes que queremos que ele instancie, quais packages queremos que ele intercepte caso seja disparado um evento… A metadata [Mediate] é um exemplo de como um IOC do swiz funciona, quando é disparado um evento na aplicação o swiz procura o método que possui o metadata [Mediate] que correspende aquele evento disparado e invoca o método.
DI(Dependency Injection) – Essa é uma das melhores partes do swiz, usar Metadata(no java Annotations) para injetar as dependências. Através do uso da metadata [Inject] o swiz consegue injetar qual objeto que deve ser usado naquele caso. Perceba que é responsabilidade do IOC containers comunicar para o swiz quais os objetos que devem ser instanciados e através de um metadata [Inject] o framework pega a instancia que ele já criou quando subiu a aplicação e injeta no atributo que se encontra com a metadata [Inject]. Injeção de dependência é tirar a responsabilidade daquela classe de instanciar os objetos(Atributos) que ela depende para funcionar. O swiz usa como base para injeção de dependência o IOC containers criado por nós, então é correto dizer que IOC é uma forma de injetar dependências (DI) mas é bom você ter ciência que não é a única forma.
o Swiz é isso,IOC e DI, aonde está o MVC? em lugar nenhum. podemos não implementar um MVC e usar o swiz para desacoplar responsabilidades usando injeção de depenências e/ou facilitar a forma com que trabalhamos com os eventos no flex. O fato de usar MVC é um boa prática e a própria documentação do framework recomenda porém o swiz não é framework MVC.
Principalmente no caso do swiz é normal essa confusão, já que em suas primeiras versões se tratava de um framework MVC, porém com a maturidade de seu container e um bom uso de metadata o foco foi mudando. Por isso é muito importante você analisar o que realmente cada framework faz, baixe o código fonte do mesmo, tente entender e assim você não será enganado pelas aparências.
Espero que medite sobre o mesmo e logo perceberá que o Spring(AS) e Mate também não são frameworks MVC.
Cumps.
Similar Posts:
Algo legal no Flex é que eles nos disponibiliza gráficos, porém, sinceramente o estilo padrão dos gráficos com cores sólidas não me agrada muito, ao meu ver cansa os olhos, então resolvi mudar as cores solidas para um padrão em degrade, para suavizar as cores…
Obs.: tendo em mente que os componentes dos gráficos ainda são os mesmos no Flex 3 e 4 os códigos mxml a seguir serão do Flex 3.
Começando pelo gráfico de barras, para ter o seguinte resultado precisei:
Código MXML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 |
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" verticalAlign="middle" backgroundColor="white"> <mx:Script> <![CDATA[ import code.StyleColumnChart; import mx.charts.chartClasses.IAxis; private function linearAxis_labelFunc(item:Object, prevValue:Object, axis:IAxis):String { return currencyFormatter.format(item); } private function categoryAxis_labelFunc(item:Object, prevValue:Object, axis:CategoryAxis, categoryItem:Object):String { var datNum:Number = Date.parse(item); var tempDate:Date = new Date(datNum); return dateFormatter.format(tempDate).toUpperCase(); } ]]> </mx:Script> <mx:DateFormatter id="dateFormatter" formatString="DD" /> <mx:CurrencyFormatter id="currencyFormatter" precision="2" /> <mx:XMLListCollection id="dp"> <mx:source> <mx:XMLList> <quote date="8/1/2007" open="40.29" close="39.58" /> <quote date="8/2/2007" open="39.4" close="39.52" /> <quote date="8/3/2007" open="39.47" close="38.75" /> <quote date="8/6/2007" open="38.71" close="39.38" /> <quote date="8/7/2007" open="39.08" close="39.42" /> <quote date="8/8/2007" open="39.61" close="40.23" /> <quote date="8/9/2007" open="39.9" close="40.75" /> <quote date="8/10/2007" open="41.3" close="41.06" /> <quote date="8/13/2007" open="41" close="40.83" /> <quote date="8/14/2007" open="41.01" close="40.41" /> <quote date="8/15/2007" open="40.22" close="40.18" /> <quote date="8/16/2007" open="39.83" close="39.96" /> <quote date="8/17/2007" open="40.18" close="40.32" /> <quote date="8/20/2007" open="40.55" close="40.74" /> <quote date="8/21/2007" open="40.41" close="40.13" /> <quote date="8/22/2007" open="40.4" close="40.77" /> <quote date="8/23/2007" open="40.82" close="40.6" /> <quote date="8/24/2007" open="40.5" close="40.41" /> <quote date="8/27/2007" open="40.38" close="40.81" /> </mx:XMLList> </mx:source> </mx:XMLListCollection> <mx:ColumnChart id="columnChart" showDataTips="true" dataProvider="{dp}" width="100%" height="100%"> <!-- vertical axis --> <mx:verticalAxis> <mx:LinearAxis baseAtZero="false" labelFunction="linearAxis_labelFunc" /> </mx:verticalAxis> <!-- horizontal axis --> <mx:horizontalAxis> <mx:CategoryAxis id="ca" categoryField="@date" title="August 2007" labelFunction="categoryAxis_labelFunc" /> </mx:horizontalAxis> <!-- horizontal axis renderer --> <mx:horizontalAxisRenderers> <mx:AxisRenderer axis="{ca}" canDropLabels="true" /> </mx:horizontalAxisRenderers> <!-- series --> <mx:series> <mx:ColumnSeries displayName="Open" xField="@date" yField="@open" fill="{StyleColumnChart.orangeLinearGradient}" stroke="{StyleColumnChart.orangeStroke}"> </mx:ColumnSeries> <mx:ColumnSeries displayName="Close" xField="@date" yField="@close" fill="{StyleColumnChart.blueLinearGradient}" stroke="{StyleColumnChart.blueStroke}"> </mx:ColumnSeries> </mx:series> <!-- series filters --> <mx:seriesFilters> <mx:Array /> </mx:seriesFilters> </mx:ColumnChart> </mx:Application> |
Obs.: esse código acima reaproveitei do respectivo post do blog.flexexamples.com
Código da classe AS3 para gerar o efeito visual:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 |
package code { import mx.graphics.GradientEntry; import mx.graphics.LinearGradient; import mx.graphics.Stroke; [Bindable] public class StyleColumnChart { public function StyleColumnChart() {} //---------------------------------------------------------------------- // @BEGIN: LinearGradient color public static function linearGradientColor(colorDark:uint, colorLight:uint):LinearGradient { var linearGradient:LinearGradient = new LinearGradient(); var arr:Array = []; arr.push(new GradientEntry(colorDark, 0.0, 0.8)); arr.push(new GradientEntry(colorLight, 1.0, 0.6)); linearGradient.entries = arr; return linearGradient; } public static function get redLinearGradient():LinearGradient { return linearGradientColor(0x990000,0xEE0000); } public static function get greenLinearGradient():LinearGradient { return linearGradientColor(0x008B00,0x00FF00); } public static function get blueLinearGradient():LinearGradient { return linearGradientColor(0x0066FF,0x00CCFF); } public static function get yellowLinearGradient():LinearGradient { return linearGradientColor(0xCAC333, 0xF5F30E); } public static function get orangeLinearGradient():LinearGradient { return linearGradientColor(0xFC9C00, 0xFCC048); } // @END: LinearGradient color //---------------------------------------------------------------------- // @BEGIN: stroke color public static function strokeColor(color:uint):Stroke { return new Stroke(color,1); } public static function get redStroke():Stroke { return strokeColor(0x990000); } public static function get greenStroke():Stroke { return strokeColor(0x008B00); } public static function get blueStroke():Stroke { return strokeColor(0x0066FF); } public static function get yellowStroke():Stroke { return strokeColor(0xCAC333); } public static function get orangeStroke():Stroke { return strokeColor(0xFC9C00); } // @END: stroke color //---------------------------------------------------------------------- } } |
A seguir segue um exemplo para gráfico de pizza:
Código MXML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
<?xml version="1.0"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"> <mx:Script> <![CDATA[ import mx.collections.ArrayCollection; import code.StylePieChart; [Bindable] public var expenses:ArrayCollection = new ArrayCollection([ {Data:"IN", Value:2000}, {Data:"OUT", Value:1000} ]); ]]> </mx:Script> <mx:Panel title="Pie Chart"> <mx:PieChart id="myChart" dataProvider="{expenses}" showDataTips="true"> <mx:series> <mx:PieSeries field="Value" nameField="Data" labelPosition="callout" fills="{StylePieChart.inOutFills}"/> </mx:series> </mx:PieChart> <mx:Legend dataProvider="{myChart}"/> </mx:Panel> </mx:Application> |
Código da classe AS3 para gerar o efeito visual:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
package code { import mx.graphics.GradientEntry; import mx.graphics.RadialGradient; import mx.graphics.SolidColor; [Bindable] public class StylePieChart { public function StylePieChart() {} //---------------------------------------------------------------------- public static function get inOutFills():Array { var gradients:Array = new Array(); var fill:RadialGradient = null; var g1:GradientEntry = null; var g2:GradientEntry = null; fill = new RadialGradient(); g1 = new GradientEntry(0xCC3640); g2 = new GradientEntry(0x990000); fill.entries = [g1,g2]; gradients.splice(-1,0,fill); fill = new RadialGradient(); g1 = new GradientEntry(0x30BB32); g2 = new GradientEntry(0x009900); fill.entries = [g1,g2]; gradients.splice(-1,0,fill); return gradients; } //---------------------------------------------------------------------- } } |
Para achar as cores utilizei os itens descritos neste post: [Adobe AIR] Color Browser
