"O que se perde com isso? Bom... os dados passados não são tipados no client. Mas, considerando-se que dados NÃO devem ser tratados no client (com raríssimas exceções), a tipagem não é grande problema aqui."
Pode parecer besteira a tipagem dos dados no servidor, mais este processo economiza muito trabalho na programação. * Eduardo Kraus* Desenvolvedor [email protected] blog.mxml.com.br www.twitter.com/EduardoKraus ADOTE ESTA CAMPANHA: 1. Apague o meu e-mail e o meu nome. 2. Apague também os endereços dos amigos antes de reenviar. 3. Encaminhe como cópia oculta (Cco ou Bcc) aos SEUS destinatários. Agindo sempre assim dificultaremos a disseminação de vírus, spams e banners. 2009/11/22 J.C.Ködel <[email protected]> > Nop. Não é o Fluorine =) > > É algo beeeeeeeeeem simples: > > O Flex me manda um XML compactado via ZLib via Http Request (como se fosse > um upload de arquivo), eu vejo o tipo de XML e chamo um método que cuida > deste, que por sua vez me responde com um XML que envio de volta compactado. > > O FireBug deve permitir ver como as coisas funcionam. > > Como é algo bem fechado (ou seja, as ações que o framework retorna são > finitas), e é tudo baseado em XML, não preciso ter nenhum overhead. > > Tirando os cabeçalhos do HTTP e a linha de GET, o protocolo não possui > nenhum overhead. > > Em resumo: é um simples XML HTTP Request, só que compactado e utilizando > streams de conteúdo ao invés de cabeçalho para os dados. > > O que se perde com isso? Bom... os dados passados não são tipados no > client. Mas, considerando-se que dados NÃO devem ser tratados no client (com > raríssimas exceções), a tipagem não é grande problema aqui. > > Quando houver regras de negócio (que serão tratadas no lado server) aí os > eventos dão liberdade de persistência ao programador (ou seja, pode usar > Linq to Sql, ADO Entities, nHibernate, whatever) > > *From:* Eduardo Kraus <[email protected]> > *Sent:* Sunday, November 22, 2009 8:45 PM > *To:* [email protected] > *Subject:* [flexdev] Re: Novo framework > > O Fluorine eu trabalho com ele há um ano e nunca me deixou na mão no > que se trata de AMF. Agora para RTMP ele simplesmente é ruim. Mais AMF é > muito bom. > > Pelo link e pelo erro me parece ser FluorineFX. > *http://www.kodelsolutions.com/Maya/Gateway.aspx* > * > Eduardo Kraus* > Desenvolvedor > [email protected] > blog.mxml.com.br > www.twitter.com/EduardoKraus > ADOTE ESTA CAMPANHA: > > 1. Apague o meu e-mail e o meu nome. > 2. Apague também os endereços dos amigos antes de reenviar. > 3. Encaminhe como cópia oculta (Cco ou Bcc) aos SEUS destinatários. > Agindo sempre assim dificultaremos a disseminação de vírus, spams e > banners. > > > 2009/11/22 J.C.Ködel <[email protected]> > >> O protocolo aqui é o de menos. >> >> AMF é legal, mas necessita de um server (sei que existe o Fluorine e o >> WebOrb para .net, mas o Fluorine não é lá muito bom e o WebOrb é pago para >> fins comerciais) e o principal: não é genérico. Preciso de algo que seja >> genérico (não preso aos dados que o meu aplicativo opera) e que seja >> extensível. >> >> *From:* Mário Júnior <[email protected]> >> *Sent:* Sunday, November 22, 2009 8:11 PM >> *To:* [email protected] >> *Subject:* [flexdev] Re: Novo framework >> >> Fiquei curioso de uma coisa... o AMF já é compactado - nao com Zlib - >> pra q criar outro protocolo? >> Ou ainda q o AMF nao use Zlib naturalmente, ainda é possivel compactá-lo >> usando zLib... entao, pq um novo protocolo e nao entao compactar o AMF??? >> >> >> []s. >> >> 2009/11/22 J.C.Ködel <[email protected]> >> >>> Olá povo! >>> >>> Vou apresentar aqui um brinquedinho novo em que venho trabalhando. O >>> intúito é ver se ele seria útil para outras pessoas (no caso abriria o >>> código-fonte no CodePlex) e ter uma ajuda quanto à idéias, recursos, etc. >>> >>> Então, comecemos do começo: >>> >>> O intuito é fazer um framework que faça de tudo com o mínimo de esforço >>> do programador. Queries, transferência de dados, grids, paginação, >>> autenticação, enfim, o máximo de componentes inteligentes que resolvam os >>> problemas comuns de um aplicativo, deixando o programador livre para >>> programar o aplicativo em si, e não sua infraestrutura. >>> >>> Um pequeno demo pode ilustrar isso com mais detalhes: >>> http://www.kodelsolutions.com/Maya >>> >>> No demo vemos uma janela de autenticação, com possibilidade de criação de >>> novas contas, disparo de e-mails e recuperação de senha, além da escolha de >>> linguagem utilizada no aplicativo e troca de senha. >>> >>> O aplicativo demo em si possui apenas 2 componentes neste ponto: >>> AuthenticationWindow e ChangePasswordWindow. Ele consegue fazer toda a parte >>> de autenticação, criação de contas etc. com apenas um componente, que é >>> customizável (o logo do aplicativo, os botões que aparecem, até as abas que >>> aparecem). >>> >>> O client (Flex neste exemplo, mas a idéia é fazer clients também em AIR e >>> Silverlight) comunica-se com um servidor em .net que trafega as requisições >>> em um protocolo hyper leve, compactado via zLib. O protocolo por sí só já >>> economiza aproximadamente 90% do que uma chamada à web service, por exemplo, >>> utilizaria. Não contente com isso, o protocolo ainda é compactado usando >>> zLib, que pode fazer com que os dados trafegados fiquem com apenas 30% de >>> seu tamanho original. Ou seja, a comunicação via rede entre o servidor e o >>> client gasta infinitamente menos banda do que qualquer tecnologia que existe >>> hoje em dia, exceto socket (que, como sabemos, nem sempre é possível usar, >>> ainda mais em provedores externos, como o meu GoDaddy, que bloquearia as >>> portas). >>> >>> Como funciona isso? Até agora, o esquema é o seguinte: >>> >>> 1) O client pergunta pro server "Ô, tio, quem sou eu?". O server então >>> aciona uma dll do seu aplicativo que customizará algumas das ações do >>> framework. Neste ponto, ele retorna o nome do aplicativo, sua versão e as >>> linguagens disponíveis (inglês, português, etc.). >>> >>> 2) O client está customizando a janela de autenticação com um logotipo e >>> permitindo o acesso a todas as abas do componente de autenticação (logo, na >>> janela de autenticação, o único trabalho do programador é colocar o logotipo >>> em uma propriedade, o resto ele faz sozinho). >>> >>> 3) Então o usuário tenta criar uma nova conta. O client fala pro server >>> "Esse cara com estes dados tá querendo criar uma conta nova". O server então >>> dispara um evento para o teu aplicativo dizendo isso. Teu aplicativo neste >>> ponto pode ou não implementar este evento. Se implementar, então ele é o >>> responsável por todo o processo de criação de conta, do jeito que o >>> programador quiser. Mas, se não quiser trabalho, o aplicativo simplesmente >>> não processa o evento. Neste ponto, o framework diz "Ok. Vou cuidar disso eu >>> mesmo". E utiliza um recurso interno para criação de contas (que, no caso, é >>> o ASP.Net SQL Membership), criando a conta e criando um e-mail de >>> confirmação. A idéia sempre será essa: permitir ao aplicativo fazer tudo o >>> que o framework faz mas, se não quiser, o framework sempre conterá uma forma >>> "genérica" de se fazer algo. >>> >>> 4) O e-mail de confirmação é outro evento do teu aplicativo (este é >>> obrigatório consumir). Ele vai pegar a linguagem que o usuário selecionou e >>> montar uma mensagem contendo as informações da conta. Devolve-se esta >>> mensagem para o framework e ele se encarrega de colocar numa lista de >>> e-mails pendentes de envio e os envia assim que a lista for processada >>> (automaticamente). Todo o restante do processo de criação de contas corre >>> pelo servidor agora, até o momento em que a conta for realmente criada onde, >>> novamente, é disparado um evento para o teu aplicativo que, se não o >>> consumir, deixa o framework criar a conta usando o processo interno. >>> >>> 5) Tudo funcionaria basicamente da mesma forma: para toda ação possível >>> do framework, ele implementaria uma solução pré-pronta. (Ex.: um datagrid >>> que obtem dados de uma view onde, no Client, o datagrid teria apenas uma >>> propriedade: o nome da view/método que obtém os dados). Se o teu aplicativo >>> não consome o evento, o framework faz o trabalho por você (isso serve apenas >>> para poder customizar o aplicativo). Mas, se teus dados vierem de um >>> web-service, por exemplo, sem problemas. Para aquela view em específico, >>> você consome o evento e lida com os dados por si mesmo (desde que devolva ao >>> framework utilizando um XML que é protocolizado). >>> >>> 6) Uma vez autenticado, o framework pede o menu principal (presume-se que >>> todos os aplicativos tenham a mesma cara, porém, uma vez que o menu é um >>> XML, nada impede do client implementá-lo como uma árvore, por exemplo, ao >>> invés de uma barra de menus). >>> >>> Toda a comunicação entre o client e o server é feito com chaves de >>> tradução, ou seja, no menu, o server não passa a palavra "Mudar senha", mas >>> sim uma chave "{ChangePassword}" que o client traduzirá, dependendo da >>> linguagem escolhida no logon (mais ou menos como o sistema de localização do >>> Flex, porém os dados vêm do servidor ao invés de serem compilados no client, >>> permitindo a adição de outras linguagens no futuro). >>> >>> O demo só permite autenticar, criar contas, recuperar senha, logar-se, >>> mudar a senha atual e deslogar-se, porém, conforme ele for se desenvolvendo, >>> tudo será feito a partir do mesmo princípio (atualmente o MXML possui 30 >>> linhas e o ActionScript umas 35. No lado server, está tudo automático. Pra >>> não falar que ele não faz nada, ele monta o corpo dos e-mails e carrega os >>> arquivos de linguagens a partir de um txt simples, dependendo da linguagem >>> escolhida pelo usuário). >>> >>> Os Alerts bonitinhos, os efeitos, tudo isso é incorporado no framework, >>> então o usuário precisa somente chamar: MsgBox.show(MensagemOuChaveTradução, >>> function(dialogResult:int){}, MsgBox.CRITICAL | MsgBox.YES_NO, "Título"); >>> >>> Os próximos passos serão: >>> >>> 1) Um datagrid com paginação e um filtro de pesquisa avançado, onde a >>> única coisa que o programador precisa fazer é definir o método que >>> preencherá os dados. Se não for customizado, o framework sozinho irá até a >>> tabela que o grid definiu, irá filtrá-la, paginá-la e montar o grid final na >>> tela. Grids serão tão fáceis quanto fazer uma view no SQL e setar o nome >>> desta view no componente DataGrid. Este componente será mais aprimorado que >>> o datagrid original e terá um painel à esquerda onde o usuário poderá montar >>> filtros complexos (ex.: Preço de Custo maior que 10 e menor que 20) e com >>> suporte à paginação (sem que precise-se programar nada pra isso). >>> >>> 2) Um formulário mais inteligente, com múltiplas colunas, componentes >>> melhores (autocomplete, masked textbox, etc.), com validações automáticas, >>> etc. Feito em XML. Assim, o programador somente irá desenhar o form de uma >>> forma bem simples usando XML (ex.: <Field source="Name" label="{Name}" >>> maxLength="32"/>) e o client irá desenhar um form completo, com validação, >>> ajuda, componentes mais inteligentes, etc. Sem que nada seja programado pelo >>> programador. >>> >>> >>> Atualmente ele está sendo desenvolvido em VB.Net 9 usando ASP.Net, MSSQL >>> 2008 e o primeiro client em Flex. >>> >>> A idéia final é fazer tanto vários clients (Flex, AIR, Silverlight, >>> Windows Forms, WPF) quanto vários servers (.net, Java, PHP) e várias bases >>> (MSSQL, MySQL, FireBird, PostGre). >>> >>> O que acham? >>> >>> >>> P.S. 1: Será open-source? Vou usar o conceito de torrent pra decidir >>> isso: se só ouverem "leechers", não. Se houver pessoas que desejam de fato >>> ajudar, sim. >>> >>> P.S. 2: Criei conta mas meu e-mail não chegou. Poisé... coisas da >>> GoDaddy... demora um século pra enviar e-mail =( Mas uma hora chega ;-) >>> >>> ------------------------------ >>> *J.C.Ködel - Programador Microsoft.net/Adobe Flex* >>> *TDS-Enterprise - http://www.tds-enterprise.com* >>> >> >> >> >> -- >> Mario Junior >> Enterprise Java / Flex Architectures >> Adobe Certified Expert Flex 3 with AIR >> >> Sofshore Informática >> http://www.sofshore.com.br >> +55 (48) 3337 2003 >> Rua Pastor Willian Richard Schisler Filho 452 sl 102, 88034-100 Itacorubi >> Florianopolis SC Brasil >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
