Duvida: JBoss Seam escopo PAGE + A4J = confusão

… nao, o page inicia no invoke application e dura ateh o final de qualquer invoke application iniciado por um request partindo da mesma pagina … ta parecendo que vc precisa conversation

… nao, o page inicia no invoke application e dura ateh o final de qualquer invoke application iniciado por um request partindo da mesma pagina … ta parecendo que vc precisa conversation

Valeu cara, brigadao.

Mas admito que o meu entendimento da documentação (versao 2.2.2) é diferente…

The page context allows you to associate state with a particular instance of a rendered page. You can initialize state in your event listener, or while actually rendering the page, and then have access to it from any event that originates from that page. This is especially useful for functionality like clickable lists, where the list is backed by changing data on the server side. The state is actually serialized to the client, so this construct is extremely robust with respect to multi-window operation and the back button.

Pelo que entendi aí diz que o estado do bean pode ser acessado pelos eventos originados na pagina. Era o que eu gostaria de fazer, mas sem conversation…

Mas se nao tiver jeito, fazer o que, hehe

Valeu…

alias:

Olá amigos do forum.

Estou iniciando com o uso do Seam e aos trancos e barrancos a coisa está indo :lol: , mas venho aos colegas pedir ajuda sobre um caso.

Tenho um managed-bean com escopo PAGE para utilizar em um xhtml. A pagina, por sua vez, usa alguns componentes da biblioteca A4J, como por exemplo o a4j:commandLink

Ocorre que, no action deste link, o meu managed-bean está sendo recriado pelo Seam, e eu preciso usar a instancia original que renderizou a pagina. Pelo que eu entendi da documentação o estado do escopo PAGE deveria ser “persistido”, mas nao é isso que está ocorrendo.

A unica forma que consegui fazer isso foi criar uma conversação longa (com o bean com escopo CONVERSATION), e passar com o a4j:commandLink o parametro “conversationId”. Aí funcionou, mas na verdade o requisito nao tem necessidade de criar uma conversação.

Não é possivel mesmo acessar o bean de escopo PAGE, após a pagina ser renderizada?

Obrigado.

‘alias’, se compreendi corretamente, o que você está tentando fazer é possível sim. Para isso, mantenha na mesma página (e conversação temporária, gerenciada automaticamente pelo seam).
Se você tiver um componente com scope PAGE na página ‘home.xhtml’ e acessar a mesma página com abas diferentes, serão instâncias diferentes do componente. Isto porque serão conversações temporárias diferentes criadas automaticamente pelo seam (’…with respect to multi-window operation …’).

Alguns problemas relacionados com o seu:
tentar fazer alguma operação como inicializar um componente com scope PAGE em uma página anterior onde o componente realmente será utilizado. Explicando melhor esse problema/erro: se na página ‘A’ vc criar um link para uma action que inicializará o componente de scope PAGE e redirecionar para a página ‘B’, não vai funcionar. Na página ‘B’ será outra instância do componente.

Utilizo muito componentes com scope PAGE para listagens. Às vezes, quando preciso inicializar o componente, utilizo page actions.

Bem, para tentar ajudar melhor:
1- Como descobrisse que a instância utilizada ao clicar no botão é diferente da que deseja?
2- Como está o seu a4j:commandLink? é um link para uma action do componente apenas?

Se conseguiu resolver o problema posta pra gente ficar sabendo!

rock:

alias:

Olá amigos do forum.

Estou iniciando com o uso do Seam e aos trancos e barrancos a coisa está indo :lol: , mas venho aos colegas pedir ajuda sobre um caso.

Tenho um managed-bean com escopo PAGE para utilizar em um xhtml. A pagina, por sua vez, usa alguns componentes da biblioteca A4J, como por exemplo o a4j:commandLink

Ocorre que, no action deste link, o meu managed-bean está sendo recriado pelo Seam, e eu preciso usar a instancia original que renderizou a pagina. Pelo que eu entendi da documentação o estado do escopo PAGE deveria ser “persistido”, mas nao é isso que está ocorrendo.

A unica forma que consegui fazer isso foi criar uma conversação longa (com o bean com escopo CONVERSATION), e passar com o a4j:commandLink o parametro “conversationId”. Aí funcionou, mas na verdade o requisito nao tem necessidade de criar uma conversação.

Não é possivel mesmo acessar o bean de escopo PAGE, após a pagina ser renderizada?

Obrigado.

‘alias’, se compreendi corretamente, o que você está tentando fazer é possível sim. Para isso, mantenha na mesma página (e conversação temporária, gerenciada automaticamente pelo seam).
Se você tiver um componente com scope PAGE na página ‘home.xhtml’ e acessar a mesma página com abas diferentes, serão instâncias diferentes do componente. Isto porque serão conversações temporárias diferentes criadas automaticamente pelo seam (’…with respect to multi-window operation …’).

Alguns problemas relacionados com o seu:
tentar fazer alguma operação como inicializar um componente com scope PAGE em uma página anterior onde o componente realmente será utilizado. Explicando melhor esse problema/erro: se na página ‘A’ vc criar um link para uma action que inicializará o componente de scope PAGE e redirecionar para a página ‘B’, não vai funcionar. Na página ‘B’ será outra instância do componente.

Utilizo muito componentes com scope PAGE para listagens. Às vezes, quando preciso inicializar o componente, utilizo page actions.

Bem, para tentar ajudar melhor:
1- Como descobrisse que a instância utilizada ao clicar no botão é diferente da que deseja?
2- Como está o seu a4j:commandLink? é um link para uma action do componente apenas?

Se conseguiu resolver o problema posta pra gente ficar sabendo!

Prezado rock, valeu pela ajuda.

Entao, o funcionamento desse meu componente com escopo PAGE ai é todo na mesma pagina mesmo. As unicas requests que ocorrem sao requisições ajax mesmo. A principio estaria de acordo com o cenario que voce descreveu, de manipular o componente PAGE na mesma pagina. Mas nao funciona! :lol: . É provável que eu esteja fazendo algo errado, hehe, mas ainda nao determinei o que.

No meu a4j:commandLink, sim, só tenho mesmo a action nele. Pra saber que o Seam criou outra instancia, eu tenho um metodo anotado com @Create, o qual é executado novamente no momento que eu clico no link (e antes de ir para o metodo do action, é claro).

Para “resolver” o problema nesse metodo do @Create eu coloquei um @Begin, entao é criada uma conversação e posso fazer as requisições ajax usando essa instancia. Mas nao queria usar uma conversação longa pra essa pagina, entende, pois do ponto de vista do requisito nao é uma “conversação”. Só vou manter assim se nao tiver outro jeito mesmo :lol:

Valeu pessoal, obrigado.

Amigos do fórum, voltando ao assunto…

Gostaria de colocar um RESOLVIDO no tópico, mas não é o caso, hehe. Resolvi o problema com alguma programação criativa, mas vou usar o tópico pra fomentar uma discussão sobre o que eu creio ser um entendimento errado da minha parte sobre a Conversation no Seam.

Antes de usar o Seam neste projeto, eu usava os beans no escopo Request, com a anotação @KeepAlive, do RichFaces. Essa anotação faz com que o bean de Request continue ativo até que a requisição seja enviada seja para outra página. Enquanto eu estivesse na pagina X, aquele bean existiria com aquele estado, o que é MUITO útil. Funciona como o novo escopo View do JSF 2.

É dessa forma que eu queria usar o escopo Page do Seam. O escopo Page DEVERIA fazer isso? Se não, só a conversação resolveria, mas…o Seam guarda a conversação na sessão. Se eu colocar um @Begin ao carregar minha página, e o usuário sair da página corrente…a conversação fica lá, perdida, na sessão. Como vocês tratam isso, se é que é necessário tratar tal “problema”?

Hã…eu criei um interceptador para manter, sempre, apenas uma conversação ativa. Está funcionando, mas sinto uma pequena vergonha dessa classe :oops: :lol:

No aguardo dos comentários dos colegas.

Obrigado.

Sim :!:
Deveria funcionar. Já fiz várias listagens com filtros utilizando um componente com scope PAGE. Mesmo com requisicoes Ajax, é utilizado a mesma instância.

Bem , sobre a teoria eu comentei antes, tem como postar seu código? pq na prática, a teoria é outra…

rock:

alias:

É dessa forma que eu queria usar o escopo Page do Seam. O escopo Page DEVERIA fazer isso?

Sim :!:
Deveria funcionar. Já fiz várias listagens com filtros utilizando um componente com scope PAGE. Mesmo com requisicoes Ajax, é utilizado a mesma instância.

Bem , sobre a teoria eu comentei antes, tem como postar seu código? pq na prática, a teoria é outra…

Opa, valeu pelo salve, cara…se você utiliza o escopo Page dessa forma, me tire uma dúvida…como está no seu web.xml o parâmetro STATE_SAVE_METHOD?

A documentação do Seam diz que o “estado do objeto será salvo no cliente”, entao creio que o conteudo desse campo DEVE estar como CLIENT…nao estou com o fonte a mao agora mas checarei isso, se funcionar…VIVA! :lol:

Valeu amigos.

não tenho ele definido.

onde vc viu isso?

que eu saiba, por padrão é salvo no servidor. E na documentação recomenda utilizar no client se estiver tendo problemas na propagação da conversação:
http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/configuration.html#d0e24304

Qual implementação do JSF vc está utilizando?

tenta o outro parâmetro também

<context-param> <param-name>com.sun.faces.serializeServerState</param-name> <param-value>true</param-value> </context-param>

Amigos,

Me parece que o problema foi resolvido. No meu web.xml havia o seguinte parâmetro, do Facelets:

<context-param>
   <param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
   <param-value>true</param-value>
</context-param>

Nem sei o que diabo esse parametro estava fazendo ai :lol:…o fato é que ele interfere no ciclo de vida do JSF, reconstruindo a arvore de componentes e forçando o Seam a destruir a instancia do meu bean que havia sido desserializado. Uma vez alterado esse parametro para false, o escopo Page está se comportando como o Rock falou.

Alias, sobre a questão da serialização client/server, na documentação do Seam diz isso sobre o escopo Page:

The state is actually serialized to the client...

Mas tem razão, no trecho que apontou, Rock, fala sobre a serialização no servidor e é como estou usando, por enquanto está tudo funcionando, desserializando o estado do Bean, e quando faço qualquer ação na pag é a mesma instancia que é usada, viva! Valeu Rock, se nao tivesse dito que era assim mesmo que esse escopo deveria funcionar eu já teria desistido :lol:

Valeu amigos.