com.Sun.faces.numberOfViewsInSession vs com.Sun.faces.numberOfLogicalViews
L'implémentation Mojarra de JSF 2 a les paramètres de contexte suivants:
com.Sun.faces.numberOfViewsInSession(la valeur par défaut est 15)com.Sun.faces.numberOfLogicalViews(la valeur par défaut est 15)
Quelle est la différence entre eux? La documentation n'en parle pas beaucoup. Mon application rencontrait des problèmes avec ViewExpiredException pour certaines pages, mais après avoir augmenté ces paramètres à une valeur (beaucoup) plus élevée, nous avons cessé d'avoir des problèmes.
Mon application est une application financière, lourde, compatible Ajax (certains écrans ont plus de 50 entrées, avec la possibilité d'ajouter beaucoup plus de données/entrées via AJAX).
quelle peut être la cause de ce comportement? Je comprends que le premier paramètre définit le nombre de "pages" qui sont conservées en session, ce qui peut être utile pour le bouton de retour, mais mes cas d'utilisation qui déclenchent le ViewExpiredException n'utilisent pas le bouton de retour. À quoi fait référence le deuxième paramètre? Si je reste dans le même écran mais que j'ajoute beaucoup de données via AJAX, cela nécessite-t-il un plus grand nombre de vues logiques pour la page?
Tout d'abord, l'implémentation de Mojarra a involontairement inversé la signification 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, alors c'est vrai.
com.Sun.faces.numberOfLogicalViews
Il s'agit essentiellement d'une requête GET. Chaque demande GET crée une nouvelle vue en session.
Pour l'expérimenter, définissez-le sur une valeur de 3, démarrez une nouvelle session de navigateur et ouvrez 4 onglets de navigateur différents (quelle que soit l'URL; peut être le même, peut être différent) dans l'ordre, puis revenez au 1er onglet et soumettez le formulaire là-dedans. Vous obtiendrez un ViewExpiredException, car cette vue a été retirée de la carte LRU (la moins récemment utilisée) pour les vues en session. Cela ne se produira pas si vous avez ouvert 3 onglets max.
Avec la valeur par défaut de 15, il s'agit d'un problème rare dans le monde réel. Si votre application Web est vraiment conçue pour être utilisée de cette façon (par exemple, un site social/communautaire qui invite à être ouvert dans plusieurs onglets, comme un forum de discussion ou une session de questions-réponses), vous pouvez envisager d'utiliser l'enregistrement de l'état côté client au lieu d'augmenter la valeur par défaut . Avec l'enregistrement de l'état côté client, vous ne rencontrerez jamais cette exception. Une alternative serait d'utiliser OmniFaces <o:enableRestorableView> en combinaison avec un bean de portée de requête et des paramètres de requête, ou un bean de portée de vue qui vérifie dans la construction (post) si son propre état doit être restauré. Encore une autre alternative est d'aller apatride avec <f:view transient="true"> , de cette façon, les vues ne sont plus enregistrées, mais vous ne pouvez plus utiliser les beans de portée de vue.
L'équivalent de MyFaces est org.Apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION dont la valeur par défaut est 20.
com.Sun.faces.numberOfViewsInSession
Ceci est essentiellement synchrone (non-ajax!) POST basé sur la demande. Chaque synchrone POST demande crée une nouvelle vue logique. Ils sont tous stockés sur la base d'un vue physique comme si Map<PhysicalView, Map<LogicalView, ViewState>>. Donc, avec max 15 vues physiques et max 15 vues logiques, vous pouvez théoriquement avoir 15 * 15 = 225 vues en session.
Pour l'expérimenter, définissez-le sur une valeur de 3, ouvrez une vue avec un formulaire synchrone, soumettez-le 4 fois, puis appuyez sur le bouton de retour du navigateur 4 fois, puis soumettez à nouveau le formulaire. Vous obtiendrez un ViewExpiredException, car cette vue a été retirée de la carte LRU (Least récemment utilisé) pour les vues logiques. Cela ne se produira pas si vous revenez au maximum 3 fois et que vous le soumettez à nouveau.
Notez que ajax soumet à réutiliser la même vue logique (vous pouvez le confirmer en voyant exactement le même javax.faces.ViewState valeur renvoyée sur les publications ajax). Il n'y a pas de prise en charge du bouton de retour du navigateur de toute façon. Le bouton de retour du navigateur vous ramène uniquement à la demande synchrone précédente, il n'aurait donc aucun sens de stocker tous ces messages ajax en tant que vues logiques en session.
Avec la valeur par défaut de 15 et la tendance actuelle des formulaires ajax uniquement et du cache désactivé sur les pages dynamiques, il s'agit d'un problème très rare dans le monde réel. Les formulaires correctement conçus ne doivent pas inviter à appuyer sur le bouton de retour du navigateur. Au lieu de cela, ils devraient en cas de redirection de soumission réussie vers la vue cible et en cas d'échec, réafficher le même formulaire avec des erreurs de validation. Voir aussi des conseils Comment naviguer dans JSF? Comment faire en sorte que l'URL reflète la page actuelle (et non la précédente) . De plus, le cache est plus souvent désactivé sur les pages dynamiques, donc le bouton Précédent vous donnerait essentiellement une toute nouvelle vue. Voir aussi éviter le bouton de retour sur l'application Web JSF . Si c'est également le cas pour votre application, vous pouvez définir la valeur sur 1 en toute sécurité.
MyFaces n'avait à l'origine aucun équivalent pour cela, et comptait également cela comme une vue physique en session. Dans la version 2.0.6, org.Apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION a été introduit, avec un objectif similaire, mais avec une implémentation différente et par défaut désactivé.
Voir également:
Je viens de le trouver sur le Web: http://oss.org.cn/ossdocs/Java/ee/javaeetutorial5/doc/JSFConfigure11.html
Cela pourrait être utile:
Les vues logiques sont des sous-vues d'une vue de niveau supérieur. Par exemple, si vous avez une page qui comprend plusieurs cadres, chaque cadre est une vue logique. Si vous avez une application simple, la valeur par défaut de 15 vues ou 15 vues logiques peut être trop grande. Dans ce cas, vous devez envisager de réduire le nombre autorisé de vues et de vues logiques pour économiser la mémoire. Inversement, une application plus complexe peut nécessiter l'enregistrement de plus de 15 vues ou vues logiques dans une session.