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 < [email protected]> 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 <[email protected]> > > To usando o SDK 3.2 e o FP 10.1 >> >> >> 2010/5/10 Mário Júnior <[email protected]> >> >>> 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 < >>> [email protected]> 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 <[email protected]> >>>> >>>> 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 <[email protected]> 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 >>>>>> [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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> [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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Desenvolvedor Web >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 [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 >>> >> >> >> >> -- >> Desenvolvedor Web >> > > > > -- > Desenvolvedor Web > > -- > 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 > -- 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 [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
