com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews

Question

Mojarra La mise en œuvre du JSF 2 a les params de contexte suivant:

• com.sun.faces.numberOfViewsInSession (valeur par défaut est 15)
• com.sun.faces.numberOfLogicalViews (valeur par défaut est 15)

Quelle est la différence entre eux? La documentation ne parle pas beaucoup à ce sujet. Mon application a des problèmes avec ViewExpiredException pour certaines pages, mais après nous avons rencontré ces paramètres à un (beaucoup) plus grande valeur, nous avons cessé d'avoir des problèmes.

Mon application est un financier, forme lourde, l'application ajax-activé (certains écrans ont plus de 50 entrées, avec la possibilité d'ajouter beaucoup plus de données / entrées via AJAX).

ce qui peut être la cause de ce comportement? Je comprends que le premier définit le nombre param de « pages » qui sont conservés en session, ce qui peut être utile pour le bouton de retour, mais mes cas d'utilisation qui déclenchent la ViewExpiredException ne pas utiliser le bouton de retour. Qu'est-ce que renvoie le deuxième à param? Si je reste dans le même écran, mais continuer à ajouter beaucoup de données via AJAX, fait cette cause la nécessité d'un plus grand nombre de vues logiques pour la page?

Answer 1

Tout d'abord, la mise en œuvre Mojarra involontairement troqué le sens de ces paramètres de contexte. Donc, si vous avez l'impression que la description est exactement l'inverse de ce que le nom du paramètre de contexte littéral implique, cela est bien vrai.

---

com.sun.faces.numberOfLogicalViews

Ceci est essentiellement GET demande fondée. Chaque requête GET crée une nouvelle vue en session.

Pour l'expérimenter, réglez une valeur de 3, démarrer une nouvelle session de navigateur et ouvrez 4 différents onglets du navigateur (quelle que soit l'URL, peuvent être identiques, peut être différent) en séquence, puis revenir au 1er onglet et soumettre le formulaire là-dedans. Vous obtiendrez un ViewExpiredException, parce que ce point de vue a été poussé hors de la LRU (moins récemment) la carte pour les vues en session. Cela ne se produira pas si vous ouvriez 3 onglets max.

Avec la valeur par défaut de 15, cela est un problème rare dans le monde réel. Si votre webapp est vraiment conçu pour être utilisé de cette façon (par exemple, un site communautaire / social qui invite à être ouverts dans plusieurs onglets, comme un forum de discussion ou Q & A), alors vous pouvez envisager d'utiliser l'état du côté client d'économie au lieu d'augmenter la valeur par défaut . Avec l'économie d'état côté client, vous ne serez jamais face à cette exception. Une alternative serait d'utiliser OmniFaces <o:enableRestorableView> en combinaison une demande scope paramètres de haricots et de requête, ou une vue haricot scope qui vérifie dans (post) construction si ses propres besoins de l'Etat à restaurer. Encore une fois une autre alternative est d'aller avec <f:view transient="true">, de cette façon les vues ne sont pas enregistrées plus, mais vous ne pouvez pas utiliser la vue scope haricots plus.

Les MyFaces équivalents est org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION qui par défaut est 20.

---

com.sun.faces.numberOfViewsInSession

Ceci est essentiellement synchrone (non-ajax!) Demande POST basé. Chaque requête synchrone POST crée une nouvelle vue logique. Ils sont tous stockés sur la base d'une vue physique comme si Map<PhysicalView, Map<LogicalView, ViewState>>. Ainsi, avec max 15 vues physiques et max 15 vues logiques, vous pouvez avoir théoriquement 15 * 15 = 225 vues en session.

Pour l'expérimenter, le mettre à une valeur de 3, ouvrez une vue avec une forme synchrone, soumettre 4 fois, puis appuyez sur le bouton de retour du navigateur 4 fois, puis soumettre à nouveau le formulaire. Vous obtiendrez un ViewExpiredException, parce que ce point de vue a été poussé hors de la LRU (moins récemment) la carte pour les vues logiques. Cela ne se produira pas si vous revenez max 3 fois, puis soumettre à nouveau.

Notez que ajax soumet réemployer la même vue logique (vous pouvez le confirmer en voyant exactement la même valeur de javax.faces.ViewState étant renvoyé sur ajax postbacks). Il y a le bouton retour de soutien à aucun navigateur de toute façon. Le bouton de retour du navigateur que vous ne rapporte à la demande synchrone précédente, il ne serait donc pas de sens pour stocker tous les ajax postbacks que les vues logiques en session.

Avec la valeur par défaut de 15 et la tendance actuelle des formes ajax seule et cache désactivé sur les pages dynamiques, c'est un problème du monde réel très rare. ne doivent pas inviter des formes bien conçues pour appuyant sur le bouton retour du navigateur. , Ils doivent le succès en présenter redirect à la vue cible et en cas d'échec tout réafficher la même forme avec des erreurs de validation. Voir aussi pour trouver des indices Éviter le bouton de retour sur application Web JSF. Si cela est aussi pour votre application le cas, vous pouvez en toute sécurité de définir la valeur à 1.

MyFaces avaient à l'origine pas d'équivalent pour cela, et compte cela comme une vue physique en session ainsi. Dans la version 2.0.6, org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION a été introduit, avec un semblable but, mais avec une implémentation différente et désactivée par défaut.

---

Voir aussi:

• doit-PARTIAL_STATE_SAVING être défini sur false
• javax.faces.application.ViewExpiredException: Vue pourrait être restauré
• Quelle est l'utilité de l'apatridie dans JSF?

Answer 2

Juste trouvé sur le web: http: // oss .org.cn / ossdocs / java / ee / javaeetutorial5 / doc / JSFConfigure11.html

Cela peut être utile:

  

vues logiques sont sous-vues d'une vue au niveau supérieur. Par exemple, si vous avez une page qui comprend plusieurs cadres alors chaque image est une vue logique.   Si vous avez une application simple, la valeur par défaut de 15 vues ou 15 vues logiques pourrait être trop grande. Dans ce cas, vous devriez envisager de réduire le nombre autorisé de vues et des vues logiques économiser de la mémoire. A l'inverse, une application plus complexe peut nécessiter plus de 15 vues ou des vues logiques à enregistrer dans une session.