Exemple

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 <e: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 <e: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 <e: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.

Les balises <h:messages> et <h:message> sont traitées dans un paragraphe à suivre.

<%@include file="_include.jsp"%>
<h:page stringsVar="msgs" menuItem="test1"
   locale="#{sessionController.locale}">
  <%@include file="_navigation.jsp"%>

</h:page>

<%@include file="_include.jsp"%>
<h:page stringsVar="msgs" menuItem="test1"
   locale="#{sessionController.locale}">
  <%@include file="_navigation.jsp"%>
  <h:form>
    <h:commandButton value="Move"
	action="gotoWelcome"/>
  </h:form>
</h:page>

<navigation-rule>
  <from-view-id>/stylesheets/test1.jsp</from-view-id>
  <navigation-case>
    <from-outcome>gotoWelcome</from-outcome>
    <to-view-id>/stylesheets/welcome.jsp</to-view-id>
    <redirect />
   </navigation-case>
</navigation-rule>

avec une méthode callback :
/**
 * JSF callback.
 * @return A String.
 */
public String callback() {
  return "gotoWelcome";
}

<bean id="test1Controller"
  class="org.esupportail.formation.web.controllers.Test1Controller"
  parent="abstractContextAwareController"
  scope="session"
  >
  <description>A bean to manage the test1 page.</description>
</bean>

<%@include file="_include.jsp"%>
<h:page stringsVar="msgs" menuItem="test1"
   locale="#{sessionController.locale}">
  <%@include file="_navigation.jsp"%>
  <h:form>
    <h:commandButton value="Move"
	action="#{test1Controller.callback}"/>
  </h:form>
</h:page>

Messages d'erreur

Dans une page JSP les balises <e:messages> et <e:message> permettent d'afficher des messages d'erreur à l'utilisateur.La balise <e:messages> permet d'afficher l'ensembles des messages d'erreurs.La balise <e:message> permet d'afficher les messages d'erreurs relatifs à une balise <e: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 <e:inputText> donnée. Ce mécanisme est notamment utilisé quand l'attribut required de la balise  <e: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 <e: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 <e: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 <e:messages>.

addErrorMessage("form:myInput", "TEST1.MESSAGE.SHORT"))

private String myInput;

public String getMyInput() {
  return myInput;
}

public void setMyInput(String myInput) {
  this.myInput = myInput;
}

/* JSF callback.
 * @return A String.
 */
public String callback() {
  if (myInput.length() < 2) {
	addErrorMessage(null, "TEST1.MESSAGE.SHORT");
	return null;
  }
  return "gotoWelcome";
}

Exemple pour messages_fr.properties
TEST1.MESSAGE.SHORT = Le champ "myInput" doit contenir plus de 2 caractères.

<%@include file="_include.jsp"%>
<h:page stringsVar="msgs" menuItem="test1" locale="#{sessionController.locale}">
  <%@include file="_navigation.jsp"%>
  <h:form>
	<h:messages/>
	<h:inputText value="#{test1Controller.myInput}" required="true"/>
	<h:commandButton value="Move"
	action="#{test1Controller.callback}"/>
  </h:form>
</h:page>

Validation des formulaires

Utilisation des validateurs prédéfinis

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.

/**
 * JSF callback.
 * @return A String.
 */
public String callback() {
  return "gotoWelcome";
}

<%@include file="_include.jsp"%>
<h:page stringsVar="msgs" menuItem="test1" locale="#{sessionController.locale}">
  <%@include file="_navigation.jsp"%>
  <h:form>
    <h:messages/>
    <h:inputText value="#{test1Controller.myInput}" required="true">
	<f:validateLength minimum="3"/>
    </h:inputText>
    <h:commandButton value="Move"
	action="#{test1Controller.callback}"/>
  </h:form>
</h:page>

Développement de validateurs personnalisés

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"));
  }
}

/**
 * @param context
 * @param componentToValidate
 * @param value
 * @throws ValidatorException
 */
public void validateMyInput(FacesContext context,
  UIComponent componentToValidate,
  Object value) throws ValidatorException {
  String strValue = (String) value;
  if (strValue.length() < 2) {
	throw new ValidatorException(getFacesErrorMessage("TEST1.MESSAGE.SHORT"));
  }
}

<%@include file="_include.jsp"%>
<h:page stringsVar="msgs" menuItem="test1" locale="#{sessionController.locale}" >
 <%@include file="_navigation.jsp"%>
 <h:form>
   <h:messages/>
   <h:inputText value="#{test1Controller.myInput}" required="true"
      validator="#{test1Controller.validateMyInput}"/>
   <h:commandButton value="Move"
	action="#{test1Controller.callback}"/>
 </h:form>
</h:page>

Mise à jour de propriétés par les formulaires (updateActionlistener)

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.

private String value;
public String getValue() {
  return value;
}
public void setValue(String value) {
  this.value = value;
}

<bean id="test2Controller"
  class="org.esupportail.formation.web.controllers.Test2Controller"
  parent="abstractContextAwareController"
  scope="session"
  >
  <description>A bean to manage the test2 page.</description>
</bean>

<%@include file="_include.jsp"%>
<h:page stringsVar="msgs" menuItem="test2" locale="#{sessionController.locale}">
 <%@include file="_navigation.jsp"%>
 <h:form>
  <h:outputText value="#{test2Controller.value}"/>
 </h:form>
</h:page>

<navigation-rule>
  <from-view-id>/stylesheets/test1.jsp</from-view-id>
  <navigation-case>
    <from-outcome>gotoWelcome</from-outcome>
    <to-view-id>/stylesheets/welcome.jsp</to-view-id>
    <redirect />
  </navigation-case>
  <navigation-case>
    <from-outcome>gotoTest2</from-outcome>
    <to-view-id>/stylesheets/test2.jsp</to-view-id>
    <redirect />
  </navigation-case>
</navigation-rule>

<%@include file="_include.jsp"%>
<e:page stringsVar="msgs" menuItem="test1" locale="#{sessionController.locale}">
  <%@include file="_navigation.jsp"%>
  <h:form>
    <h:messages/>
    <h:inputText value="#{test1Controller.myInput}"
        validator="#{test1Controller.validateMyInput}"/>
    <h:commandButton value="Move"
      action="#{test1Controller.callback}"/>
    <h:commandButton value="SetTest2Value"
      action="gotoTest2">
       <t:updateActionListener value="#{test1Controller.myInput}"
	  property="#{test2Controller.value}"/>
    </h:commandButton>
  </h:form>
</h:page>

Conversion des types complexes

Il existe des convertisseurs par défaut dansJSF (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.

JSF et accessibilité

Un des objectifs de l'utilisation de JSF est, via un standard de haut niveau, de tendre vers plus d'accessibilité (WAI). 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, tel 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 (e: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.