Recentemente, estou em contato com um projeto que utiliza a micro-arquitetura Cairngorm e o padrão ModelLocator de uma forma bem responsável. Isso me motivou a escrever esse post e reconsiderar a necessidade do uso do padrão ModelLocator em minhas aplicações Cairngorm, ou pelo menos ter muito mais cuidado ao utilizá-lo.
Leia o artigo completo »

Esse negócio de POG é uma coisa engraçada. Vejo as pessoas muito preocupadas com este tal uso dos colchetes, por exemplo. Bem, penso eu que existem inúmeras outras coisas mais importantes para se preocupar. Não que o uso da notação de colchetes indiscriminada não deva ser alertada. Mas o impacto que isto pode ter no código é bem menor, por exemplo, do que usar o Command do Cairngorm ou do PureMVC APENAS para fazer uma simples chamada no Back-end e armazenar o resultado em algum “model” no Front-end. Notem a importância da palavra “APENAS”. Se você tem uma aplicação com mais de 5 Commands e eles só fazem isso são boas as chaces de você não precisar de fato de uma Microarquitetura robusta como o Cairngorm/PureMVC ou de você estar subutilizando o Command. E eu não vejo quase ninguém discutindo isso.

Leia o artigo completo »

O uso de validação de formulários do lado do cliente é uma pratica muito comum em aplicações web, para não haver inconsistência nos dados quando forem enviados para a base de dados.

Bem, esses dias em visita a um dos nossos clientes deparei com um problema que ele estava tendo com validação de uma classe extendida do TextInput. Só que essa nova classe seria base para outras classes de Input do sistema, que necessitavam de validação para números, data, hora ou qualquer outro campo de inserção de dados. A solução encontrada foi bem simples, porém bem interessante, pois sempre estamos usando classes associadas como TextInput e Validator. Então porque não utilizamos uma class TextInput que já contenha o Validator e deixamos subclasses decidirem qual classe instanciar do validator? Isso mesmo, este é o conhecido Factory method pattern.

Veja com ficou o diagrama de classes:

Leia o artigo completo »

Como visto em posts anteriores sobre Flex e o MVC , podemos dizer que o framework PureMVC vem evoluindo muito bem, já consegue atender 10 tipos de linguagens diferentes, com 2 versões diferentes para as3, a Standard e a Multi-Core que propõe atender a programação modular (flex modules).

Leia o artigo completo »

O Cairngorm é o carro chefe dos frameworks para a plataforma Flex. Há quem diga que é o framework que todo desenvolvedor flex deve conhecer. E de fato o é. Ele é simples e intuitivo, e é também suportado pela Adobe. Por todos esses motivos é o mais utilizado no mercado. Bom é que ele não é o único.

Dentre os frameworks para a plataforma Flex em desenvolvimento atualmente, um deles vem se tornando cada vez mais popular. Me refiro ao PureMVC, visto ter sido citado como “vencedor” em uma comparação de frameworks (ao todo, 9) para o Flex e desde então só tem aumentado seu número de interessados.
Leia o artigo completo »

O conceito de Mock foi bastante utilizado nos projetos do Rio de Janeiro. A idéia é bastante interessante para criarmos uma abstração da camada de backend, permitindo que o desenvolvimento Flex possa andar em paralelo e independente desde que o contrato backend/frontend esteja bem definido. Além disto podemos também garantir um processo de integração mais eficiente.

Leia o artigo completo »

Duas novidades rápidas: O Flex 2.0.1 está em Alpha com uma boa quantidade de bugs corrigidos e Steven Webster anunciou o Cairngorm 2.1, com algumas implementações, a principal relativa ao setCredentials(). Ele anunciou também planos futuros de ter um Cairngorm Mobile Edition e um Cairngorm Enterprise Edition, baseados em um core do Cairngorm.