Pourquoi la portée request n'est pas suffisante pour le backing bean

Voici ce qui se passe quand l'utilisateur clique sur l'id d'un compte dans la table :

1. La requête GET arrive sur le serveur pour afficher la page du mouvement.
2. Le backing bean est créé car il est référencé dans la page. Ce backing bean est initialisé avec le compte sur lequel on veut faire un mouvement grâce à la balise <f:viewParam> de la section <f:metadata> de la page.
3. L'utilisateur saisit le type et le montant du mouvement et il soumet ensuite le formulaire.
4. La soumission du formulaire lance une nouvelle requête POST. Oui, vous avez compris (j'espère :-) ) : c'est une nouvelle requête et donc un nouveau bean est créé quand la requête POST arrive sur le serveur pour un nouveau cycle de vie JSF (retauration de la page des mouvements, validation des valeurs saisies dans la page, etc.). Donc, en particulier la propriété "compte" (celle qui contient une référence vers l'entité CompteBancaire sur laquelle on veut faire un mouvement) a la valeur null !

Conclusion : il faut élargir la portée, toujours en choisissant la portée la plus restreinte possible. Pour ce cas, une portée "view" convient car on reste sur la même page. Donc l'instance du backing bean créée au moment de la 1ère requête GET est conservée lors de l'arrivée sur le serveur de la 2ème requête POST et tout marche donc bien.

Dans d'autres cas la portée "view" peut ne pas convenir et il faudra alors utiliser la portée "flow" (dans le support de cours mais pas étudié dans le cours ; vous avez un exemple dans les exercices optionnels à la fin du TP), la portée "conversation" ou, plus rarement, la portée "session".