Galera…
Eu tenho 2 views e 1 MB…
Eu pesquisei aqui no forum e um rapaz (que inclusive criou um framework)
sugeriu mudar o scope do bean para algo do myfaces @AccessViewScoped
Mas eu nao quero ficar adiacionando mta dependencias no meu projeto…
E tb nao quero usar o framework do rapaz.
Então o problema e´que todo crud tem 2 views:
list
form
onde no list eu tenho um form de filtros… uma datatable … e um confirmDelete …
o outro arquivo eu tenho um for aara visualizar/editar os dados …
Eu achava que o viewScoped iria perceber que o managedBean tbem é referenciado na proxima view
e que ele iria manter. Mas não! (PS: outro problema é que estou usando Spring…)
Então, como eu vou manter o MB vivo quando eu trocar de pagina?
Ou como faço um bypass disso para nao precisar mantê-lo vivo?
Só para contextualizar melhor: a tabela tem uma coluna com botao de deletar e editar…
veja:
<p:commandButton id="edit" icon="ui-icon-pencil" action="#{cc.attrs.controller.getFormPath}" ajax="false">
<f:setPropertyActionListener value="#{entity}" target="#{cc.attrs.controller.entity}" />
</p:commandButton>
Eu tenho um action que o metodo retorna algo do tipo: /view/grupo/formGrupo.xhtml
e usando o setPropertyActionListener eu sei que o meu atributo “Grupo entity” que esta
na outra view será carregado nos campos e ao salvar, vou editá-lo [método saveOrUpdate]!
Este é um dos problemas… O outro problema vou postar em outro tópico 
Mas envolve FlashScope.
Um problema.
Spring não tem view scope que eu saiba.
Por isso que os seus beans não devem manter os valores.
Eu uso com um servidor jee e funciona corretamente.
[quote=lele_vader]Um problema.
Spring não tem view scope que eu saiba.
Por isso que os seus beans não devem manter os valores.
Eu uso com um servidor jee e funciona corretamente.[/quote]
O ViewScoped se manter por duas paginas??
com ViewScpoed??
*EDIT:
Mas eu to usando Spring para CDI,
Spring Data, e para controle transacional…
q nem vi q vc disse num post uma vez.
Tem como eu deixar o JSF tomar conta do Escopo
e deixar o spring quetin só praquilo ali?
Duas páginas não.
O view scope tem que se manter na mesma página.
Se precisa disso daí usa session scope talvez.
Mas não sei como o spring vai fazer cdi de um managed bean com escopo de view não.
cara, mas imagine um sistema com 300 tabelas (praticamente 200~250 cruds)
Agora imagine 1k usuarios acessando simultaneamente…
Não dá né??
A não ser que tenha um workaround ou algo assim pra eu remover da sessão manualmente depois!
Não disse para colocar todas os managed beans como sessão.
Ainda não entendi para que você quer essa questão dos managed beans ?
Por exemplo no editar lá e deletar.
Você poderia passar o id ou o próprio objeto para a próxima página e o managed bean iria recuperar o objeto setado e faria normalmente.
[quote=lele_vader]Não disse para colocar todas os managed beans como sessão.
Ainda não entendi para que você quer essa questão dos managed beans ?
[/quote]
Então cara, é porque todo crud tem duas paginas:
listEntidade.xhtml
fromEntidade.xhtml
Onde todo LIST tem um componente que criei que representa os filtros … Um componente que contem o datatable e outro componente que contém um dialogo para deletar a entidade.
Todo FORM tem um formulário para a pessoa visualizar/editar
Na datatable eu tenho:
<p:commandButton id="edit" icon="ui-icon-pencil" action="#{cc.attrs.controller.getFormPath}" ajax="false">
<f:setPropertyActionListener value="#{entity}" target="#{cc.attrs.controller.entity}" />
</p:commandButton>
onde o getFormPath vai retornar /view/entidade/formEntidade.xhtml
eu seto o valor na entidade que tenho no MB tipo “Entidade entity”
e depois quando ele muda de pagina, ela já aparece com os campos carregados.
Pronto! 
É por isso que eu preciso manter o MB vivo por duas views
Você não precisa manter todo o managed Bean vivo.
Você precisa manter a entidade viva.
Passa por parâmetro para a próxima url.
Ou nesse seu propertyActionListener, poderia colocar uma propriedade para visualizar ou alterar.
E na outra página pegar o valor dessa propriedade.
Agora você manda redirect entre uma tela e outra ?
[quote=lele_vader]Você não precisa manter todo o managed Bean vivo.
Você precisa manter a entidade viva.
Passa por parâmetro para a próxima url.[/quote]
tem algum pedacin de código rapidinho de como eu faria isso?
f:param né ?
ai do outro lado como que eu pego ele? como?
ahh aproveitando… isso vai funcionar na caixa de dialogo que tenho para deletar?
ou tbem tenho que fazer do mesmo jeito?
PS: esqueço o setProperty… née?
Acho que tem que ser f:attribute, pois você vai querer passar os objetos.
Lembrando que se for jsf 2 você pode passar parâmetros para os métodos de um managedBean.
Se usar f:param no seu managed bean terá que pegar por se não me engano:
Entidade entidade = (Entidade) request.getFacesContext().getRequestParamMap().getAttribute(“nomeAtributo”);
Daí acho que poderia fazer assim (se for usar o parâmetro no método do managed bean):
public String prepararEditar(Entity objeto){
setEntidade(objeto);
}
return "string para proxima pagina";
e na outra página você pode usar
#{bean.entidade.campoX}
Como você cria essa caixa de diálogo ?
Pode-se fazer do mesmo jeito.
uééé mas isso não tem diferença do que eu ja estava tentando fazer !
PS: ja que o spring n tem viewscope… eu vi um workaround
http://www.harezmi.com.tr/spring-view-scope-for-jsf-2-users/
qq vc acha?
E porque parou de fazer dessa forma ?
O que acontece é o seguinte
eu tinha o MB com @ViewScoped e @Component anotado…
ai tava usando tranquilo ACHANDO que o viewScoped tava funcionando…
depois fui ver que nao funciona! Descobri isso hoje!
Aí to me virando aqui pra ver oq ue faço para ele matar o MB depois que sair dessas duas views!
Se você colocar como request ele só vai funcionar a cada requisição.
O view scope também não é muito recomendado eu acho para o seu modelo que tem várias páginas.
Mesmo se não fosse spring não funcionaria eu acho.
Nos links você prepara os objetos que a próxima página irá ver.
Lembrando que jsf não é struts 1 com 1 página por action (no caso managed bean).
Você pode colocar 1 managed beans para todas as páginas correlacionadas.