Seam vs Grails/Rails -ComponentBased vs ActionBased para de estados Rich UI

This message was edited 2 times. Last update was at 02/12/2007 17:22:30

Caros,pensando em como o Seam trabalha com estados dos objetos, para desenvolvimento de camadas frontend bastante ricas e como esses componentes também mantém estado, fico pensando se não seria mais natural a transferência desses para o backend.

OBS: Flex por exemplo, integrado ao Seam, isso é um exemplo, sei que a integração hoje, mesmo na versão 2.0 não é tão natural.

Isso é completamente o oposto de como desenvolvemos no backend, utilizando projetos como Grails ou Rails, que são ActionBaseds.

Queria saber a opinião de vocês sobre "Transferência de estado", melhor integração entre os componentes e qual o melhor approach para esse cenário.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Não entendi qual o problema de se usar action-based frameworks pra componentes "ricos". Nesse tipo de framework, o único componente visual é o HTML, cujas tags possuem seus atributos on.*, que disparam eventos feitos em JavaScript para dar "dinamismo" às páginas; e que pode vir junto a alguns arquivos CSS e a um monte de imagens para dar uma cara legal à aplicação.

Mesmo em aplicações JavaServer Faces, fica feio misturar uma classe que manipula os UI com os que manipulam os models.

Não se precisa dos objetos da camada visual para o backend, isso é trocar o MVC por caca.

Kenobi,
Seguindo o exemplo do Flex, a idéia não é transferência de estado ...
O Flex mantem o estado dos componentes apenas no front-end ...
E passa para o backend apenas as alterações de informação, o que diminui muito o trafego necessário ...

Ja o Seam, ou JSF em geral, o estado trafega sempre junto com cada requisição (pelo menos o estado dos componentes que estão na tela), isto quando se configura para manter o estado no cliente, se o JSF for configurado para manter o estado no servidor, ele vai utilizar o HttpSession para isto, e vai aplicar apenas as diferenças enviadas pela UI.
no primeiro caso ele serializa o estado dos componentes zipados em um cookie se não estou enganado.

Ja o WebForms do .NET serializa o estado também zipado para um campo hidden base64 encoded nos formulários gerados ...

Ou seja, se eu entendi o post, fica mais ou menos assim:
No JSF ou WebForms o estado é mantido sempre pelo servidor (mesmo tendo a opção de serializar isto para o cliente, que diminui o uso se memória do servidor aumentando o trafego de rede), e o HTML ou a view escolhida envia apenas as alterações.

O Flex é mais indicado para trabalhar com frameworks estilo action based, pois não existe estado de componentes no servidor, apenas no cliente, e apenas alterações de dados são enviadas para o servidor.

Em frameworks ActionBased que utilizam DHTML+Ajax para criar componentes Ricos o comportamento é similar a arquitetura do flex, o estado dos componentes existe apenas no cliente, e apenas alterações de dados são enviadas para o servidor.

Tanto no caso do Flex quando nos frameworks action based + (DHTML/Ajax) o trafego de rede para atualizações é bem menor e o consumo de memória do seridor também é bem menor por que este não precisa manter estado de forma alguma.
Mas a renderização inicial da página em ambos os casos é mais trabalhosa para o cliente pois este precisa renderizar o componente todo e manter o estado destes na memória do cliente.

Ja no caso do JSF/WebForms o cliente é menos onerado, mas o servidor é mais onerado, pois o servidor mantem o estado de todos os componentes para todos os clientes (mesmo que utilize serialização, neste caso ele vai ter que deserializar e remontar em memória o estado a cada request).

urubatan wrote:Kenobi,
Seguindo o exemplo do Flex, a idéia não é transferência de estado ...
O Flex mantem o estado dos componentes apenas no front-end ...
E passa para o backend apenas as alterações de informação, o que diminui muito o trafego necessário ...

Ja o Seam, ou JSF em geral, o estado trafega sempre junto com cada requisição (pelo menos o estado dos componentes que estão na tela), isto quando se configura para manter o estado no cliente, se o JSF for configurado para manter o estado no servidor, ele vai utilizar o HttpSession para isto, e vai aplicar apenas as diferenças enviadas pela UI.
no primeiro caso ele serializa o estado dos componentes zipados em um cookie se não estou enganado.

Ja o WebForms do .NET serializa o estado também zipado para um campo hidden base64 encoded nos formulários gerados ...

Ou seja, se eu entendi o post, fica mais ou menos assim:
No JSF ou WebForms o estado é mantido sempre pelo servidor (mesmo tendo a opção de serializar isto para o cliente, que diminui o uso se memória do servidor aumentando o trafego de rede), e o HTML ou a view escolhida envia apenas as alterações.

O Flex é mais indicado para trabalhar com frameworks estilo action based, pois não existe estado de componentes no servidor, apenas no cliente, e apenas alterações de dados são enviadas para o servidor.

Em frameworks ActionBased que utilizam DHTML+Ajax para criar componentes Ricos o comportamento é similar a arquitetura do flex, o estado dos componentes existe apenas no cliente, e apenas alterações de dados são enviadas para o servidor.

Tanto no caso do Flex quando nos frameworks action based + (DHTML/Ajax) o trafego de rede para atualizações é bem menor e o consumo de memória do seridor também é bem menor por que este não precisa manter estado de forma alguma.
Mas a renderização inicial da página em ambos os casos é mais trabalhosa para o cliente pois este precisa renderizar o componente todo e manter o estado destes na memória do cliente.

Ja no caso do JSF/WebForms o cliente é menos onerado, mas o servidor é mais onerado, pois o servidor mantem o estado de todos os componentes para todos os clientes (mesmo que utilize serialização, neste caso ele vai ter que deserializar e remontar em memória o estado a cada request).

Urubatan, obrigado pela explanação sobre o Flex, pois não sabia como ele funcionava, ainda não o utilizei. Entretanto, foi um exemplo hipotético.

A pergunta não se refere ao JSF , pois o SEAM na nova versão possui independência para a camada view, podendo ser esta GWT por exemplo.

Pensando em componentes que mantém estado, como JSF, seria interessante ver o FLEX ou outros utilizando essa "transferência de estado".

O JSF mesmo quando é stateless, seu ciclo de vida até a versão atual passa pelo servidor, até mesmo para a versão 2.0 é um ciclo stateless é sugestão do Gavin.

Acho que estou confuso hoje, vou voltar a escrever amanhã

o JSF 2.0 eu não tive tempo de estudar ainda para ver como vai ficar, li algumas sugestões do gavin king, mas nada de concreto ainda

O Seam pelo que eu entendi abstraiu o conceito de componentes statefull do JSF mantendo estado no servidor e criou o binding para GWT (pode ser que eu esteja enganado, o que é bem provavel pois não estudei a nova versão do Seam ainda).
Na versão atual do GWT ele funciona parecido com o Flex, todo o estado dos componentes é mantido no client, desonerando o servidor (o que eu acho uma ótima abordagem para componentes ricos

), mas realmente não sei como foi feito o binding do Seam, o que falei no paragrafo anterior foi um chute

Para componentes ricos, eu acho mais interessante a abordagem do Flex ou DHTML+Ajax (similar ao GWT), que mantem o estado dos componentes no cliente e envia/busca apenas alterações no servidor

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Urubatan, no que isso difere de vc configurar o SAVE_STATE do JSF no modo Client?

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Fala Lazarotti, meu primeiro post foi sobre isso

http://www.rponte.com.br/2007/10/14/state_saving_method-server-ou-client/

Vê se ajuda!

This message was edited 1 time. Last update was at 09/05/2008 16:16:56

Olá Ponte,
sim... eu sei do que se trata. Minha pergunta foi referente à:

do que difere o armazenamento do estado em JSF, atraves de SAVE_STATE "client", em relação ao estado mantido por uma aplicação tbm em client, como o Flex, da forma citada pelo Urubatan.

Urubatan wrote: Para componentes ricos, eu acho mais interessante a abordagem do Flex ou DHTML+Ajax (similar ao GWT), que mantem o estado dos componentes no cliente (...)

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Ah ok Lazarotti, eu havia entendido errado

a diferença é que com save_state o estado vai e volta pro servidor, na outra abordagem, o estado nunca precisa chegar no servidor permitindo código totalmente stateless no servidor, o que aumenta muito a escalabilidade

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Na Java Magazine de março (ou abril?) houve um artigo sobre MVC Model 3, escrito pelo Christiano Milfont. Ele se utilizou de Extjs para renderizar a GUI e do DWR para efetuar a comunicação cliente e servidor (JSON), assim todo o estado da GUI ficava no cliente e somente os dados trafegavam entre as tiers.

Muito bom o artigo, vale a pena dar uma lida.
http://www.milfont.org/tech/2008/02/12/java-magazine-54/

Abraços.

Notícias, artigos e o maior fórum brasileiro sobre Java