JSF

- Mise à jour : 21/04/2015 - Copyright(C) 2015 - Laurent Chrétien

- La page, le bean de données, le backing bean - pp : 13/03/2015 - dm : 21/04/2015
- L'arbre des composants de la vue - pp : 13/03/2015 - dm : 13/03/2015


LA PAGE, LE BEAN DE DONNEES, LE BACKING BEAN

Révisions : 2015 - 21/04, 13/03, 11/03

C'est ça la bonne perspective :

- la page html/xhtml (la page jsf),

- qui affiche les champs d'un enregistrement, le bean de données,

- et dont le click du bouton "ok", est traité par une méthode du bean d'action, en charge de cette page.

Le bean de données

Le bean de données est un simple bean, un simple enregistrement (le client, la commande, la ligne de commande, etc ..), de type donc "pojo".

C'est un bean entité (annotation @Entity).

Il est prêt à être enregistré, persisté, par le service de persistence de l'entité, appelé depuis la méthode "ok" du bean d'action.

Le bean d'action

Le bean d'action est le "managed bean" (annotation @ManagedBean, @Named).

Il est géré, instancié automatiquement par l'outil (et détruit aussi) (en fonction de son "scope").

Sa vocation fondamentale est de gérer l'action de l'utilisateur (qui appuie sur "ok") pour cette page. C'est le contrôleur de cette "vue", en charge de cette vue.

Il traite, plus largement, toutes les actions de l'utilisateur sur cette page, cliks de boutons, de liens, de validation de saisie côté serveur, etc ..

Il a en particulier la charge d'appeler le service de persistence de l'entité, du bean de données à enregistrer, mais aussi de rechercher les beans de données à afficher (au travers toujours de leur service de persistence), lorsque l'utilisateur est en mode consultation et modifie ses critères.

Bean de données restant dans le bean d'action

Une pratique courante consiste à "laisser" le bean de données dans le bean d'action, de ne pas en faire un objet indépendant présent dans un scope.

Il apparaît alors, dans la page xhtml, préfixé par le nom du bean d'action, dont il est un attribut (accessible par un get).

Exemple (dans la page) : nom du client : #{gestionClient.leClient.nom}.

Ceci permet en particulier de gérer potentiellement simultanément plusieurs pages du même type, affichant chacune son propre client (typiquement avec des onglets).


L'ARBRE DES COMPOSANTS DE LA VUE

En JSF, la page xhtml stockée sur le serveur est parsée et traduite en un arbre de composants java standardisés (dérivant tous de la classe UIComponent) imbriqués, correspondant chacun à une balise présente sur cette page (un composant pour la balise <form>, un pour la balise <input>, etc ..).

Chacun de ces composants doit produire, doit fournir, son propre code html constituant la page html envoyée au browser client, sur l'appel de sa méthode de rendu render().

S'il contient un champ de donnée (champ <input>) il sera appelé un valueHolder, et recevra la valeur saisie par l'utilisateur, ou à afficher pour l'utilisateur.

Cet arbre est fabriqué la première fois qu'on appelle la page. Il est ensuite conservé pour les appels ultérieurs.

La plus grosse part des opérations sur les composants sont faites automatiquement (chargement des valeurs saisies par l'utilisateur, affectation ensuite au bean de donnée, contrôles) et c'est bien là l'immense intérêt. C'est une énorme économie de code (de 1 à 100), par rapport à la programmation très basique en mode servlet où il faut tout faire.

L'accès par programmation depuis le bean d'action à chacun de ces composants reste cependant pleinement possible en cas de besoin, mais cela est en pratique rare et très limité, à des opérations très simples (par exemple changer le style du composant, sa couleur, etc ..), et celà doit le rester. On ne modifiera la plupart du temps que les beans de données.