Quando conheci JavaServerFaces, achei muito bacana. Componentes pra apresentação de páginas HTML, MVC, listeners ... gostei da idéia e comecei a desenvolver aplicações com esta tecnologia. Fui feliz durante algum tempo, até começar a me deparar com o que considero uma pequena deficiência do JSF: Escopo de requisições.
Em JSF temos três tipos de escopo aparentemente bastante simples
- request: cada requisição um novo estado;
- session: o estado é mantido enquanto durar a sessão;
- application: o estado é mantido até que a aplicação morra;
Mas estes três escopos não cobrem tudo. Veja por exemplo um problema que enfrentei graças a isto:
Desenvolvi uma página JSF, associada a um JavaBean, que exibe os valores deste bean e tem alguns botões que oferecem algumas funcionalidades ao usuário. O escopo desta página foi definido como request. Na primeira vez que acesso esta página, carrego os valores do bean através do seu construtor (passo pela requisição o parâmetro desejado, e com ele a aplicação carrega os valores dos atributos através de chamadas a métodos da persistência. Alguns dos botões da minha página são exibidos somente em alguns casos, dependendo dos valores dos atributos do bean. Quando clico em um destes botões, associados a um actionListener, o bean é reinicializado. No entanto, o parâmetro de inicialização não é passado, e por isso o construtor não consegue atualizar os valores. Tudo bem, isto será feito pelo JSF na fase "Update Model Values". O único problema é que antes desta fase, o JSF verifica se as componentes devem ser renderizadas ou não, e vai utilizar os valores não inicializados. Com isto, a componente do meu botão clicado anteriormente não será renderizada, e portanto não posso invocar o actionListener associado a ele. Para resolver isto, utilizei a solução descrita neste tópico do Java Forums, ou seja, uma grande gambiarra. Não gosto desse tipo de solução, preferiria que a tecnologia me desse suporte para fazer as coisas de maneira mais limpa.
O artigo abaixo fala bem deste problema de escopo, e apresenta uma solução interessante. Pessoalmente acho uma gambiarra também, mas bem mais elegante que a minha
Gradebook - Taming JSF 1.1 - Confluence
Fico feliz de não ser só eu que acho que existe esta limitação em JSF. Não quero ter que colocar como session algo que não precisa durar pela sessão toda. Espero que os desenvolvedores do JSF pensem nisso nas próximas versões. Mas como esta tecnologia esta ainda na sua versão 1.1 (a 1.2 virá logo, aguardem), não vou desistir dela, pois parece bastante promissora.
Em JSF temos três tipos de escopo aparentemente bastante simples
- request: cada requisição um novo estado;
- session: o estado é mantido enquanto durar a sessão;
- application: o estado é mantido até que a aplicação morra;
Mas estes três escopos não cobrem tudo. Veja por exemplo um problema que enfrentei graças a isto:
Desenvolvi uma página JSF, associada a um JavaBean, que exibe os valores deste bean e tem alguns botões que oferecem algumas funcionalidades ao usuário. O escopo desta página foi definido como request. Na primeira vez que acesso esta página, carrego os valores do bean através do seu construtor (passo pela requisição o parâmetro desejado, e com ele a aplicação carrega os valores dos atributos através de chamadas a métodos da persistência. Alguns dos botões da minha página são exibidos somente em alguns casos, dependendo dos valores dos atributos do bean. Quando clico em um destes botões, associados a um actionListener, o bean é reinicializado. No entanto, o parâmetro de inicialização não é passado, e por isso o construtor não consegue atualizar os valores. Tudo bem, isto será feito pelo JSF na fase "Update Model Values". O único problema é que antes desta fase, o JSF verifica se as componentes devem ser renderizadas ou não, e vai utilizar os valores não inicializados. Com isto, a componente do meu botão clicado anteriormente não será renderizada, e portanto não posso invocar o actionListener associado a ele. Para resolver isto, utilizei a solução descrita neste tópico do Java Forums, ou seja, uma grande gambiarra. Não gosto desse tipo de solução, preferiria que a tecnologia me desse suporte para fazer as coisas de maneira mais limpa.
O artigo abaixo fala bem deste problema de escopo, e apresenta uma solução interessante. Pessoalmente acho uma gambiarra também, mas bem mais elegante que a minha
Gradebook - Taming JSF 1.1 - Confluence
Fico feliz de não ser só eu que acho que existe esta limitação em JSF. Não quero ter que colocar como session algo que não precisa durar pela sessão toda. Espero que os desenvolvedores do JSF pensem nisso nas próximas versões. Mas como esta tecnologia esta ainda na sua versão 1.1 (a 1.2 virá logo, aguardem), não vou desistir dela, pois parece bastante promissora.
Nenhum comentário:
Postar um comentário