Exatamente: Componentizacao!
Deixar TUDO TUDO num mxml, com varios states e tal relmente deixa o código
um pouco complicado de manter depois, por isso a componentizacao ajuda
bastante.

No entanto, a preciosidade com essa parte (criar componente pra tudo e todos
e dominar o mundo com eles) também pode ser ruim, é uma faca de dois gumes,
ou melhor, uma balança muito sensível onde vc precisa ponderar até q ponto o
código está bom, facil e limpo.

Recomendo as seguintes leituras:
http://www.becklog.org/2009/08/06/ti-centrismo-vs-usuario-centrismo/
http://www.becklog.org/2009/08/31/trade-off-com-foco-no-valor-agregado/


Abraços.



Em 11 de maio de 2010 09:48, Helio Antonio Francisco Silva <
helio.afsi...@gmail.com> escreveu:

> Vou dar uma olhada quando chegar em casa do serviço nao da pra ver nada,
> tudo acess denied.
>
> 2010/5/11 bruno bg <bruno...@ig.com.br>
>
> Helio, lembra que falei sobre refatoração / desaclopamento do código.
>> Separação do MXML do ActionScript dos Eventos e etc
>> veja um exemplo 
>> simples<http://blip.tv/file/get/Becknovaes-RefatorandoAFlexFlickrApp828.mov>.
>>
>>
>> brunobg
>>
>>
>> Em 11 de maio de 2010 09:27, Helio Antonio Francisco Silva <
>> helio.afsi...@gmail.com> escreveu:
>>
>>  Claro concordo com o que você falo.
>>>
>>> mas como faço para separar o codigo das telas usar states nem rola fica
>>> um lixo o codigo e dificil de manipular.
>>> Transformo a tela em um componente ? e isso ?
>>>
>>> 2010/5/10 Mário Júnior <juninho...@gmail.com>
>>>
>>>> Vamos lá =D
>>>>
>>>>
>>>> *"A Mário não queria que voce me acha-se um chato e que como vim da
>>>> escola do flash, tenho enraizado esse conceito de separar as coisas em 
>>>> SWF."
>>>> *
>>>> Nao mano.. capaz!
>>>> Compreendo seu ponto de vista, e até concordo que em animações é melhor
>>>> ter tudo separado em swf mesmo. Por exemplo, em um hot-site, vc poderia ter
>>>> cada "pagina" um swf a parte. Agora, com Flex, não pensamos em "páginas". 
>>>> Tb
>>>> não é muito certo pensar em "telas", embora esse conceito está bem mais
>>>> relacionado a aplicacoes doq "páginas" propriamente ditas. Mas é normal
>>>> pensarmos em componentes, em contextos, em funcionalidades ou, mais ainda,
>>>> em casos de uso (use-cases).
>>>>
>>>> É possível separar cada funcionalidade em modulo a parte? Sim! Vc mesmo
>>>> já fez isso. Agora, compensa? IMHO não!
>>>> Daí vc me pergunta: "Pq?" Resposta: Pelo esforço desnecessário: Vc pode
>>>> até "achar q facilita" a sua vida de desenvolvedor, mas pensa no lado do
>>>> cliente: O cara ter q ficar carregando cada modulo a medida q vai usando a
>>>> app. Oras, vc pode criar o crud todo em uma única tela, não há necessidade
>>>> de criar modulo_list, modulo_insert_update, modulo_delete. Além do mais,
>>>> como vc mesmo disse, vc usa singleton para trafegar informacoes. Com um
>>>> unica tela, vc poderia usar um "data model" só. Bem mais simples, e bem 
>>>> mais
>>>> rapido para o usuario pq todas as funcionalidades da tela já estão ali.
>>>>
>>>> Além do mais, eu acho um pouco de preciosismo demais se preocupar com
>>>> cada kb carregado pelo usuário.
>>>> Como no exemplo, vc tem dois modulos de 30kb (dando total de 60kb) e uma
>>>> tela q com aplication vai dar, sei lá.. uns 70kb .. taca logo no swf
>>>> principal! :) ... isso representa oq para o usuario, talvez 1s ou 2s a mais
>>>> no carregamento?! Entao, será q vale todo o esforço de deixar um modulo a
>>>> parte, esperar compilar os modulos (vc percebeu q a compilacao com modulos 
>>>> é
>>>> mais lenta né) por causa de 10kb (menos de 1s de loading).... enfim, como
>>>> falei noutro e-mail "tamanho de aplicacao nunca fora minha principal
>>>> preocupacao". Temos muitas outras coisas para se preocupar, como a 
>>>> interface
>>>> com o usuario e a experiencia q ela proporciona ao usuario final.
>>>>
>>>> Enfim.. não sou chato nao :), talvez só nos preocupamos com coisas
>>>> diferentes.
>>>>
>>>> []s, fica na paz.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Em 10 de maio de 2010 15:15, Helio Antonio Francisco Silva <
>>>> helio.afsi...@gmail.com> escreveu:
>>>>
>>>>  A Mário não queria que voce me acha-se um chato e que como vim da
>>>>> escola do flash, tenho enraizado esse conceito de separar as coisas em 
>>>>> SWF.
>>>>>
>>>>> A ideia original eu coloquei, todo o CRUD de pedidos em uma so tela,
>>>>> mas como os states na minha opiniao sao ruins por que nao separam o 
>>>>> codigo,
>>>>> fico meio ruim de trabalhar, tinha algumas telas que precisavam de
>>>>> componentes, classes e outras coisas que que em outras telas nao 
>>>>> precisava,
>>>>> ai pensei po e se o cara so quiser inserir ? ele nao vai usar nenhuma 
>>>>> outra
>>>>> operação que tem varias coisas.
>>>>>
>>>>> Pensei eu, vo dividir cada operação em um "modulo " pra mim nada mais
>>>>> que um mero SWF 40k em vez de 150k bem ate entao ta carregando super 
>>>>> rapido,
>>>>> quando for uma empresa vai cair no cache o swf e todos os proximos 
>>>>> usuarios
>>>>> vao acessar bem mais rapido ( correto ), o codigo fica bem otimizado e
>>>>> agrupado.
>>>>>
>>>>> Por faor, nao to questionando o que voce me falo, so to colocando a
>>>>> minha visão, o que eu quero e compartilhar e aprender pra poder fazer um
>>>>> projeto bacana.
>>>>>
>>>>> Eu so fico mesmo cabreiro de fazer todas as funcionalidades num modulo
>>>>> por causa do codigo fica bem maior por que tenho de tratar varias
>>>>> particularidades.
>>>>>
>>>>> O que você acha ?
>>>>>
>>>>> 2010/5/10 Helio Antonio Francisco Silva <helio.afsi...@gmail.com>
>>>>>
>>>>> To usando o SDK 3.2 e o FP 10.1
>>>>>>
>>>>>>
>>>>>> 2010/5/10 Mário Júnior <juninho...@gmail.com>
>>>>>>
>>>>>>> essa de rodar o gc antes de remover é novidade pra mim tb...
>>>>>>> interessante.
>>>>>>>
>>>>>>> Qual sdk esta usando e qual a versao do player?
>>>>>>> O FP 10.1 release candidate ja está bem melhor nessa questao de
>>>>>>> memoria, vai ver as mudancas nessa parte ja comecaram.
>>>>>>>
>>>>>>> []s
>>>>>>>
>>>>>>>
>>>>>>> Em 10 de maio de 2010 13:58, Helio Antonio Francisco Silva <
>>>>>>> helio.afsi...@gmail.com> escreveu:
>>>>>>>
>>>>>>>  Valeu mario.
>>>>>>>> Eu pensei em desenvolver modulos para cada operação por que to
>>>>>>>> usando RSL e cada swf meu fica 40k a 60k , e pensei muito usuario so 
>>>>>>>> querem
>>>>>>>> inserir, ou vizualizar por que importar funcoes de excluir, editar e 
>>>>>>>> depmais
>>>>>>>> coisas ?
>>>>>>>>
>>>>>>>> essa foi a ideia inicial, mas vo repensar isso.
>>>>>>>>
>>>>>>>> Vou ver se pego o contato do pessoal da datasul.
>>>>>>>>
>>>>>>>> abração. e  brigadao pelo esclarecimento.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/5/10 Mário Júnior <juninho...@gmail.com>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Desenvolvedor Web
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Desenvolvedor Web
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Desenvolvedor Web
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Desenvolvedor Web
>>>
>>> --
>>> 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
>>
>
>
>
> --
> Desenvolvedor Web
>
> --
> 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

Responder a