[quote=urubatan]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).
[/quote]
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ã 