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
Sent: Sunday, November 22, 2009 8:45 PM
To: flexdev@googlegroups.com
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
eduardokr...@gmail.com
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 <jcko...@gmail.com>
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
