de l'interet des paramètres numberOfViewsInSession et numberOfLogicalViews

Bonjour à tous,

Notre web app utilise JSF 1.2 (sun RI) (+JSP) et richfaces 3.3.1.

Nous avons des problèmes d'expiration de view (ViewExpiredException) sans qu'on puissent les reproduire.

J'ai trouvé plusieurs fois le même problème :

http://forums.sun.com/thread.jspa?threadID=5367160
http://www.jboss.org/index.html?modu...topic&t=150405
http://www.coderanch.com/t/430764/JS...eout-but-throw

J'ai bien fais des recherches plus ou moins intéressantes sur le net:

http://forums1.java.net/jive/message...=343966#343966
http://wiki.glassfish.java.net/Wiki....aServerFacesRI

mais je n'ai pas trouvé de réponses satisfaisantes.

En particulier, j'essaye de comprendre l'intérêt des 2 paramètres:
com.sun.faces.numberOfViewsInSession
et com.sun.faces.numberOfLogicalViews

Je crois comprendre qu'ils servent pour gérer le boutton "back" du navigateur.
Mais si je met leur valeur à 1 je ne vois pas de différence de comportement, je n'ai pas de view expirée.

Quelqu'un a t-il eu à modifier ces paramètres ? Quels impacts ont-ils sur les performance ?

Merci pour vos réponses,

VG

Ces paramètres ont effectivement une incidence sur l'expiration des views en cache coté serveur.
Par contre, en cas de requête ajax (via RichFaces), les requêtes tombent en erreur mais rien ne se passe coté navigateur.

il faut utiliser

Code:

---

1 2 3 4 5 6 7

<context-param>   <param-name>org.ajax4jsf.handleViewExpiredOnClient</param-name>   <param-value>true</param-value>   </context-param>

---

et

Code:

---

1 2 3 4 5

A4J.AJAX.onExpired = function(loc, expiredMsg){ ... }   }

---

Cela me convient moyennement, je cherche donc un moyen lorsque cette exception arrive (ViewExpiredException) de rediriger JSF vers la dernière view disponible. Est ce que quelqu'un a déjà tenté l'expérience ?

VG

Bonjour,

Je reviens à la charge avec mes problèmes de view.

Quelqu'un connait-il les règles JSF qui font correspondre une requête HTTP à une view dans la session ?

Je m'explique :
Lorsqu'on navigue dans une web app JSF, les requêtes sont en général des POST qui contiennent un Id correspondant à la view (il me semble) donc là pas de problème pour restaurer la view coté serveur.
Mais si on utilise la directive <redirect/>, JSF génère bien un POST qui se poursuit en GET (via un aller-retour client-serveur).
Dans ce cas, comment JSF sait que cette seconde requête GET correspond au post précédent ?

Si je clique sur le bouton "actualiser" de mon navigateur, je renvoie une requête GET correspondant à l'URL courante visible. Comment JSF s'en sort ?
Retrouve t'il la view courante ? si oui comment ? Recrée t'il toujours une nouvelle view ?

Plus généralement, quelles sont les règles JSF induisent la création d'une nouvelle instance de view plutôt que la restauration d'une view déjà instanciée ?


Merci à tous ceux qui m'auront lu jusqu'ici.

VG.