JSF: bean portée; session vs demande

J'ai un managed bean appelé UserSearchHandler, il a un doSearch méthode qui remplit UserSearchHandler.searchResults qui sont affichés dans un tableau sur le userSearch.xhtml page.

J'ai un autre bean géré appelé UserHandler, il a un showUser méthode et ainsi de suite.

Dans le tableau des résultats de recherche, le nom d'utilisateur est un lien qui, lorsqu'il est cliqué, est censé afficher les détails de l'utilisateur sur un userView.xhtml page. La table et le lien ressemble à ceci:

<p:dataTable var="user" value="#{userSearchHandler.searchResults" >

//... and so on ... then

<h:commandLink value="#{user.firstName}" action="#{userHandler.showUser}">
  <f:setPropertyActionListener target="#{userHandler.userIdToShow}" value="#{profile.id}"/>
</h:commandLink>

Tout fonctionne bien lorsque la gestion de haricots sont mis à session portée.

Cependant, lorsque je change la portée sur les haricots à request la recherche fonctionne, et le tableau est renseigné, mais quand je clique sur le lien rien ne se passe. J'ai mis un point d'arrêt sur la userHandler.showUser méthode et elle n'est jamais atteint lorsque le userSearchHandler est réglé sur "demande" de la portée.

Quelqu'un peut aider à expliquer pourquoi il en est, ou ce que je fais mal?

InformationsquelleAutor Robert Hume | 2011-01-26
  1. 5

    C'est parce que la #{userSearchHandler.searchResults} est vide lors de la nouvelle demande et, par conséquent, JSF est incapable de localiser la ligne concernée où la commandlink est été invoqué dans le but d'invoquer l'action (et de passer/définir les propriétés le cas échéant).

    Vous devez vous assurer que le même #{userSearchHandler.searchResults} est créés au préalable lors de l'haricot de construction/d'initialisation. Si c'est pour être créé sur la base d'un ensemble de paramètres spécifiques, alors vous avez à les transmettre avec le formulaire.

    C'est exactement la raison pour laquelle les solutions de Tomahawk est <t:saveState /> et de nouvelles JSF 2.0 portée de vue existent.

    Voir aussi:

    • Merci! Est-il un moyen de le faire fonctionner sans faire le UserSearchHandle une session d'étendue de haricot?
    • Si vous êtes sur JSF 2.0, il suffit de mettre le haricot à portée de vue. Si vous êtes encore sur JSF 1.x, envisager de Tomahawk est t:saveState (pas sûr si PrimeFaces offres similaires interne, solution pour ce que, je n'ai jamais utilisé PrimeFaces sur JSF 1.x).
    • Merci encore. Je suis en utilisant JSF2. Plus de questions. 🙂 La lecture à propos de l'étendue de l'affichage, dans mon cas, je suis le chargement d'une nouvelle page "userView.xhtml" sur le clic. Va voir portée de travail ici ou suis-je à rester sur la même page pour que cela fonctionne? Je suis aussi à l'aide de Printemps Cio donc je suis en utilisant le Printemps des annotations pour créer de la gestion de haricots, comme "@Scope("session")" et il ne semble pas être un "@Scope("affichage")" option.
    • Ah le Printemps, puis il s'arrête ici. Soit remplacer le Ressort par Java EE 6 (CDI) (si vous exécutez un conteneur Java EE 6), ou aller pour le Tomahawk approche. C'est assez simple: après avoir installé l'pots, ajouter <t:saveState value="#{userSearchHandler}" /> à la page. C'est tout. Il se comporte exactement comme la portée de vue (qui aurait travaillé dans votre cas, oui, la soumettre revient à la même vue en tout cas).
    • Merci pour l'aide!
    • Vous êtes les bienvenus.
    • Plus de détails -- et une autre question, j'ai changé mon Ressort des annotations dans la gestion de la fève à la JSF2 ceux; ex. "@Scope("session")" est devenu "@SessionScoped" et ainsi de suite. Et j'ai eu l'application fonctionne à nouveau (avec session étendue de haricots). J'ai ensuite changé @SessionScoped à @ViewScoped et quand il a couru, j'ai une erreur que mon gestionnaire de UserSearchHandler n'était pas sérialisable. J'ai ajouté "implements Serializable" et puis j'ai eu une erreur qu'il y a des Printemps et/ou en veille prolongée de classes qui ne sont pas sérialisables. Est-ce que "serializable" erreur somethign que je peux corriger, ou ai-je fait quelque chose de mal?
    • Eh bien, c'est un problème de conception. Les Javabeans sont par cahier des charges nécessaires pour mettre en œuvre Serializable. Si vous ne voulez pas sérialiser un javabean pour quelque raison spécifique (contient des informations sensibles qui vous voudrais de ne pas stocker sur le disque ou le transfert sur le réseau, ou contient des propriétés qui pas être sérialisé, de toute façon comme InputStream, etc), puis il suffit de les marquer transient. L'exigence d'être sérialisable par la façon dont s'appliquent également lors de l'utilisation de t:saveState.
    • Merci encore. Je ne suis pas sûr de quoi faire avec "transitoire". J'ai essayé de faire mon UserHandlerBean serializable, puis a fait "transitoire privé UserService _userService" (qui est définie avec un @ManagedProperty(value="#{userService}) annotation). Mais avec le mot "transitoire" il y la userService est toujours null. Sans le mot "transitoire" il y a là un serializable exception sur "org.springframework.orm.hibernate3.AbstractSessionFactoryBean$TransactionAwareInvocationHandler" -- ce qui, vraisemblablement, est utilisé par le UserService mise en œuvre. Suis-je à l'aide de "transitoire" de la façon dont vous vouliez dire? Merci encore.
    • Lors du marquage d'un champ transient, il ne sera pas sérialisé et donc aussi de ne pas être disponible après la désérialisation. Si vous l'utilisez correctement, mais le UserService semble être un javabean ainsi et ainsi, elle a vraiment besoin d'être sérialisable ainsi. C'est juste par contrat.
    • Juste pour conclure, UserService a des méthodes (ex. createUser) qui sont marqués @Transactionnelle (un Printemps annotation de fournir Printemps, la gestion des transactions sur la méthode). Je ne peux pas obtenir loin de mise en œuvre sur le court terme, donc je vais essayer de t:saveState approche. Dans le long terme, ce serait de la non-Printemps, JavaEE de remplacement pour le Printemps @Transaction annotation? Merci encore.
    • Java EE/EJB est transactionnelle par défaut. Notez que le t:saveState exige également la fève être sérialisable... (voir aussi le commentaire précédent). Si la portée de session ou serialiable est pas vraiment une option, alors vous avez à jouer avec les paramètres de la demande et de la préparation du modèle de données de l'haricot, le constructeur ou l' @PostConstruct en fonction de ces paramètres.

    InformationsquelleAutor BalusC
  2. 0

    J'ai quelques idées. Si vous êtes en utilisant un à votre navigation, vous pouvez essayer de prendre ça. Le faire signifierait que le navigateur ne sera pas de faire une nouvelle requête HTTP, quand il rend la deuxième fenêtre. C'est la nouvelle requête HTTP qui efface la portée de la requête de haricots. Si ce n'est pas une option, vous pourriez être en mesure de passer un paramètre dans votre lien comme un id d'enregistrement, ce qui pourrait vous permettre d'extraire des données à partir de votre source de données correspondant à l'id.

    • Sauf si vous avez ajouté <redirect/>, la navigation n'est par défaut pas de feu d'une nouvelle demande. Il utilise juste RequestDispatcher#forward() sous les couvertures. C'est le formulaire de soumission (un pur interaction avec le client de la pression commandlink/bouton de commande) qui est responsable de la nouvelle demande.
    • J'ai tapé redirect/ lt et gt carottes, mais il n'apparaît pas dans ma réponse. Désolé à ce sujet. C'est ce que j'essayais de dire. Je ne pouvais pas dire si une redirection a été utilisé ou non. J'ai lu dans JavaServer Faces 2.0, La Référence Complète, qu'en appuyant sur un bouton de commande/Lien qui n'ont pas de navigation à la règle avec une redirection ou implicite de navigation qui ne comprend pas ?visages-redirect=true va simplement afficher les valeurs d'un formulaire sans le navigateur de faire une deuxième requête HTTP vers la nouvelle URL.
    • Au lieu de cela, le navigateur va simplement rendre la nouvelle page et les valeurs de la portée de la requête bean sera toujours disponible. Mais je suis relativement nouveau, donc, il est très possible que j'ai mal compris ce que j'ai lu. Je vais aller re-lire.
    InformationsquelleAutor Sean