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
