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 <jcko...@gmail.com> > 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 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 -~----------~----~----~----~------~----~------~--~---
