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 -~----------~----~----~----~------~----~------~--~---
