Opa pessoal, tranquilo?
Estou com um problema que me consome há meses, porém só agora voltei a mecher no meu projeto:
É um clássico problema de request scope do JSF, onde eu tenho uma página que lista chamados, e desta eu posso solicitar o fechamento do mesmo enviando para uma outra página (via command button com setPropertyActionListener).
eu consigo mandar tranquilamente os dados desse objeto Chamado, pelo bin chamadoBean, para a outra página, porém, quando eu vou salvar (atualizando a proposta de solução de chamado apenas), ele perde totalmente o objeto, apenas seta esse novo atributo (num objeto novo).
eu já vislumbrei 2 soluções, mas não sei se seriam gambiarras:
1- colocar um monte de inputHidden e converters pra todos os atributos de chamado. Isso funcionaria em teoria mas estou apanhando pros converters, e convenhamos, parece uma GAMBI TOTAL… nem dei seguimento hehe
2- colocar apenas um inputHidden do id, e quando for chamar o metodo de enviarProposta ele pega o id, puxa do banco via DAO e perfila o objeto Chamado e blz, só que antes eu teria que criar variáveis auxiliares pra cada item que eu fosse alterar, nesse caso, apenas o atributo “solicitarFechamento” (porque ele vai pegar o chamado do banco e sobrescrever).
a solução 2 fica um pouco melhor, mas mesmo assim muito cheirando a gambiarra…
pergunta: é normal esse tipo de erro ou eu devo estar vacilando em algum lugar ?
eu já vi que tem aquele saveState do tomahawk, seria interessante usá-lo ? importar uma lib só pra usar um comando?
Veja bem, quando um MB é anotado com @RequestScoped isso diz ao JSF que aquele MB deve viver durante uma requisição apenas. Ou seja, para cada chamada ao servidor o JSF cria uma instância completamente nova do JSF, é por isso que você “perde” o objeto. A abordagem correta é você utilizar o escopo apropriado do seu MB. Se ele precisa sobreviver entre chamadas da mesma página, então o escopo @ViewScoped é suficiente. Porém, se você precisa que o MB sobreviva entre chamadas de páginas diferentes, então você deverá usar o escopo @SessionScoped.
[quote=caematos]eu entendo isso, mas acho que você também entende os problemas de se usar SessionScope, certo ?
[/quote]
SessionScoped apresenta problema se você usar da maneira errada, ou seja, se você usar onde não existe necessidade de se manter sessão. Caso contrário, você precisa usar esse recurso, ou seja, se o estado do seu MB precisa sobreviver entre requests de páginas diferentes então você precisa usar o SessionScoped.
Agora, isso não quer dizer que essa é a única solução para o seu problema, você pode revisar a navegação entre as suas páginas, você pode dividir o MB em dois ou então juntar 2 páginas em uma …
Exato. Mas nesse contexto fica estranho utilizar SessionScope, pois não faz sentido guardar algo temporário na sessão, ou seja, estaria o utilizando de forma errada, algo equiparado com metodos static.
Como você faria pra, por exemplo, de um dataGrid/dataTable enviar um Objeto para uma outra página, e dessa página alterar o mesmo Objeto?
Sendo que você só quer alterar UM campo desse Objeto. Seria como inserir apenas um atributo.
Bom, nesse caso, acho que não tem muita saída a não ser enviar o id do objeto para a próxima página, daí o cara carrega do banco, faz a modificação que precisa e persiste o objeto novamente, porém, ao voltar para o grid você vai precisar recarregar seus objetos.
É, foi isso mesmo que pensei, valeu pela resposta.
O que eu acho estranho é que pouca gente tem um problema assim. O que você faz quando tem que editar algo? Edita na mesma página?
[quote=caematos]É, foi isso mesmo que pensei, valeu pela resposta.
O que eu acho estranho é que pouca gente tem um problema assim. O que você faz quando tem que editar algo? Edita na mesma página?[/quote]
Eu acho que é uma idéia boa. Assim você pode usar o @ViewScoped, que é mais prático que o @RequestScope e menos pesado que o @SessionScope, além disso você usar o Ajax para enviar as requests.
Cara, o rmendes08 tem razão na sugestão entre usar @ViewScoped, e o @RequestScope. Utilizar a session só dá problema se você não souber o que esta fazendo, lembre-se que se um recurso existe é para ser usado.
Se o problema é não deixar objetos temporários na session sem necessidade, ok, mas você pode simplesmente retira-lo da session através do seu Managed bean após o uso.
