Me desculpando cair de para-quedas no assunto... ainda mais porque uso .net server side e não Java mas...

Como disse em um e-mail anterior, eu estou usando Flex em todos os projetos onde normalmente usaríamos aqui ASP.Net. E o drama é o mesmo: como fazer CRUD (ou mesmo business server-side) com performance e de forma fácil usando uma camada servidora. Web Services não é a resposta (muito verboso o protocolo SOAP e gerar proxies para cada alteraçãozinha é um pain in the ass).

Desenvolvi várias coisinhas para ajudar isso, inclusive um sistema de web services binário (compactado com zLib), o que me reduziu em 60% o tráfego de rede, especialmente para transferência de grids, aliado a isso o fato do transporte ser em XML e eu não precisar de fato tipar as entidades de transporte (embora isso seja um absurdo do ponto de vista OO, é uma mão na roda do lado da produtividade, já que posso programar genericamente ao invés de programar cada entidade separadamente).

Cheguei até a usar o ASP.MVC adaptado para trabalhar com o Flex mas, apesar do Linq ser uma ótima tecnologia, fica complicado quando, por exemplo, um filtro dinâmico é aplicado no lado client... programar cada aspecto da camada de modelo para cada caso de visualização pra mim não é uma boa (a grande parte do desenvolvimento estaria envolvendo modelos de dados, ao invés da business do meu projeto, que é o que me faz chegar no objetivo do aplicativo).

Também testei o WebOrb (que é disponível para Java também). Achei até interessante o fato de poder chamar métodos puros do servidor no client, porém a idéia de camada de dados deles é meio estranha (eu acho que nunca faria um aplicativo que lidasse com base de dados diretamente no client). E também achei meio lerdo demais =\

De qualquer forma, não achei nada interessante para fazer transferência de dados e persistência de uma forma que fosse fácil de usar, rápida e genérica (no sentido de eu não precisar, por exemplo, fazer cada método C, R, U e D para cada entidade), por isso, estava com uma idéia que está anexada no documento em anexo.

[As partes desta mensagem que não continham texto foram removidas]

A lista nao permite anexos (potencial disseminação de virus).
Vc pode publicar o seu arquivo direto no repositorio de arquivos da lista e
daí quem se interessar pode ir lá e fazer o download (é publico), em
http://br.groups.yahoo.com/group/flex-brasil/

[]s.

2009/11/10 J.C.Ködel <jckodel@gmail.com>

>
>
> Me desculpando cair de para-quedas no assunto... ainda mais porque uso .net
> server side e não Java mas...
>
> Como disse em um e-mail anterior, eu estou usando Flex em todos os projetos
> onde normalmente usaríamos aqui ASP.Net. E o drama é o mesmo: como fazer
> CRUD (ou mesmo business server-side) com performance e de forma fácil usando
> uma camada servidora. Web Services não é a resposta (muito verboso o
> protocolo SOAP e gerar proxies para cada alteraçãozinha é um pain in the
> ass).
>
> Desenvolvi várias coisinhas para ajudar isso, inclusive um sistema de web
> services binário (compactado com zLib), o que me reduziu em 60% o tráfego de
> rede, especialmente para transferência de grids, aliado a isso o fato do
> transporte ser em XML e eu não precisar de fato tipar as entidades de
> transporte (embora isso seja um absurdo do ponto de vista OO, é uma mão na
> roda do lado da produtividade, já que posso programar genericamente ao invés
> de programar cada entidade separadamente).
>
> Cheguei até a usar o ASP.MVC adaptado para trabalhar com o Flex mas, apesar
> do Linq ser uma ótima tecnologia, fica complicado quando, por exemplo, um
> filtro dinâmico é aplicado no lado client... programar cada aspecto da
> camada de modelo para cada caso de visualização pra mim não é uma boa (a
> grande parte do desenvolvimento estaria envolvendo modelos de dados, ao
> invés da business do meu projeto, que é o que me faz chegar no objetivo do
> aplicativo).
>
> Também testei o WebOrb (que é disponível para Java também). Achei até
> interessante o fato de poder chamar métodos puros do servidor no client,
> porém a idéia de camada de dados deles é meio estranha (eu acho que nunca
> faria um aplicativo que lidasse com base de dados diretamente no client). E
> também achei meio lerdo demais =\
>
> De qualquer forma, não achei nada interessante para fazer transferência de
> dados e persistência de uma forma que fosse fácil de usar, rápida e genérica
> (no sentido de eu não precisar, por exemplo, fazer cada método C, R, U e D
> para cada entidade), por isso, estava com uma idéia que está anexada no
> documento em anexo.
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>

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

[As partes desta mensagem que não continham texto foram removidas]

O Pimento é legal mesmo, só tenho medo doq eu disse no começo de da thread:
"cuidado em expor regras de negocio na view" ... lembrem-se q SWF é
facilmente descriptografado.

Com essa ideia em mente, acho q o TIDE (do GraniteDS) é bem mais
interessante e "transparente", vejam um simples exemplo:
http://java.dzone.com/articles/migrating-classical-jee-web-ap

Pra quem curte Grails (groovy), tem um plugin do TIDE para Grais que é
simplesmente a-n-i-m-a-l.
Agora, pq eu não uso TIDE em todas as minhas apps ou pq eu ainda sou fã do
BlazeDS?
Apoio e denvolvimento da Adobe, arquitetura lightware, fácil
extensabilidade, maior adoção da comunidade oq me permite acreditar ter
menos bugs e mais documentação/links/blogs/ajuda/whatever ...

A real é q depende de cada projeto a adoção entre BlazeDS ou GraniteDS, no
entanto reforço q o GraniteDS evoluiu muito de um tempo pra cá, Frank Wolf e
seus colegas tem feito um excelente trabalho.

Congrats Frank.

2009/11/10 Mário Júnior <juninhog12@gmail.com>

> A lista nao permite anexos (potencial disseminação de virus).
> Vc pode publicar o seu arquivo direto no repositorio de arquivos da lista e
> daí quem se interessar pode ir lá e fazer o download (é publico), em
> http://br.groups.yahoo.com/group/flex-brasil/
>
> []s.
>
>
>
> 2009/11/10 J.C.Ködel <jckodel@gmail.com>
>
>
>>
>> Me desculpando cair de para-quedas no assunto... ainda mais porque uso
>> .net server side e não Java mas...
>>
>> Como disse em um e-mail anterior, eu estou usando Flex em todos os
>> projetos onde normalmente usaríamos aqui ASP.Net. E o drama é o mesmo: como
>> fazer CRUD (ou mesmo business server-side) com performance e de forma fácil
>> usando uma camada servidora. Web Services não é a resposta (muito verboso o
>> protocolo SOAP e gerar proxies para cada alteraçãozinha é um pain in the
>> ass).
>>
>> Desenvolvi várias coisinhas para ajudar isso, inclusive um sistema de web
>> services binário (compactado com zLib), o que me reduziu em 60% o tráfego de
>> rede, especialmente para transferência de grids, aliado a isso o fato do
>> transporte ser em XML e eu não precisar de fato tipar as entidades de
>> transporte (embora isso seja um absurdo do ponto de vista OO, é uma mão na
>> roda do lado da produtividade, já que posso programar genericamente ao invés
>> de programar cada entidade separadamente).
>>
>> Cheguei até a usar o ASP.MVC adaptado para trabalhar com o Flex mas,
>> apesar do Linq ser uma ótima tecnologia, fica complicado quando, por
>> exemplo, um filtro dinâmico é aplicado no lado client... programar cada
>> aspecto da camada de modelo para cada caso de visualização pra mim não é uma
>> boa (a grande parte do desenvolvimento estaria envolvendo modelos de dados,
>> ao invés da business do meu projeto, que é o que me faz chegar no objetivo
>> do aplicativo).
>>
>> Também testei o WebOrb (que é disponível para Java também). Achei até
>> interessante o fato de poder chamar métodos puros do servidor no client,
>> porém a idéia de camada de dados deles é meio estranha (eu acho que nunca
>> faria um aplicativo que lidasse com base de dados diretamente no client). E
>> também achei meio lerdo demais =\
>>
>> De qualquer forma, não achei nada interessante para fazer transferência de
>> dados e persistência de uma forma que fosse fácil de usar, rápida e genérica
>> (no sentido de eu não precisar, por exemplo, fazer cada método C, R, U e D
>> para cada entidade), por isso, estava com uma idéia que está anexada no
>> documento em anexo.
>>
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>>
>>
>
>
>
> --
> 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
>

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

[As partes desta mensagem que não continham texto foram removidas]

Olá..

Daniel, estendemos praticamente todos os componentes da paleta do builder adicionando alguns comportamentos que precisamos, listeners etc... e temos uma classe Action que se comunica com todos os componentes, essa classe é quem executa quase tudo, ela quem acessa os serviços do blaze, e controla os componentes nas telas, a maior parte da lógica aplicada à camada de apresentação esta nesta classe, a Action sabe abrir a janela, chamar os serviços, executar validações simples (pertinentes à camada de apresentação), extendemos uma action para cada crud, ex:CadClientesAction, CadProdutosAction, então o trabalho ficou simples, basta desenhar a tela no builder, e criar uma classe Action script para cada tela, neste clase implementamos muito pouca coisa, ou sobrescrevemos algum método para um comportamento muito, muito específico...

então basicamente é desenhar a tela no builder e extender uma classe Action, com isso a janela esta pronta.