aê Mario Jr , é um bom artigo a ser publicado no BLOG.
PS: você ainda "assina" seus post com o blog que está desativado.!

abraço
bruno bg


Em 10 de maio de 2010 13:50, Mário Júnior <juninho...@gmail.com> escreveu:

> Semana passada dei aulas sobre Modulos na minha turma de Flex no curso da
> e-Genial, vou colocar aqui algumas considerações (nada muito diferente doq
> ja foi dito)
>
> a) procure contextualizar seus modulos em sub-sitemas.
> Por exemplo: Seu sistema principal tem área de "Estoque" e "Financeiro".
> Entao, crie dois modulos para cada área, onde TUDO oq for relativo a Estoque
> fique dentro de seu respectivo modulo, assim como no financeiro, relatorios,
> etc.
>
> Obviamente q isso requer uma analise melhor do seu projeto como um todo.
>
> b) Se um modulo for "exclusivo" daquela app, entao utilize a otimizacao.
>
> c) Criar um modulo para cada operacao é um tiro no pé. Vc facilita a sua
> vida de programador (organizacao do codigo e tal) mas complica pro usuario
> ter q toda hora ficar carregando um swf a mais. Lembre-se q o ModuleLoader
> extends de SWFLoader, portanto carregar diferentes modulos para cada tela é
> totalmente desnecessário e muito mais pesado.
>
> d) Para fazer comunicação de dados entre Modulos => App use
> parenteApplication. Ja entre Modulos => App => OutroModulo dispare eventos e
> faça seus modulos implementar uma interface em comum que será o acessor da
> Application poder acessar o modulo destinatario.
>
> e) Nesse caso de comunicacao por eventos, use listeners com referencia
> fraca (weakReference=true). Também, sempre remova os listeners qnd puder.
>
> f) Nao reaproveitar ModuleLoaders (isso é interessante). Usar um
> moduleLoader para cada Module é mais performatico doq reaproveitar o mesmo
> moduleLoader para carregar varios Modules (isso tb é um misterio :S).
> Obviamente q nao se esqueça de destrui-lo depois q nao precisar mais do
> modulo.
>
> g) terminou de usar o module e matou o seu module loader, entao pede pro gc
> te dar uma força =D (faça a pesquisa q a gabi recomendou e veja as tecnicas
> para isso, incluindo a do LocalConnection q é um grande misterio =P)
>
>
> Obviamente q tudo isso ainda nao irá resolver totalmente a questao, mas
> ajuda bastante. Recomendo a leitura do e-mail deste email (repare na data:
> http://groups.google.com.br/group/flexdev/browse_thread/thread/d177cfe63c56c4ad?fwc=1&pli=1)
> e tb o link q ele sugere no proprio email.
>
> Outro documento importante sobre "Sub Applications" é esse, extremamente
> recomendado, onde é falado sobre o Marshal Plan:
> http://livedocs.adobe.com/flex/3/loading_applications.pdf
>
>
> Vamos ver agora no FP 10.1 final como isso será tratado. Me parece q vi
> (senao me engano foi no proprio bug jira da adobe) q isso será totalmente
> resolvido... tomara.
>
> Mas enfim, em dois grandes projetos q trabalhei com modulos, na boa,
> problemas de memoria era oq menos me preocupava.
>
>
> []s
>
>
> (Ps: Vi q esta desenvolvendo para a Totvs né? Recomendo vc conversar com a
> galera fera de Flex q fica em Joinville-SC - q ja trabalhavam na Datasul -
> eles podem te ajudar bastante. Procure pelo Arian, Diefrei e tem tb o Fabio
> Gol, mas esse ultimo acho q ja nao trabalha mais na Totvs. Tem muita gente
> boa la q pode te ajudar.)
>
>
>
>
>
> Em 10 de maio de 2010 12:56, miso <miso...@gmail.com> escreveu:
>
>> Olha Helio, não se desespere, jajaja...
>>
>> Minha humilde recomendação, e que não faça seus módulos dentro de um só
>> projecto, ainda mais se tem vários módulos.
>> Porque, francamente, não faz muito sentido no caso do flex,  a distribuição 
>> de
>> peso e terrível, cai tudo sobre o aplicação principal e se perde o
>> conceito de distribuição de carga.
>> Posso apostar que sua aplicação principal está com um tamanho enorme e
>> seus módulos muito pequenos em comparação.
>>
>> A melhor jogada é:
>> - criar um  projeto commons para as classes em comun
>> - agregar no build path do app principal o projeto commons como RSL
>> - fazer cada modulo em um projeto separado, só dele, e setar no build-path
>> como 'external' o seu projeto commons
>> - a o facer o release final do seu sistema, gerar um link report do seu
>> app principal introduzindo *-link-report=C:\report.xml *no compiler
>> - e por ultimo, em cada modulo, agregar no compiler *
>> -load-externs=report.xml**. *(depois de copiar o xml gerado, no root de
>> cada projeto). Isto irá prevenir que cada módulo recarga as classes que
>> já estão carregadas no aplicativo principal.
>>
>> como falou o @bruno, em módulos, cada caso e um caso...
>>
>> bom, tai...
>>
>>
>> --
>> La alegría se multiplica, cuando la dividimos
>>
>> --
>> Você recebeu esta mensagem porque está inscrito na lista "flexdev"
>> Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com
>> Para sair da lista, envie um email em branco para
>> flexdev-unsubscr...@googlegroups.com
>> Mais opções estão disponíveis em http://groups.google.com/group/flexdev
>>
>
>
>
> --
> Mario Junior
> http://blog.mariojunior.com/
> @mariojunior
>
>  --
> Você recebeu esta mensagem porque está inscrito na lista "flexdev"
> Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com
> Para sair da lista, envie um email em branco para
> flexdev-unsubscr...@googlegroups.com
> Mais opções estão disponíveis em http://groups.google.com/group/flexdev
>

-- 
Você recebeu esta mensagem porque está inscrito na lista "flexdev"
Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com
Para sair da lista, envie um email em branco para 
flexdev-unsubscr...@googlegroups.com
Mais opções estão disponíveis em http://groups.google.com/group/flexdev

Responder a