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 Sent: Sunday, November 22, 2009 8:11 PM To: flexdev@googlegroups.com 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 <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 -~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
