***** Desculpem as mensagens repetidas pessoal. Precisei fazer umas edições no post. Portanto, considerem o ultimo (e prometo que este é o ultimo)
Bem, seria necessário escrever bem mais do que estou disposto no momento, mas espero que algumas coisas fiquem subentendidas nas entrelinhas. 1. Se você ainda não enxerga os benefícios do Cairngorm é porque não se deparou com os problemas que ele resolve (de fato, talvez você não tenha mesmo estes problemas). Houve uma época em que o pessoal parou completamente de usá-lo aqui na DClick e isto está trazendo muitos problemas nos projetos que estão sem ele. Pelo menos hoje as pessoas entendem o por que de cada um dos Patterns do Cairngorm. 2. Frameworks robustos não são simples. De fato, são complicados. Exige um bom conhecimento de Design Patterns (conseqüentemente OOP) e experiência com outros problemas que os desenvolvedores criadores do Framework tiveram. 3. O Framework é um ponto de partida e ele sozinho não será a solução do seu problema. Algumas vezes as pessoas rejeitam determinados Frameworks pelo "desalinhamento" que existe entre os conceitos e problemas conhecidos das pessoas que desenvolveram o Framework e os problemas e conceitos conhecidos das pessoas que o utilizam. 4. Alguns dos problemas do Cairngorm são efeitos colaterais de algumas de suas vantagens. Ao implementar o Cairngorm o pessoal procurou tirar máximo proveito de funcionalidades específicas do Flex como o DataBinding. Isto fácil atualizar a View com dados, mas tornou difícil encontrar algumas soluções para problemas sem infringir o MVC. Como mostrar uma mensagem na View a partir do Command sem ter que acessar a View diretamente? O problema neste caso é que o DataBinding substituiu o Design Pattern Observer geralmente usado nas implementações do MVC. Mas nem sempre o que as pessoas querem é fazer simplesmente Binding. E usar o Binding como Observer está mais para hack do que para solução num Framework. 5. Eu prefiro o Cairngorm ao PureMVC, mas isto exigiria uma explanação mais detalhada para deixar claros os meus motivos (perdoem a preguiça momentânea). []'s Beck Novaes On Oct 30, 9:45 am, LeonardoW <[EMAIL PROTECTED]> wrote: > Obrigado pela ajuda! > Realmente não consegui ver utilidade do cairngorm no meu projeto, que > já está pronto e em produção. > A impressão que deu é que utilizando-o só ia aumentar meu > trabalho...criar muitas classes a mais e ter um refactoring muito > grande e ainda > me surgiu essa dificuldade/dúvida descrita no email anterior. > A única coisa que estou utilizando é o modelLocator, mas apenas em > ocasiões específicas. > Minha idéia era estudá-lo para utilizar nos futuros projetos e também > para ver se eu obtinha um melhor consumo de memória pelo reuso de > componentes. > No mais fiz um estrutura da seguinte forma, cada tela (mxml) tem um > "handler" (.as) que adiciona e remove os eventos, inicializa os > campos, também contém os métodos responsáveis pelas lógicas > envolvidas, que são chamados pelos eventos quando necessários. Toda > tela tem o seu "handler" que é criado no creationComplete do mxml. > Tenho um treeMenu na lateral que abre as telas. Minha app sempre > remove todos os eventos e telas ao clicar em um menu novo, gerando um > pequeno acumulo de memória usada pelo flashplayer, nessa app isso não > tem muito impacto, mas nas futuras aplicações vou ter que mudar essa > lógica e pelo que andei estudando, vou ter que manter as telas já > carregadas eliminando a existência de objetos sem referencia mas que > continuam ocupando a memória. > Já aproveitando gostaria de saber como você está trabalhando para ter > o menor consumo de memória e desempenho possível. > Vou dar uma estudada nesse swiz. > > []´s > > On 30 out, 09:57, "Mário Júnior" <[EMAIL PROTECTED]> wrote: > > > O Cairngorm ganhou fama por ter sido a primeira proposta de micro > > arquitetura para desenvolvimento com Flex, e ganhou apoio da Adobe, MAS nem > > por isso é a melhor solução. > > Um dos pontos cruciais que deixam a desejar no Cairngorm: > > > - Falta de sensibilidade da View em tratar respostas vindo do servidor > > (result e false). > > - Não há reaproveitamento de Commands (fazer com switch? afff...) > > - ModelLocator tende a ficar inchado > > - Events desnecessários e repetitivos (isso já até alterei e fiz uma forma > > melhor trabalhando com eventos dinâmicos) > > > Se vc seguir o "padrão Cairngorm", relamente terá q fazer isso: dados do > > result devem ser jogados no modelLocator e o view conhece APENAS o > > modelLocator. Com o tempo, vc vai perdeber q o seu modelLocator vira um > > "repositório de variáveis" e, por ser singleton, terão o escopo por toda a > > aplicação assumindo um papel de variáveis "globais" oq é horrível - no meu > > ponto de vista. > > > Caso queire, ou necessite, trabalhar como seu objeto - aplicar alguma lógica > > sobre ele, etc.. - terá q fazer isso dentro do VO ou no result do command. > > > Por fim, acharia melhor vc começar a pesquisar por outros FWs como o Mate > > Framework ou um outro q conheci há pouco tempo e gostei muito: Swiz > > Framework (coincidentemente tem a mesma idéia do EloFlex, fw q estava > > desenvolvendo para a Elotech) com injeção de Dependências e dinamismo por > > Meta-Tags (estilo annotations do spring). > > > Aqui no site do Ted Patrick, tem um vídeo de 1h sobre o swiz. dê uma olhada > > (não preciso dizer q é inglês né) > > >http://www.onflex.org/ted/2008/09/360flex-sj-2008-introduction-to-swi... > > > Como sempre, essa idéia que tenho sobre o cairngom representa apenas minha > > opinião pessoal... Antes de tudo, sempre vale a boa análise e o bom senso. > > Se o seu projeto já foi iniciado com o Cairngorm, então continue com ele há > > menos q vc tenha prazo suficiente para investir em aprendizado no swiz > > (muito simples de entendê-lo) e migrar tudo oq já fez com o cairngorm para o > > novo fw. > > > Abraços e bons estudos. > > > -- > > Mário de Souza Júnior > > Programador Java / Adobe Flex > > (44) 4009-3550 Maringá-PRhttp://blog.mariojunior.com > > [EMAIL PROTECTED] (gtalk, msn, etc..) --~--~---------~--~----~------------~-------~--~----~ Você recebeu esta mensagem porque está inscrito na lista "flexdev" Para enviar uma mensagem, envie um e-mail para [email protected] Para sair da lista, envie um email em branco para [EMAIL PROTECTED] Mais opções estão disponíveis em http://groups.google.com/group/flexdev -~----------~----~----~----~------~----~------~--~---
