javax.faces.STATE_SAVING_METHOD pode resolver problemas

Após algum tempo sem escrever no blog, venho aproveitar a ocasião para descrever uma experiência que tive durante a resolução de um problema.

A maioria dos desenvolvedores que utiliza o framework JavaServerFaces acaba adotando por regra determinar a propriedade STATE_SAVING_METHOD como client, deixando a validação da renderização dos componentes no cliente ( cria-se um input hidden com o nome de ViewState ), é possível também deixar que essa responsabilidade fique no servidor de aplicações, definindo assim a propriedade com o valor "server".

Basta verificar a seguinte configuração em seu web.xml:

<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>

Caso exista algum problema de validação na estrutura do seu código ( jspx, jsp, jsf ), e a propriedade server estiver definida, será possível que a validação ocorra em linha, ou seja, antes de renderizar a página o servidor irá fazer todas as validações necessárias ( se existe tal propriedade ou metodo, se existe mais de 1 componente com mesmo id, se seus conversores estao definidos de maneira correta, etc ), pois bem, muitas dessas validações são feitas indiferentemente do que se define no "saving_method", porém em alguns casos o "client" pode falhar.

Ex: Caso você tenha utilizado jstl para fazer alguma verificação dos componentes, ex:

<c:choose>
<c:when> test="${meuMBean.minhaCondicao}"
<t:inputHidden id="meuHiddenComIdRepetido" forceId="true" value="#{meuFacesMBean.meuValue}" />
</c:when>
</c:otherwise>
<t:inputHidden id="meuHiddenComIdRepetido" forceId="true" value="#{meuFacesMBean.meuValue}" />
</c:otherwise>
</c:choose>



Obs: Veja que o ID é o mesmo, isso não pode.

Nesses casos, a validação client pode falhar. Muitos poderão dizer que o motivo é essa mistura do JSTL com JSF, porém em muitos casos se faz necessária, além de que você nunca sabe o que foi escrito no código antes de dar manutenção no mesmo, e pode ser que pensem diferente de você, portanto é preciso estar preparado para todos os casos. Outro argumento à favor é o fato de ser permitida essa adição, então se é permitida, logo é possível que ocorra e se o código funcionar assim, poderá causar erros inexplicáveis na aplicação, pois no momento em que for para o server, a validação irá falhar (e pode falhar de forma intermitente, digo isso como experiência propria que tive em uma aplicação).

Pois bem, adicionando em sua aplicação a propriedade SERVER, esse trecho de código acima, será rejeitado sempre, não deixando que nenhuma execução problemática ocorra.

Nota: Utilizei neste projeto myfaces1.1.7, tomahawk 1.9 e trinidad-api-1.0.11.jar