L'écriture des formulaires JSF ne déroutera pas l'habitué des formulaires JSP. On utilisera par exemple :
<h:form id="administratorAddForm"> <h:messages /> <h:outputLabel for="ldapUid" value="#{msgs['ADMINISTRATOR_ADD.TEXT.PROMPT']}" /> <h:inputText id="ldapUid" value="#{administratorsController.ldapUid}" required="true" /> <h:message for="ldapUid" /> <h:commandButton value="#{msgs['ADMINISTRATOR_ADD.BUTTON.ADD_ADMIN']}" action="#{administratorsController.addAdmin}" /> <h:commandButton value="#{msgs['_.BUTTON.CANCEL']}" action="cancel" immediate="true" /> </h:form> |
L'attribut value de la balise <h:inputText> contient une référence vers un attribut du contrôleur. Cet attribut sera mis à jour lors de la validation du formulaire. L'attribut action du bouton <h:commandButton> contient une référence vers la callback (méthode) du contrôleur. C'est elle qui sera appelée lors de l'appui sur le bouton et dont le résultat sera utilisé par les règles de navigation pour connaître la page que l'application doit afficher en retour.
Le deuxième bouton a un attribut immediate="true". Dans ce cas, les attributs du contrôleur relatifs aux balises <h:inputText> ne seront pas mis à jour et les éventuelles vérifications de forme ou de contenu ne seront pas exécutées. Ceci est particulièrement utile sur un bouton d'annulation comme c'est le cas ici.
Voir tous les composants ici http://www.horstmann.com/corejsf/jsf-tags.html
Les balises <h:messages> et <h:message> sont traitées dans un paragraphe à suivre.
Ajouter une entrée Test1 dans la barre de navigation (_navigationItems.jsp) qui sera toujours affichée (pas d'attribut rendered) et dont l'action sera gotoTest1 (en dur).
|
Créer la page test1.jsp, (la créer à partir de about.jsp, en ne gardant que la barre de navigation) et tester (elle doit s'afficher). Note : la page doit s'afficher maintenant qu'elle existe.
|
Ajouter un formulaire avec un bouton Move sur la page, dont l'action gotoWelcome envoie sur la page welcome.jsp.
|
Ajouter une classe contrôleur Test1Controller (la créer à partir de AboutController), ajouter à cette classe une méthode callback() qui renvoie la chaîne gotoWelcome, et appeler cette méthode en réaction au bouton de la page test1.jsp.
|
Dans une page JSP les balises <h:messages> et <h:message> permettent d'afficher des messages d'erreur à l'utilisateur.La balise <h:messages> permet d'afficher l'ensemble des messages d'erreurs. La balise <h:message> permet d'afficher les messages d'erreurs relatifs à une balise <h:inputText> particulière. Elle dispose, à cet effet, d'un attribut for qui lui permet de faire le lien avec un attribut id d'une balise <h:inputText> donnée. Ce mécanisme est notamment utilisé quand l'attribut required de la balise <h:inputText> est positionné à true ou bien quand un validateur (cf. ci-dessous) lui est associé.Il est aussi possible, dans une callback d'un contrôleur, de remonter des messages d'erreurs vers la vue. Ces messages seront généralement rendus grâce à la balise <h:messages>. Typiquement, la callback renverra null, c'est-à-dire que la page affichée à l'utilisateur restera la même (celle où s'est produite l'erreur de saisie). Dans l'exemple suivant, on affiche un message si l'utilisateur correspondant à l'identifiant donné est déjà administrateur :
User user = getDomainService().getUser(ldapUid); if (user.getAdmin()) { addErrorMessage( "form:uid", "ADMINISTRATORS.MESSAGE.USER_ALREADY_ADMINISTRATOR", ldapUid); return null; } |
Le premier paramètre de la méthode addErrorMessage vaut "uid". Le message ajouté sera alors affiché par la balise <h:message for="uid">. Il est également possible de spécifier un premier paramètre null ; le message d'erreur sera global, c'est-à-dire affiché par la balise <h:messages>.
Ajouter une boîte de saisie (id="myInput") au dessus du bouton dans le formulaire, lier le contenu de la boite à une propriété myInput de test1Controller, et modifier la méthode callback() pour qu'elle ne renvoie vers la page d'accueil que si myInput a au moins deux caractères ou sinon, reste sur la vue test1.jsp en affichant le message d'erreur TEST1.MESSAGE.SHORT.
|
Il existe des validateurs par défaut dans JSF (validateLength, validateLongRange et validateDoubleRange), par exemple :
<h:inputText id="age" value="#{testController.age}"> <f:validateLongRange minimum="18"/> </h:inputText> <h:message for="age"/> |
On peut trouver d'autres validateurs que ceux fournis par défaut, Tomahawk propose par exemple validateCreditCard, validateUrl, validateEmail, validateEqual et validateRegExpr.
Ajouter un validateur prédéfini à la boite de saisie et supprimer le code correspondant de la méthode callback() (utiliser le validateur validateLength)
|
Il est aussi possible d'écrire ses propres validateurs. Leur mise en œuvre est relativement simple, par exemple :
<h:inputText id="age" value="#{testController.age}" validator="#{bean.validateAge}"> </h:inputText> |
La méthode validateAge de bean ressemblera à :
public void validateAge( FacesContext context, UIComponent componentToValidate, Object value) throws ValidatorException { if (...) { throw new ValidatorException(getFacesErrorMessage("MESSAGE.ALWAYS_ERROR")); } } |
Ajouter un validateur personnalisé validateMyInput() à la boite de saisie qui se charge de lancer une exception à la place de la méthode callback().
|
http://www.jmdoudoux.fr/java/dej/chap-validation_donnees.htm
http://musingsofaprogrammingaddict.blogspot.com/2009/01/getting-started-with-jsr-303-beans.html
http://www.touilleur-express.fr/2008/06/06/jsr-303-vous-avez-valide-votre-bean/
http://www.openscope.net/2010/02/08/spring-mvc-3-0-and-jsr-303-aka-javax-validation
Au cours du développement d'une application web on constate la nécessité de valider les objets manipulés à différents niveau :
On en vient souvent à dupliquer les contraintes à chaque niveau et de façon pas toujours cohérentes (ex: on limite un champs à 50 caractères dans un formulaire alors que la colonne correspondante en base est un varchar(100)
Pour répondre à cela la JSR 303 propose une spécification standard pour la validation des beans.
On utilisera alors les annotations introduites en Java 5 pour exprimer les contraintes sur le bean.
Exemple :
package org.esupportail.example.web.beans; import javax.validation.constraints.NotNull; import javax.validation.constraints.Size; public class UserBean{ /** * Id of the user. */ @NotNull private String id; /** * Display Name of the user. */ @Size(max = 10, min = 1) private String displayName; [...] } |
Pour utiliser javax.validation il faudra alors ajouter dans le pom.xml la dépendance suivante :
<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-validator</artifactId> <version>4.0.2.GA</version> </dependency> |
Exemple de contraintes :
On peut également imaginer un bean qui cumulerait les annotations nécéssaires à la validation et les annotations nécessaires à la persistance.
http://www.hibernate.org/subprojects/validator.html
Implémentation hibernate validator intègre la validation du bean au niveau de la persistance.
elle propose quelques contraintes supplémentaires à celles de la spécifictation JSR 303 comme :
JSF 2 intègre par défaut la validation des beans (JSR 303)
http://www.mastertheboss.com/web-interfaces/293-jsf-validation-tutorial.html?start=2
Dès lors, les pages JSF n'ont plus besoin de contenir les information de validation du bean. Lorsque une validation de contrainte échoue, les messages d'erreur associés sont automatiquement traduits en FacesMessage par l'implementation JSF.
On pourra toutefois les désactiver :
<h:inputText value="#{sampleBean.userName}"> <f:validateBean disabled="true" /> </h:inputText> |
On peut définir le message qui sera affiché en cas d'erreur de validation en précisant un attribut message dans l'annotation
@Size(max = 10, min = 1, message="{toto}") |
Ici on utilise une clé (chaîne entre accolades) afin d'aller chercher le message dans un fichier de propriétés. Ce fichier doit se trouver dans le classpath et porter le nom ValidationMessages.properties
On peut le décliner ne fonction des langues ValidationMessages_en.properties, ValidationMessages_fr.properties
updateActionListener est une balise de la librairie JSF Tomahawk qui est particulièrement utile. C'est un listener qui est associé à une balise permettant une action (bouton, lien) qui, au moment où ce dernier est activé, va lire le contenu de son attribut value pour l'assigner à la référence contenue dans son attribut property.On utilisera par exemple :
<h:commandButton action="deleteUser" value="#{msgs['BUTTON.DELETE']}"> <t:updateActionListener value="#{user}" property="#{controller.userToDelete}" /> </h:commandButton> |
Ici, l'action deleteUser va diriger l'utilisateur vers une autre page (typiquement une page de demande de confirmation avant d'effacer l'administrateur), via le fichier de règles de navigation. La présence de la balise updateActionListener fait que le moteur JSF aura, avant d'effectuer le changement de page, positionné la valeur de #{user} dans l'attribut userToDelete du contrôleur controller. La page de confirmation de l'effacement pourra alors faire appel à ce contrôleur pour générer un contenu en fonction de la valeur de cet attribut.
Il est à noter que, dans cet exemple JSF, user est un objet de type complexe et pas simplement une chaîne de caractères comme on peut en avoir l'habitude en développement web classique.
Faire une vue test2.jsp qui s'appuie sur un contrôleur test2Controller qui possède une propriété chaîne de caractères value. Cette vue test2.jsp ne fait qu'afficher la valeur de value. Rajouter un bouton SetTest2Value à la vue test1.jsp et faire en sorte qu'appuyer sur ce bouton, mette dans test2Controller.value la valeur de myInput.
|
|
Il existe des convertisseurs par défaut dans JSF (DateTimeConverter et NumberConverter). Ils permettent de transformer une date ou un nombre suivant différentes règles, par exemple :
<h:outputText value="#{testController.date}"> <f:convertDateTime dateStyle="short" locale="#{sessionController.locale}"/> </h:outputText> |
Dans certains cas, il est aussi nécessaire de définir des convertisseurs manuellement. C'est notamment le cas pour les listes déroulantes. Considérons que l'on veuille afficher une liste déroulante permettant à l'utilisateur de choisir un objet de type Locale. Pour la génération du HTML, JSF a besoin d'une représentation textuelle de chaque objet de la liste. De même, il a besoin de pouvoir retrouver un objet depuis un choix de l'utilisateur qui correspond à la valeur textuelle de la balise <option> du formulaire HTML. C'est le rôle du convertisseur converter de faire ce travail :
<h:selectOneMenu id="locale" onchange="submit();" value="#{preferencesController.locale}" converter="#{localeConverter}"> <f:selectItems value="#{preferencesController.localeItems}"/> </h:selectOneMenu> |
Ici, la liste déroulante est constituée d'objets de type Locale. Le convertisseur localeConverter est défini (par convention dans esup-commons) dans le fichier /properties/web/converters.xml :
<bean id="localeConverter" class="org.esupportail.commons.web.converters.LocaleConverter"> <description> A converterforLocale objects. </description> </bean> |
La classe LocaleConverter implémente l'interface Converter de JSF.
Un des objectifs de l'utilisation de JSF est, via un standard de haut niveau, de tendre vers plus d'accessibilité (WAI : Web Accessibility Initiative). L'accessibilité des applications doit être une préoccupation constante des programmeurs, qui ne doivent pas hésiter à tester leurs applications en utilisant des navigateurs pauvres tels que Lynx. En règle générale, on évitera absolument d'utiliser les balises h:commandLink qui, à cause de l'utilisation de Javascript, brisent toutes les règles de l'accessibilité. On préfèrera dans tous les cas des boutons (h:commandButton). Javascript peut néanmoins être utilisé pour améliorer l'IHM des applications, en faisant attention à ce que les navigateurs ne parlant pas Javascript puissent quand même utiliser l'application. Nous montrons ici à titre d'exemple comment on peut soumettre un formulaire par simple changement de la valeur d'une boite déroulante :
<h:form id="form"> <h:messages /> <h:outputLabel for="value" value="#{msgs['TEXT.VALUE']}"/> <h:selectOneMenu id="value" onchange="submit();" value="#{controller.value}"> <f:selectItems value="#{controller.valueItems}"/> </h:selectOneMenu> <h:commandButton value="#{msgs['BUTTON.CHANGE']}" id="changeButton"/> </h:form> <script type="text/javascript"> hideButton("form:changeButton"); </script> |
Le bouton changeButton est caché par du codeJavascript.
Les clients qui parlent Javascript ne le voient pas ; ce n'est pas grave puisqu'un changement de valeur de la boite de sélection déroulante soumet automatiquement le formulaire (onchange="submit();"). Les clients qui ne parlent pas Javascript voient le bouton, et peuvent donc valider le formulaire.