=> Annonce
=> What is New
=> Live Demo

• Les managed beans: là, c’est le bonheur. Du java pur et dur, on est libre de s’exprimer comme on veut (héritage/composition/délégation, etc.). Ajoutez Spring dans l’equation et on est proches de l’orgasme cérébral !
  Enfin, avec quelques limitations bien sûr (signature des actions, etc.).
• Richfaces/Ajax4jsf: J’en ai parlé à maintes reprises dans le forum, mais je tiens à en reparler ici: Impossible AMHA de battre Ajax4jsf comme moyen de faire de l’ajax via une taglib. J’ai bien dit pour une taglib car j’ai vu comment on procède avec Wicket, et c’est beaucoup plus puissant, mais c’est normal car on passe par Java.
• L’approche composants: je ne suis pas spécialement doué en HTML/CSS, et n’o n’avait pas une personne pareille dans l’équipe. C’est pour cela que j’ai énormément apprécié le fait qu’avec quelques lignes XML pour décrire le composant dans la page JSF, j’obtiens à l’exécution des trucs à couper le souffle côté visuel (Merci Richfaces)

Trois points seulement … mais c’est déjà ça

Mais je pense que vous êtes nombreux à attendre l’autre partie plutôt, the bad and the ugly

• Tooling: là, c’est un véritable cauchemar. On est sous eclipse europa, qui offre quelques fonctionnalités d’un IDE JSF, mais il en est encore loin … très loin. En fait, ça a tourné au vinaigre dès qu’on ne fait plus du JSF de base (sans jeux de composants additionnels ni facelets ni Spring).
  Mais dès qu’on essaies de faire quelque chose de puissant, eclipse nous a complètement laché.
  Il perd complètement les boules avec facelets, ce qui est tout simplement choquant, vu qu’aucun développeur JSF sérieux n’oserait faire sans facelets.
  D’ailleurs, eclipse s’est amélioré au fils des versions de maintenance (3.3.1.1 et 3.3.2), dans le sens où il accepte par exemple les pages xhtml dans l’editeur des règles de navigation, chose qu’il refusait avant, où qu’il offre l’auto-completion sur les jeux de composants standards (core et html) dans une page xhtml, mais il refuse de fonctionner pour facelets et tout autre jeu de composants.
  Exit l’aspect IDE et nous revoilà à l’époque de notepad, où on est censé taper des pages de quelques dizaines de lignes d’XML sans se tromper dans le nom d’un composant où d’un attribut.

  De plus, mais là c’est vivable, si on fait gérer ses managed beans par Spring, eclipse ne peut plus faire de l’auto-completion sur les ELs. D’ailleurs, il ne le fait plus du moment qu’on est dans une page xhtml et non pas JSP.

• Ca figure dans la liste des bonnes chose, mais également ici: le fait qu’on bosse sur les composants et que ça génère du HTML. J’en ai vu des vertes et des pas mûres à cause de cela, et le pire que tu ne peux rien y faire: des liens qui ne marchent pas, générant des erreurs JavaScript, des inputs qui ne sont pas envoyés lors d’un submit, des composant qui violent leur contrat, notamment les valueChangeListeners sur les inputText, etc.
  On se retrouvait alors obligés à faire de l’acrobatie en essayant de contourner ces problèmes avec des solutions plus sordides l’une que l’autre.
• Je sais que ça devrait être résolu dans JSF 2.0, ou encore déjà avec Seam et RestFaces, mais l’aspect fortement stateful de JSF peut vraiment devenir ennuyant, surtout si l’application est destinés à un utilisateur non forcément informaticien. Vas lui expliquer qu’il vaut mieux éviter le bouton retour du navigateur ou les F5 ou encore qu’il doit suivre une séquence particulière dans les pages pour arriver au résultat, et qu’il ne peut pas bookmarker des pages, etc.
• Les maudits erreurs de « View has Expired », et la gestion des erreurs en général qui est, et c’est un doux euphémisme, exécrable.
• Facelets: je l’ai déjà dit à maintes occasions: JSF sans Facelets c’est comme les oeufs avant la maîtrise du feu, mais la gestion/rapport d’erreurs de facelets est parfois cryptique et n’aide aucunement à leur localisation/correction.
  Par exemle, si dans un include on se trompe du nom du fichier à inclure, on obtient un beau 404 quand on essaie d’accèder à la page mère au lieu d’un message indiquant clairement l’origine de l’erreur… ainsi que dans d’autre cas où on obtenait des messages d’erreur cryptés sur 128 bits sans même le numéro de la ligne en cause.
• Difficile de faire quoi que soit d’utile avec le scope request. On se retrouve obligé de passer au scope session.
• Bouffeur de CPU: J’en parle dans ce billet.
• Mais le point noir à mon avis est la difficulté sordide de la tache de développement de composants personnels … C’est vrai que facelets essaies de simplifier ça, mais ça permet pas de développer de véritables composants personnels.

Impressionnant cette liste, non ? En relisant ce billet, je sens que c’est injuste pour JSF, car on a tout de même fait pas mal de trucs puissants avec, et ce en un temps record, ce qui est ne serait pas forcément la conclusion tirée par quelqu’un lisant ce billet

Pour résumer et rectifier un peu le tir, je dirais qu’avec JSF, on est pas loin de la règle de 80/20, mais que je transformerais en 80/60 au risque de casser sa beauté

• On fait 80% du boulot en 60% du temps attribué
• Et on se retrouve à combattre les 20% restantes du boulant dans le 40% du temps restant

Enfin, pour conclure, je ne suis aucunement en train de lancer une croisade contre JSF, loin de là même: JSF est toujours une option valable à envisager pour un nouveau projet. Seulement, comme tuotes les autres technos, JSF a ses défauts et un prix à payer.

• JSF: La Sun RI 1.2_07 (Mojarra)
• Richfaces 3.1.3
• Facelets
• Spring framework 2.5.1: pour la DI et pour l’abstraction JDBC
• De nombreuses commons de jakarta (dbcp, pooling, collections, logging, etc.)
• Log4j
• MySQL 5

L’IHM est assez complexe avec de l’Ajax à gog, des images complexes générées dynamiquement, et bien sûr, pour combler le tout, le volume des données traitées est imposant.

Donc, avant de lancer les tests, j’etais presque sûr que les goulots d’étranglement etaient dans la couche DAO, la couche services (à cause de calculs complexes) et peut être aussi dans la génération dynamique des images.

Vous vous en doutez déjà, j’avais complètement tort …
Voici un extrait des résultats du profiling (temps d’exécution) (réalisé avec TPTP):

Pour résumer, ou encore textuellement, ça donne:

1. 32% du temp processeur passé dans ajax4jsf, plus précisément dans le package component
2. 28% du temp processeur passé dans Mojarra, plus précisément dans le package component
3. 22% du temp processeur passé dans Richfaces, plus précisément dans le package component
4. Ensuite la couche JDBC ave 8%
5. 3% dans la génération dynamique des images (notre propre code, enfin)

Effrayant … 82% du temps processeur est consumé dans la couche présentation et est partagé par Mojarra, Richfaces et Ajax4jsf.
La logique métier, aussi complexe soit elle, n’apparait pas dans le top 10, donc consomme moins de 0.5% du temps processeur.
Même la couche JDBC, le usual suspect dans les problèmes de performances ne s’accapare que de 8% du gateau.

Il se peut que je refasses des tests vec MyFaces au lieu de Mojarra, car il est facile d’interchanger les implémentations JSF.
Par contre, il est trop tard pour ce qui est de Richfaces/Ajax4jsf.

Là, je me poses des questions … Est ce que ça vient de notre IHM complexe et/ou style de codage ou est ce que c’est plutôt de la faute des librairies utilisées ?
Et est ce spécifique à JSF ou est ce que ça touche d’autres frameworks ?

N’hésitez pas à faire part de vos propres expériences

• L’objet Item représente un article. Il contient juste un identifiant, un nom et un prix.

package model; 

 

public class Item { 

  private String name; 

  private Long price; 

  private Long id; 

 

  public Item() { 

  } 

 

  public Item(String name, Long price) { 

    this.name = name; 

    this.price = price; 

  } 

 

  public String getName() { 

    return name; 

  } 

 

  public void setName(String name) { 

    this.name = name; 

  } 

 

  public Long getPrice() { 

    return price; 

  } 

 

  public void setPrice(Long price) { 

    this.price = price; 

  } 

 

  public Long getId() { 

    return id; 

  } 

 

  public void setId(Long id) { 

    this.id = id; 

  } 

}

Passons maintenant au contrôleurs JSF. On en a deux:

• ItemCtrl: Un simple pojo qui expose une liste d’Items.
• CartCtrl: Contient lui une liste d’Items qui représente les articles achetés jusque là ainsi qu’un champ price qui contient le prix total des articles achetés.
  De plus, c’est ce contrôleur qui gère l’évènement drop généré lorsque l’on dépose un article sur le panneau.

Voici le code d’ItemCtrl

package control; 

 

import java.util.ArrayList; 

import java.util.List; 

 

import model.Item; 

 

public class ItemsCtrl { 

  private List<item> items = new ArrayList<item>(); 

 

  public ItemsCtrl() { 

    items.add(new Item("Montre", 50L)); 

    items.add(new Item("Table", 450L)); 

    items.add(new Item("Chaise", 150L)); 

    items.add(new Item("Moquette", 250L)); 

    items.add(new Item("Lit", 750L)); 

    items.add(new Item("Armoire", 1050L)); 

    items.add(new Item("Ordinateur", 750L)); 

    items.add(new Item("Imprimante", 90L)); 

  } 

 

  public List<item> getItems() { 

    return items; 

  } 

 

  public void setItems(List<item> items) { 

    this.items = items; 

  } 

}

Rien de spécial à dire à propos de cette classe (juste un détail, dans le constructeur, j’ai ajouté quelques articles fictifs pour égayer un peu l’application !)
Maintenant, le code de CartCtrl:

package control; 

 

import java.util.ArrayList; 

import java.util.List; 

import org.richfaces.event.DropEvent; 

 

import model.Item; 

 

public class CartCtrl { 

  private List<item> items = new ArrayList<item>(); 

  private Long price = 0L; 

 

  public void onDropItem(DropEvent e) { 

 

    Item i = (Item) e.getDragValue(); 

    items.add(i); 

    price += i.getPrice(); 

  } 

 

  public List<item> getItems() { 

    return items; 

  } 

 

  public void setItems(List<item> items) { 

    this.items = items; 

  } 

 

  public Long getPrice() { 

    return price; 

  } 

 

  public void setPrice(Long price) { 

    this.price = price; 

  } 

}

Le seul point à expliquer ici est la méthode onItemDrop.
Cette méthode ne retourne rien (void) et accepte un paramètre de type org.richfaces.event.DropEvent
qui contient toutes les informations relatives à un évènement Drag and Drop.
En particulier, on a le champ dragValue (Object) qui contient l’objet qu’on a déplacé et lâché au dessus du panneau. Ici, c’est un Item. Dès lors, on l’ajoute à la liste des articles achetés et on incrémente le prix total des achats.

Passons maintenant à la couche présentation.
Pour afficher la liste des articles, j’ai décidé d’utiliser le composant DataGrid de RichFaces qui ressemble au DataTable mais qui affiche les données exactement comme le composant PanelGrid de JSF:

<rich:dataGrid value="#{itemsCtrl.items}" var="item" columns="3"> 

  <h:panelGrid border="0" columns="2"> 

    <h:outputText value="Nom: " /> 

    <h:outputText value="#{item.name}" /> 

    <h:outputText value="Prix: " /> 

    <h:outputText value="#{item.price}" /> 

  </h:panelGrid> 

</rich:dataGrid>

Voici ce que ça donne:

On va maintenant rendre les éléments draggables. Pour ce faire, il suffit d’ajouter le composant dragSupport de RichFaces dans chaque article. Comme le composant support d’ajax4Jsf (présenté dans les posts précédents), ce composant ajouté le comportement draggable au composant qui le contient.

Dans notre cas, on va placer le panelGrid sur lequel on itère dans le composant a4j:outputPanel (dragSupport impose quelques limitations sur le conteneur, et il se trouve que outputPanel les satisfait). On ajoutera ensuite dragSupport dans le outputPanel, ce qui donne:

<rich:dataGrid value="#{itemsCtrl.items}" var="item" columns="3"> 

  <a4j:outputPanel layout="block" style="cursor: move"> 

    <rich:dragSupport dragType="item" dragValue="#{item}" /> 

    <h:panelGrid border="0" columns="2"> 

      <h:outputText value="Nom: " /> 

      <h:outputText value="#{item.name}" /> 

      <h:outputText value="Prix: " /> 

      <h:outputText value="#{item.price}" /> 

    </h:panelGrid> 

  </a4j:outputPanel> 

</rich:dataGrid>

Comme principaux paramètres, dragSupport prend:

• dragType: une chaine qui identifie le type de l’élément. C’est surtout utile pour pouvoir discerner entre plusieurs types d’éléments draggables. Ici, on en a qu’un seul, et on le nomm item.
• dragValue: la valeur de l’élément draggé. C’est cette valeur là qui sera récupéré dans DropEvent.getDragValue (cf plus haut). Ici, on met l’Item courant.

Reste maintenant à définir la zone de drop.
Comme pour le drag, on définit une telle zone en incluant le composant dropSupport:

<a4j:outputPanel layout="block"> 

  <rich:dropSupport acceptedTypes="item" dropListener="#{cartCtrl.onDropItem}" 

      reRender="boughtItems, totalPrice" dropValue="x" /> 

  <h:graphicImage url="/pics/shopping_cart.png" /> 

</a4j:outputPanel>

En gros, il s’agit d’une image à l’intérieur dans outputPanel pour les même raisons que pour le dragSupport).
Les attributs de dropSupport sont:

• acceptedType: un liste de types d’éléments acceptés par cette zone. Ici, on ne a qu’un seul qui est item (cf attribut dragType du composant dragSupport).
• dropListener: la méthode d’un managed bean qui sera appelée lorsque le drag and drop est terminé (cf CartCtrl.onDropItem).
• reRender: les identifiants des composants à re-dessiner à la réception de la réponse de la requête générée par le drop.

N.B: Il faut mettre les composants dragSupport (ainsi que ses parents) et dropSupport (ainsi que ses parents) dans un formulaire et dans le même formulaire !

Reste enfin à afficher les articles achetés ainsi que le prix total:

<rich:dataList id="boughtItems" value="#{cartCtrl.items}" var="item"> 

  <h:outputText value="#{item.name}" /> 

  </rich:dataList> 

<h:outputText id="totalPrice" value="Prix total: #{cartCtrl.price}" />

Voilou ! C’est un peu long parce qu’on est passé par un exemple plus ou moins réaliste et pratique, mais c’est hyper-simple dans le fond !

Voici pour conclure un petit shot de l’application:

<filter> 

   <display-name>RichFaces Filter</display-name> 

   <filter-name>richfaces</filter-name> 

   <filter-class>org.ajax4jsf.Filter</filter-class> 

</filter> 

<filter-mapping> 

   <filter-name>richfaces</filter-name> 

   <servlet-name>Faces Servlet</servlet-name> 

   <dispatcher>REQUEST</dispatcher> 

   <dispatcher>FORWARD</dispatcher> 

   <dispatcher>INCLUDE</dispatcher> 

</filter-mapping>

Attaquons maintenant le jeu. On commence par créer un simle POJO (le managed bean) qui servira à stocker le nom saisi par l’utilisateur:

public class HelloBean { 

     private String name; 

 

     public String getName() { 

        return name; 

     } 

 

     public void setName(String name) { 

        this.name = name; 

     } 

}

On déclare ensuite ce bean dans faces-config.xml pour qu’il soit accessible depuis les pages JSF:

<managed-bean> 

     <managed-bean-name>helloBean</managed-bean-name> 

     <managed-bean-class>HelloBean</managed-bean-class> 

     <managed-bean-scope>request</managed-bean-scope> 

</managed-bean>

On crée ensuite une première pages (index.jsp) qui se contente de « forwarder » vers la page JSF:

<jsp:forward page="hello.jsf" />

Enfin, on arrive aux choses sérieuses: du JSF et de l’AJAX. Dans la page hello.jsp, et à l’intérieur de l’élément view:

<h:outputText value="Name :" /> 

<h:form> 

   <h:inputText value="#{helloBean.name}"> 

      <a4j:support event="onchange" reRender="greeting" /> 

   </h:inputText> 

</h:form> 

<h:outputText id="greeting" value="Hello #{helloBean.name} !" />

Toute la magie de la chose est réalisée par le <a4j:support>. Il permet d’ajaxifier n’importe quel composant JSF standard. Ce composant est très flexible et a de nombreux usages, mais dans ce cas particulier, on l’a utilisé pour capturer l’évènement onchange (javascript), formuler une requête AJAX et redessiner le composant outputText (reRender= »greeting ») à la reception d’une réponse à cette requête. C’etait le comportement côté client. Côté serveur, RichFaces s’occupe de décoder la requête AJAX, mettre à jour le champ « name » de notre managed bean et formuler la réponse.

C’etait un aperçu rapide de la simplicité et la puissance de RichFaces.
Comptez sur moi pour d’autres exemples dans les prochains billets.

public class GameBean { 

  private int magic; 

  private Random random; 

  private String guess; 

  private String message; 

 

  public GameBean() { 

    random = new Random(); 

    reset(); 

  } 

 

  private void reset() { 

    magic = random.nextInt(100) + 1; 

    guess = ""; 

    message = "..."; 

  } 

 

  public String check() { 

    int x = 0; 

    try { 

       x = Integer.parseInt(guess); 

       if (x < 1 || x > 100) 

           throw new Exception(); 

    } catch (Exception e) { 

       message = "Entrée non valide"; 

       return null; 

    } 

 

    if (x < magic) { 

       message = "Trop petit !"; 

    } else if (x > magic) { 

       message = "Trop grand !"; 

    } else { 

       message = "Excellent ! Le nombre magique était " + magic; 

    } 

    return null; 

  } 

 

  public int getMagic() { 

    return magic; 

  } 

 

  public String getGuess() { 

    return guess; 

  } 

 

  public void setGuess(String guess) { 

    this.guess = guess; 

  } 

 

  public String getMessage() { 

    return message; 

  } 

}

Voici rapidement de quoi il s’agit:

• Le champ magic (int) va contenir le nombre à deviner.
• Le champ random (java.util.Random) servira à générer les nombres aléatoires.
• Le champ guess (String) servira à receuillir les essais de l’utilisateur. Normalement, il devrait être de type int combiné avec un converter dans la page JSF, mais bon, j’ai omis ça pour simplifier la chose.
• Le champ message servira à contenir la réponse de l’application suite à un essai du joueur (trop grand, trop petit, etc.)
• La méthode privée reset() sera appelée à l’initialisation du jeu pour générer le nombre aléatoire.
• La méthode check() est une action JSF (type de retour String, sans paramètres) quis era appelé à chaque entrée utilisateur pour la vérifier.
  N.B: check retourne toujours null, et ce pour rester dans la même page.
• Les méthodes restantes ne sont que des getters et des setters pour exposer nos champs à l’EL (aux pages JSF).

Passons maintenant à la partie présentation. Notre jeu tiendra dans une seule page.
Normalement (sans Ajax), nous aurions déclaré dans un élément de type avec un inputText la dedans bindé avec notre #{guessBean.guess} ainsi qu’un outputText bindé avec #{guessBean.message} qui affichera le résultat, un truc de ce genre:

<h:form> 

  <h:inputText value="#{gameBean.guess}" /> 

  <h:outputText value="#{gameBean.message}" /> 

  <h:commandButton value="Check" action="#{gameBean.check}" /> 

</h:form>

En cliquant sur le commandButton « check », le formulaire sera envoyé et traité par JSF, ce qui implique entre autre que gameBean.guess se verra affecter la valeur entrée dans le champ texte. Ensuite, la méthode gameBean.check() à sera appelé qui va mettre dans le champ message le résultat de la vérification et retournera null. JSF retournera la main alors à la même page qui sera rendu à nouveau mais avec le message adéquat.

Nous allons maintenant ajaxifier la chose avec RichFaces (ou plus exactement avec Ajax4Jsf).
Dans une première passe (et là, c’est vraiment magique ;-)), on se contente de remplacer le composant form de JSF par celui d’Ajax4Jsf, comme ça:

<a4j:form> 

  <h:inputText value="#{gameBean.guess}" /> 

  <h:outputText value="#{gameBean.message}" /> 

  <h:commandButton value="Check" action="#{gameBean.check}" /> 

</a4j:form>

N.B: l’uri qu’il faut importer pour utiliser les comosants a4j est: http://richfaces.org/a4j

Relançons l’application.
A première vue rien ne se passe: suite à un clic sur le commandButton, absolument rien ne se passe … mais en fait si ! Pour s’en convaincre, il suffit d’ajouter un simple :
System.out.println(« check « +guess);
au tout début de GameBean.check().
Réessayez de nouveau … et vous remarquerez que chaque fois que l’on appuie sur le commandButton, une ligne telle que celle-ci s’ajoute dans la console (d’eclipse par exemple):

    check 45
    check 23

Explication ? intercepte tout submit déclenché par un de ses fils (ici, le commandButton) et le traduit en requête ajax vers le serveur où elle sera traité.
Mais alors, pourquoi le message ne change pas ?
C’est simple, il suffit d’indiquer à quels composants il faut re-dessiner à la reception d’une réponse ajax. Ce comportement est plus qu’il y’a de naturel, autrement, on devrait re-dessiner tout faute de savoir qu’est ce qui a changé, ce qui revient à un submit http classsique et non plus Ajax.
Notre code devient donc:

<a4j:form reRender="out" > 

  <h:inputText value="#{gameBean.guess}" /> 

  <h:outputText value="#{gameBean.message}" id="out" /> 

  <h:commandButton value="Check" action="#{gameBean.check}" /> 

</a4j:form>

J’ai ajouté :

• l’attribut reRender= »out » dans <a4j:form>
• L’attribut id= »out » dans <h:outputText>

Ce qui tout naturellement veut dire « re-dessiner le composant dans l’identifiant est out à la reception d’une réponse ajax ».
N.B: reRender n’est pas limité à un seul identifiant, et peut prendre une liste d’attributs à re-dessiner, comme par exemple reRender= »out, x, y, z ».

En relançant l’application avec ces modifications, on aura notre guess-game version AJAX !
Pour approfondir la chose, vous pouvez essayer d’ajouter un compteur trials qui indique au fur et à mesure combien d’essaies le joueur a fait + un bouton rejouer qui ne s’affiche que lorsque la réponse est bonne (le second point, je vous le dis d’avance, est un casse-gueule … j’expliquerais pourquoi dans un prochain post).