Quando se começa a estudar alguma tecnologia, ferramenta ou metodologia você sempre ouvirá essa bendita pergunta, mas por que você escolheu x ou Y? comigo não é diferente e ouço essa pergunta alguma vezes em relação ao Flex, principalmente essa semana um pouco mais movimentada..rs

vamos para o momento múltiplas escolhas:

(  ) Porque o Flex traz produtividade no desenvolvimento de Aplicações.

(  ) Porque com o Flex se consegue uma experiência mais agradável para o usuário final.

(  ) Porque o Flex paga muito bem e me deixou rico do dia para noite.

(  ) nenhuma das opções acima.

Eu já escutei todas essas respostas como justificativa da escolha do Flex mas poucos responderam que é nenhuma das opções acima. Esse é o meu caso, escolhi o Flex porque era a tendência da vez, calma explico melhor.

Em 2008 quando comecei efetivamente a estudar o Flex trabalhava com Visual Basic 6 em manutenção de sistema legado, meu objetivo na empresa era migrar tudo para .Net, porém , pensar em transcrever sistema legado é algo que sempre fica em segundo plano de uma empresa que não tem reservas financeiras. .Net era um mercado muito burocrático e não percebia um crescimento profissional na velocidade que gostaria, foi aí que conheci o Flex com alguns evangelistas divulgando e mostrando como a ferramenta funcionava, comecei a pesquisar o mercado e vi que estava começando a crescer de uma forma assustadora, pessoas querendo aprender mas poucos eram os que apareciam como evangelistas, pessoas que realmente dominavam e estimulavam todos a se aprofundar na tecnologia. Foi quando percebi que o Flex era a tendência da vez, nesse momento meu objetivo foi se especializar e fazer parte desses poucos que estimulavam as pessoas.

Seguir a tendência me fez de um programador de sistema legado sem muita expectativa do futuro para a um Desenvolvedor criando soluções inteligentes para grandes empresas, participando de eventos e compartilhando conhecimento para um público carente de pessoas que os ajude na etapa mais difícil da adoção de uma nova tecnologia que é o começo.

Portanto eu não escolhi o Flex porque posso fazer um produto final com maior qualidade e nem porque ele colocou mais dinheiro no meu bolso, escolhi o Flex porque ele era o melhor investimento de curto/médio prazo que eu encontrei para alcançar meus objetivos na minha carreira.

Quando falo em carreira não estou falando do fator financeiro, acho que é como o @IgorMusardo falou hoje

“nós #soudev queremos estar sempre na crista da onda”

Penso sempre em pessoas que foram escravas dos seus talentos, como Michael Jordan, ele tinha metas claras como ser o melhor, sempre na busca pela excelência. Ele sabia que para ser o melhor em quadra não bastava ser o cestinha, sabia que seu desempenho junto com a equipe levava as vitórias. Ganhar muito dinheiro e títulos(ou produtos para os devs) é a consequência de quem tem um objetivo muito maior, onde esse tipo de pessoa passa atrai o sucesso(nem sempre títulos) para o time, mesmo quando o time não tem o seu propósito muito bem definido.

Tudo que eu falei aqui vai de encontro com o que falei a 2 dias atrás que as tendências são suas aliadas, você como desenvolvedor que realmente é apaixonado pelo que faz consegue analisar ao seu redor e ver qual é a próxima tendência? vai fundo e mostre a todos que você tem total capacidade de ser um dos melhores, mas lembre-se, a primeira pessoa que tem que acreditar nisso é você.

• As tendências são suas aliadas
• Qual é a sua parte no produto final?
• (#soudev > #soudev) < (#soudev + #soudev)
• Faça o que está ao seu alcance!
• (Certificação && Faculdade) < Conhecimento

Não é surpresa para ninguém que acompanha o meu blog que trabalho mais atualmente com java e flex. Também não deve ser surpresa para ninguém que no final das contas trabalho muito na plataforma do Flash (que roda no Flash Player), em resumo estou no meio do fogo cruzado do futuro html5 e do condenado a morte Flash. Sempre evitei falar desse assunto aqui no blog mais achei por bem declarar algumas opniões, não da tecnologia x ou y, mas sim de qual deve ser sua posição como desenvolvedor.

O que vai acontecer com você se realmente matarem o Flash Player? 

não quero entrar no mérito de quando e como isso poderia acontecer, a pergunta é o que você tem feito para se preparar para próxima tendência. Essa é fácil de responder, a própria Adobe proprietária do flash te responde. além de ter o Flash CS você tem o Edge que tem o mesmo objetivo do FlashCS porém gera html5 + css3 + javascript. A adobe não quer saber quem vai sair vencedora desse duelo, o que interessa é que ela está preparada para qualquer uma delas. Você como desenvolvedor que quer estar sempre a frente e preparado para pegar uma fatia maior do mercado em um futuro próximo precisa ter essa consciência, dar valor em quem paga o seu salário e quem pode pagar ainda mais.

É apenas a próxima Tendência

O que quero dizer com isso, é que o flash morrendo ou não a próxima tendência que está chegando com força total é o html5, não porque é melhor que o flash mas sim porque foi escolhido por quem tem esse poder de descisão. Por favor, não se iludam, é apenas mais uma tendência, não se apegue a essa nova tecnologia. Vejo pessoas reconhecidas no mundo do flash que agora já são referência em html5, por quê? porque entenderam que podem usar essas tendências ao seu favor, é a famosa frase “dance conforme a música”.

Essa é a dica que dou para os desenvolvedores em geral, não se apegue a uma tecnologia, ferramenta ou metodologia, quando você se adaptar com html5 vai surgir algo que será melhor, assim foi com os paradigmas de programação, com as linguagens que aparecem por um tempo e  forão/são as tendências como Ruby e Python, com metodologias que já foi melhor RUP , depois Agile e agora está começando o Lean Startup. Não pense que isso é ruim, na verdade é inevitável, lembre que as tendências são suas aliadas e sempre nessas mudanças existe uma oportunidade para se ter um crescimento profissional de forma expoente.

“Tecnologia, Ferramentas e metodologia são o meio, dinheiro no bolso é o fim”

UPDATE: 11/11/11

Acho que a frase final poderia ser

“Tecnologia, Ferramentas e metodologia são o meio, sucesso é o fim”

Acho que cada um tem a sua definição de sucesso, muitas das vezes o dinheiro é a consequência por um bom trabalho mas não o fim desejado, todos querem a felicidade e a realização de suas metas e é essa sensação de dever cumprido que te faz acreditar que tentar ser o melhor em executar o “meio” te trará o sucesso desejado.

• Por que eu escolhi o Flex?
• Novidades para o projeto #soudev
• Faça o que está ao seu alcance!
• Experiência #fail com Scrum, XP e Pomodoro.
• #soudevcast 1 – O Futuro do Flex e Flash

Trago uma excelente notícia para vocês “flexeiros” hoje, se trata da primeira versão Release Candidate do Flexmojos 4, tenho a alegria de mostrar para vocês um pouco do que é possível fazer com o novo plugin e farei isso mostrando sua integração com o servidor contínuo Jenkins e o DashBoard de Métricas de código Sonar. Tudo isso graças as funcionalidades de rodar testes unitários do flex(flexunit 4) pelo maven e de gerar coverage dos testes no modelo do framework cobertura implementado no novo flexmojos 4.

Esse screencast será diferente do que normalmente faço aqui no blog que é ensinar passo a passo, dessa vez mostrarei o que é possível para que a comunidade comece a despertar interesse por esse magnífico plugin para maven chamado de Flexmojos.

então vamos ao screencast de Flexmojos 4 + Jenkins + Sonar:

então gostou? tenho certeza que sim e por esse motivo venho através desse post pedir a comunidade flex brasileira que nos ajude a dar continuidade ao Flexmojos. Para quem não sabe o Flexmojos foi criado por um brasileiro chamado Marvin Froeder (@velobr ) e praticamente ele vem mantendo o plugin desde o início, porém o plugin é usado muito no mundo inteiro, inclusive aqui no brasil em empresas corporativas como a petrobras. Sabemos que apenas uma pessoa fica impossibilitada de dar suporte e implementar novas funcionalidades que aparecem nas contantes atualizações da adobe no framework Flex e em sua IDE Flash builder.

Então quero fazer dois pedidos a vocês:

1. Aos grandes desenvolvedores java/flex desse país ajude o framework a crescer pensando e implementando novas funcionalidades ao mesmo. O Flexmojos há algum tempo é opensource e seu código se encontra no github https://github.com/flexmojos.
2. Segundo pedido é que vocês se cadastrem e votem nessa solicitação feita para adobe para assumir o suporte do flexmojos, não deveria ter outra empresa mais interessada na evolução desse framework que a própria Adobe , esse framework aumenta e muito a aceitação do flex em projeto cujo o backend é em java e traz o que falta e muito para o flex hoje, algo que ajude e facilite na integração do flex SDK com outros frameworks e ferramentas como mostrei nesse screencast para vocês. o link da solicitação A Flex/AIR/Flash Maven Plugin.

aí fica uma aguá na boca do que já é possível graças a esse plugin e também fica o apelo para que nos ajudem votando nessa solicitação para adobe

Até a próxima o/

• Retrospectiva 2011 e Metas 2012
• Adobe Photoshop CS5 – Criação de Interface para Flex 4
• AIR + SQLite = Simplicidade para coisas Simples
• o Tweetdeck não é mais Adobe AIR
• TUTORIAL JAVA + FLEX + IREPORT NA PRÁTICA (10)

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.

• Material do Flexmania e o #soudevcon
• TUTORIAL JAVA + FLEX NA PRÁTICA 4/6
• Swiz não é mais Framework MVC!
• Retrospectiva 2011 e Metas 2012
• MVC da teoria para a prática

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

Conhecendo o Swiz

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:

1. Ajuda no mapeamento de eventos tirando a necessidade de addEventListener para cada Evento disparado, isso tudo com o uso da metadata [EventHandler].
2. IOC(Inversão de Controle) containers e DI(Injeção de Dependências) sendo feito por metadata [Inject].
3. Utilitários como o ServiceHelper e ChannelSetHelper que ajuda na comunicação com serviços como WebService ,RemoteObject,etc…

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

Swiz na prática

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.

Mapeando os eventos

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:

• eventPackages – indica para o swiz onde estão nossos eventos customizados para quando informarmos o tipo no [EventHandler] ele saiba como tratar o mesmo.

• viewPackages – indica para o swiz onde estão nossas views que disparam os eventos.

Obs. Observe esse <config:Beans dentro do <swiz:beanProviders, vamos explicar e mostrar o source dele mais abaixo.

IOC containers e DI

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.

1. Aplicação inicia.
2. O Swiz pega esses objetos que você informou nesse container e instancia os mesmos. ex. contactdelegate = new ContactDelegateFake().
3. O Swiz vai procurar se tem algum [Inject] referenciando esse id informado no container e vai tentar injetar essa instancia que ele criou.

É 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.

Service Helper

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.

Conclusão

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.

• Swiz não é mais Framework MVC!
• TUTORIAL JAVA + FLEX NA PRÁTICA 5/6
• MVC da teoria para a prática
• TUTORIAL JAVA + FLEX NA PRÁTICA 3/6
• TUTORIAL JAVA + FLEX NA PRÁTICA (9) – Atualizando o Swiz

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.

• Tutorial Básico Swiz Framework 1.0
• Tutorial Spring ActionScript
• TUTORIAL JAVA + FLEX NA PRÁTICA (9) – Atualizando o Swiz
• TUTORIAL JAVA + FLEX NA PRÁTICA 3/6
• Resumo do #Flexdp e o #CafxFramework