Gagner en productivité avec Java Server Faces

| Xavier Paradon | Valtech |

Dans la grande famille des frameworks Web du monde J2EE, voilà Java Server Faces (JSF). Un de plus me direz-vous. Certes, mais si toutes les améliorations apportées à la construction d'applications Web en Java ont jusqu'à maintenant été insuffisantes, c'est bien dans la productivité attendue des développeurs.

Si JSF reprend de nombreux frameworks Web utilisant les règles de conception courantes, il amène en revanche des idées intéressantes ayant fait leurs preuves dans le développement de clients graphiques lourds comme la gestion d'évènements ou l'utilisation de composants graphiques. A-t-on enfin trouvé l'équilibre entre les méthodes qui ont fait le succès de Delphi ou VB et celles qui font l'universalité du Web ? C'est ce que nous allons voir en gardant un œil sur la problématique de la productivité.

Il va être essentiellement question dans cet article du fonctionnement de JSF, des publics ciblés par JSF et des bibliothèques de composants.

- Titre : Gagner en productivité avec Java Server Faces

- Auteurs : Xavier Paradon, Valtech

- Parution : 29 mars 2007

- Mise à jour : 23 février 2020

- Licence : Copyright ® 2007 Valtech. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Petit historique ou pourquoi JSF

- I-A. Évolution des technologies dynamiques

- I-B. ASP.Net et ses WebForms

- I-C. Naissance de JSF

- II. Anatomie de JSF

- II-A. Un modèle MVC2

- II-A-1. Des règles de navigation

- II-A-2. Des composants réutilisables

- II-A-3. Des évènements

- II-A-4. Des liens simples avec le modèle

- II-A-5. Des classes graphiques

- II-B. Un cycle de vie complet

- II-C. Une totale flexibilité

- III. Développement rapide avec JSF

- III-A. Points forts de JSF

- III-B. Environnements graphiques

- III-C. Bibliothèques de composants

- IV. Conclusion

- V. Remerciements

I - Petit historique ou pourquoi JSF

I-A - Évolution des technologies dynamiques

La création d'applications Web dynamiques est depuis quelques années une source toujours croissante de nouveaux développements que ce soit pour des applications internes ou pour des sites commerciaux. Face à l'importance et à l'hétérogénéité de ces demandes, de nombreuses technologies sont apparues comme ASP puis ASP.Net, PHP aujourd'hui en version 5 et parmi les plus récentes le très à la mode Ruby On Rails.

Les évolutions de ces technologies visent essentiellement deux objectifs : mieux concevoir son application Web et gagner en abstraction par rapport au protocole http et aux tracas connexes. Ainsi dans le monde Java, l'introduction des servlets a été rapidement complétée par les JSP pour mieux gérer les sorties HTML. Mais la maintenance et la montée en complexité des applications posaient de nombreux problèmes et il a fallu reprendre les éternelles bonnes pratiques (ou Design Patterns) comme le modèle MVC (Modèle Vue Contrôleur) et les adapter un peu à cette nouvelle problématique (MVC2). Il aurait été dommage de s'arrêter en si bonne voie alors qu'un petit effort supplémentaire était nécessaire pour réutiliser certains éléments de présentation (TagLibs), simplifier la syntaxe des pages JSP (JSP 2.0 Expression Language) et capitaliser sur un nombre toujours croissant de développements (Struts et tant d'autres) auxquels des modèles (templates) de production de pages (Tiles par exemple) n'enlèvent rien. Une conclusion s'impose d'emblée, si vous n'êtes pas passé par toutes ces étapes, certes stimulantes, mais rétrospectivement fastidieuses, vous avez souvent l'impression que le développement J2EE est d'emblée hors de portée. Rassurez-vous, JSF arrive à votre secours.

Dans les technologies citées, l'abstraction vis-à-vis du protocole de transport Web s'est manifestée par des API fournissant des objets correspondant aux requêtes et réponses http, ou permettant de mettre en œuvre un suivi automatique des clients (ou session http). Derrière toutes ces évolutions, on sent bien une logique de rationalisation et d'industrialisation des développements visant à une réduction des coûts de production, mais qui est jusqu'à présent restée en deçà des attentes des directions informatiques. Combien de fois avons-nous déjà entendu que « les développements J2EE c'est trop long et trop cher », « les développements PHP c'est inmaintenable ». Même si une bonne équipe de développement J2EE ou PHP peut faire des merveilles, ces critiques ne sont pas sans fondement et montrent qu'il y a largement la place pour une technologie plus simple à aborder et plus efficace dans sa mise en œuvre.

I-B - ASP.Net et ses WebForms

Pourtant, dans le monde des développements Web où SUN et ses recommandations J2EE dominaient les autres solutions ou éditeurs par son dynamisme et par l'importante communauté open source qu'elle avait réussi à drainer, la dernière évolution majeure est venue du monde Microsoft et des nouveautés de sa technologie ASP.Net, les WebForms.

Face à la complexité du monde J2EE, Microsoft a compris que la solution viendra de la simplicité et qu'un ralliement massif des développeurs à son framework .Net est alors envisageable. Pour cela, quitte à se montrer simpliste, éliminons tous les obstacles et tergiversations du monde J2EE : le choix de l'éditeur (évidemment, c'est propriétaire !) et de l'OS, le choix de l'outil de développement (Visual Studio .Net avec des années de savoir-faire dans la réalisation d'environnements de développements ergonomiques c'est un plus indéniable), le choix du serveur (IIS sinon rien) et du framework Web.

Les points forts d'ASP.Net, un environnement de développement convivial qui masque la complexité du développement Web. Des composants graphiques de haut niveau, faciles à agréger dans des pages se soumettant à elles-mêmes (AutoPostBack) afin de pouvoir réagir à des évènements utilisateurs. C'est-à-dire les composantes ayant fait le succès des applications graphiques Windows appliquées au monde Web. Il suffisait d'y penser… pas si sûr !

Une question nous vient tout de suite à l'esprit, elle concerne la grande facilité de mise en œuvre qui débouche sur un risque accru d'avoir des développeurs inexpérimentés produisant des applications impossibles à faire évoluer ou à faire monter en charge. Certes, ce risque existe et il a manifestement été bien pesé pour offrir à la fois un framework assez flexible pour les experts et suffisamment simple pour les néophytes. Éevidemment, ce « grand écart » est loin d'être parfait, mais il demandait une réponse rapide de la part de SUN.
Comme quoi, à tous ceux qui dénonçaient le framework .Net comme une copie éhontée du JDK, Microsoft prouvait très rapidement qu'il allait falloir compter avec lui. Mais laissons là les pages ASP.net pour nous concentrer sur JSF qui, vous l'aurez compris, va en reprendre les principales caractéristiques.

I-C - Naissance de JSF

Afin de réagir aux ambitions de Microsoft de croquer une plus grosse part du marché du développement Web et de proposer enfin un framework Web standard dans le monde J2EE, une JSR (Java Specification Request) est formée qui donne lieu en 2003 à la première version de Java Server Faces. Depuis, la version actuelle est la 1.1 et nous nous dirigeons vers une version 1.2.

Son arrivée pose très vite de nombreux soucis et particulièrement pour tous ceux qui ont misé sur un framework Web en Java (Struts pour les plus nombreux) et qui craignent pour la pérennité de leurs développements. Ceux-là ont raison de s'inquiéter et, bien que de nombreux articles et quelques bibliothèques d'intégration (comme struts-faces) aient été consacrés aux possibilités d'intégrer Struts et JSF, cela reste fort complexe à réaliser en pratique et bien souvent idiot au vu des recoupements entre les deux frameworks. Il y a donc là un choix stratégique important.

L'arrivée de JSF n'est pas illico synonyme de succès pour deux raisons liées aux différences stratégiques entre le monde J2EE et le monde Microsoft. Le monde J2EE vise avant tout à la production de normes, laissant à la charge des éditeurs le soin de fournir des implémentations à la hauteur des attentes du public. La norme JSF 1.0 fournit avant tout un framework Web et un modèle de programmation permettant de créer des composants réutilisables. L'implémentation de référence (JSF-RI) fournie par SUN contient donc un ensemble très limité de composants graphiques, on est très loin des composants évolués d'ASP.Net qui vise avant tout à fournir une solution prête à l'emploi. Il faut attendre une année avant de voir les communautés et éditeurs fournir des bibliothèques de composants dignes de ce nom.

De la même façon, la sortie de JSF ne coïncide pas non plus avec la livraison d'un environnement de développement simple et intuitif. Il faut, là encore, attendre de longs mois avant de voir des outils commencer à tenir leurs promesses en terme de facilité de mise en œuvre. Aujourd'hui, cependant, tout est là pour faire de JSF une réalité.

II - Anatomie de JSF

Il n'est pas question de vous donner ici une vue exhaustive du fonctionnement de JSF, mais plutôt un aperçu de son fonctionnement interne pour en comprendre les avantages.

II-A - Un modèle MVC2

Comme de nombreux frameworks Web, JSF dispose d'une architecture de type MVC2. Dans notre cas, le contrôleur JSF s'appelle la « Faces Servlet », les objets du modèle sont des objets Java (ou POJO) appelés « managed-beans » ce qui signifie tout simplement que l'on laisse, le cas échéant, à JSF le soin de les instancier et de les initialiser. En ce qui concerne les vues, le fonctionnement de JSF est particulier, puisqu'elles sont créées majoritairement à partir de pages JSP, mais qu'elles sont réellement représentées par un arbre d'objets gérés côté serveur. Au sein de JSF, les classes responsables de la présentation graphique (HTML ou autre) des composants graphiques sont appelées des « renderers ». Enfin, le compagnon indispensable du framework J2EE, le fichier de configuration XML est bien sûr présent et s'appelle généralement « faces-config.xml ».

Figure 1 : Une page JSF

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%-- début de la vue, il s'agit d'un classique formulaire de login --%>
<f:view>

<h:graphicImage value="/images/LogoValtech-Training.png" id="VTLogo"/>

<%-- pas d'action dans le formulaire qui s'autosoumet toujours --%>
<h:form id="logform">
<h:panelGrid columns="3">
<h:panelGroup id="l">
<h:outputText value="Login "/>
<%-- Le champ 'log' est automatiquement lié à un champ du bean 'user' --%>
<h:inputText id="log" required="true" size="10"value="#{user.login}">
<%-- Prsésence et taille du champ sont automatiquement validés --%>
<f:validateLength minimum="3" maximum="10"/>
</h:inputText>
</h:panelGroup>
<h:panelGroup id="p">
<h:outputText value="Password "/>
<h:inputSecret id="pass" required="true" maxlength="8" size="10" value="#{user.pass}">
<f:validateLength minimum="3" maximum="8" />
</h:inputSecret>
</h:panelGroup>
<%-- la méthode 'validate' du bean 'user' va déclencher une règle de navigation en fonction de son traitement --%>
<h:commandButton value="Log Me In" action="#{user.validate}"/>
<h:message for="log" showSummary="true" showDetail="false"/>
<h:message for="pass" showSummary="true" showDetail="false"/>
<h:message for="logform" />
</h:panelGrid>
</h:form>
</f:view>

II-A-1 - Des règles de navigation

Le passage d'une page à une autre se fait par l'utilisation de règles de navigation. En effet, avec JSF les formulaires HTML contenus dans les pages ou les URL des liens renvoient systématiquement vers la vue qui a entraîné leur affichage, c'est l'« AutoPostBack ». De retour sur le serveur, la navigation est liée à des règles permettant de passer d'une page à une autre, en réalité d'une vue à une autre.
Les règles de navigation se définissent dans le fichier de configuration de JSF.

Figure 2 : Une règle de navigation

<faces-config>
<managed-bean>
<managed-bean-name>user</managed-bean-name>
<managed-bean-class>vt.cra.domain.User</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<navigation-rule>
<display-name>Menu</display-name>
<from-view-id>/Login.jsp</from-view-id>
<navigation-case>
<from-outcome>menu</from-outcome>
<to-view-id>/Menu.jsp</to-view-id>
</navigation-case>
</navigation-rule>
<faces-config>

II-A-2 - Des composants réutilisables

JSF a beau permettre la création de composants, graphiques ou non, il est indispensable qu'un certain nombre d'entre eux soient prédéfinis.
Les principaux types de composants sont :

- les composants graphiques : éléments de formulaires, tableaux… ;

- les convertisseurs et les validateurs : pour gérer très simplement les entrées ;

- les « renderers » : pour l'affichage des composants.

La plupart de ces composants s'intègrent dans les pages JSP au moyen de balises spécifiques. Ne perdez pas de vue que les éléments de base sont volontairement simples et qu'ils ne sauraient suffire (comme dans l'exemple de la Figure 1). Nous parlerons plus tard des composants de haut niveau.

II-A-3 - Des évènements

Afin d'affranchir le développeur du traitement des requêtes http entrantes, JSF dispose d'un modèle reposant sur l'autosoumission des formulaires ainsi que la possibilité de réagir à des évènements (le plus souvent grâce à des champs cachés dans les pages HTML générées par JSF). Ces évènements sont en premier lieu les actions des utilisateurs comme les clics sur des boutons ou les changements de valeurs (listes déroulantes, champs de saisie).

Figure 3 : Exemple de ValueChangeEvent

<%-- Zoom sur le champ 'login' avec gestion événementielle --%>
<%-- En cas de modification du champ, la méthode 'lowerCase' du managed-bean 'user' sera exécutée et la page réaffichée --%>
<h:outputText value="Login "/>
<h:inputText id="log" required="true" size="10" value="#{user.login}"
valueChangeListener="#{user.lowerCase}" onchange="this.form.submit();">

<%-- #{user.login} est un value-binding --%>
<%-- #{user.lowerCase} est un method-binding --%>
<f:validateLength minimum="3" maximum="10"/>
</h:inputText>

II-A-4 - Des liens simples avec le modèle

Afin de lier directement les valeurs contenues dans les composants graphiques à des variables Java, JSF dispose d'un langage d'expression (JSF EL). On parle alors de « value-binding ». Cela simplifie drastiquement le développement des vues. De la même façon, ce langage peut-être utilisé pour lier certains composants aux méthodes de gestion des évènements, on parle alors de « method-binding » (comme on peut le voir sur la figure ci-dessus).

II-A-5 - Des classes graphiques

Lorsque les vues deviennent complexes et que la conception de l'application pose problème, il serait souhaitable de disposer d'une classe Java reflétant le contenu de la vue, non pas ses tags JSP, mais les objets Java réellement instanciés côté serveur. On va alors lier un composant JSF à une variable Java typée d'après la hiérarchie de classes de JSF. Les deux figures suivantes illustrent la mise en œuvre et l'intérêt de cette démarche.

Figure 4 : Exemple de liaison avec un composant

<%-- utilisation de l'attribut 'binding' dans Login.jsp --%>
<f:form binding="#{Login.form1}" id="form1">
<h:outputText binding="#{Login.outputText1}" id="outputText1"/>
<h:inputText binding="#{Login.txtLogin}" id="txtLogin"/>

<h:outputText binding="#{Login.outputText2}" id="outputText2"/>
<h:inputText binding="#{Login.txtPass}" id="txtPass"/>

<h:commandButton action="#{Login.button1_action}"
binding="#{Login.button1}" id="button1" value="Envoyer"/>
</f:form>

Figure 5 : Exemple de backing-bean

// Vue partielle de la classe Login, backing-bean de Login.jsp

import javax.faces.component.html.HtmlOutputText;
import javax.faces.component.html.HtmlInputText;
import javax.faces.component.html.HtmlCommandButton;

public class Login {

private Form form1 = new Form();

public Form getForm1() {
return form1;
}

public void setForm1(Form f) {
this.form1 = f;
}

private HtmlInputText txtLogin;

public HtmlInputText getTxtLogin() {
return txtLogin;
}

public void setTxtLogin(HtmlInputText hit) {
this.txtLogin = hit;
}

private HtmlInputText txtPass;

public HtmlInputText getTxtPass() {
return txtPass;
}

public void setTxtPass(HtmlInputText hit) {
this.txtPass = hit;
}

private HtmlCommandButton button1;

public HtmlCommandButton getButton1() {
return button1;
}

public void setButton1(HtmlCommandButton hcb) {
this.button1 = hcb;
}

// Traite l'action résultant du clic du bouton. La valeur renvoyée est le nom d'un cas de navigation et 'null' renverra à la même page.
public String button1_action() {
//Interaction facilitée avec la vue
// Si je veux afficher la même page en supprimant le bouton
button1.setRendered(false);
return null;
}
}

Cette classe ressemble beaucoup à une classe « SWING », elle permet de manipuler directement les composants graphiques, en ajouter ou en enlever sans toucher à la page JSP par exemple. Dans la terminologie JSF, une telle classe s'appelle un backing-bean.

II-B - Un cycle de vie complet

Les points qui viennent d'être abordés constituent la base de JSF. Avec un bon environnement, ils sont assez simples à mettre en œuvre et ne demandent qu'un minimum de connaissance du fonctionnement de JSF, du protocole http ou du langage HTML. Ils rendent possible le développement d'applications Web J2EE à de nombreux développeurs peu expérimentés.

Cependant, JSF est loin d'être un framework simple. Il est avant tout basé sur un cycle de vie comprenant de nombreuses étapes qu'il devient nécessaire de comprendre dès que l'on veut tirer pleinement parti de JSF.
Dans l'ensemble, une requête entrante interceptée par JSF est soit une première demande, soit un « PostBack ».
En cas de première demande, une vue est créée côté serveur à partir des tags JSF contenus dans la page JSP demandée et on passe ensuite en phase d'affichage (« rendering »).
En cas de « Postback », la vue est recréée côté serveur, les valeurs issues de la requête entrante sont appliquées à l'arbre de composants donc converties puis validées. Si tout se passe bien, les variables Java liées à la vue (le modèle) sont mises à jour et on peut alors traiter les évènements débouchant soit sur le réaffichage de la page, soit sur le déclenchement d'une nouvelle règle de navigation, ce qui amène dans les deux cas le passage à la phase d'affichage. Notez qu'en cas de problème, c'est toujours la vue demandée qui est réaffichée.

Figure 6 : Cycle de vie JSF

II-C - Une totale flexibilité

Afin de prouver son utilité, JSF se doit d'être simple, mais aussi flexible pour ceux qui veulent aller plus loin que le développement rapide d'applications Web.
JSF se montre en pratique d'une flexibilité énorme. Il est évidemment possible de créer n'importe quel type de composant graphique pour ses propres besoins, mais aussi de créer ses propres méthodes de validation plus ou moins réutilisables ou encore de créer ses propres classes d'affichage. Le développement d'un composant va beaucoup plus loin que la création d'une simple TagLib, il s'agit en fait d'une balise personnelle couplée à un objet géré côté serveur avec toutes les fonctionnalités que nous sommes prêts à développer et qui, une fois packagé, se réintègre très facilement dans tout projet JSF. Il est cependant vrai que l'on déplore une certaine complexité dans le mode de création des composants graphiques et particulièrement lorsqu'il ne s'agit que de créer un agrégat de composants existants.
Enfin, chaque partie de la mécanique interne de JSF peut être personnalisée, comme le gestionnaire de vues (« ViewHandler ») qui travaille par défaut avec des pages JSP, mais que l'on peut modifier par exemple pour intégrer Tiles dans un développement JSF. Le gestionnaire de navigation, le gestionnaire d'état ou les « resolvers » du langage JSF-EL peuvent très simplement être remplacés par nos propres classes. Il est ainsi facile d'aller chercher les messages d'internationalisation dans une base de données plutôt que dans un fichier de propriétés (fonctionnement par défaut).

III - Développement rapide avec JSF

III-A - Points forts de JSF

JSF permet de réconcilier deux points de vue diamétralement opposés en fournissant un framework Web basé sur une abstraction complète des mécanismes d'Internet tout en garantissant une totale maîtrise du cycle de vie du traitement d'une requête si le besoin s'en fait sentir.
D'un côté, JSF rend le développement Web accessible à tous ceux qui ont des connaissances basiques en Java et qui ont travaillé par le passé avec des outils comme Delphi.
De l'autre côté, il se montre capable d'offrir des possibilités de capitalisation et de réutilisation simplifiées sans commune mesure avec ce qui était proposé jusqu'à maintenant.
Dans tous les cas, le temps nécessaire à la création d'une page, complexe ou non, est très nettement réduit grâce à un minimum de compétences JSF. Si j'ai personnellement trouvé assez rapide la courbe d'apprentissage de JSF, j'ai eu de nombreux retours de développeurs Web expérimentés jugeant sans comparaison le temps de production des pages même après des années passées à utiliser d'autres frameworks du monde J2EE.
Il est important de comprendre qu'une technologie comme JSF peut être assimilée à une technologie « grand public » en terme de développement Web et que de nombreuses PME qui jugeaient le développement J2EE trop coûteux et trop spécialisé pour de petites équipes devraient se pencher sérieusement sur cette solution.
N'oublions pas que les beaux jours du client-serveur sont étroitement liés à l'informatique départementale et à la possibilité de réaliser simplement des applications de faible envergure. Aujourd'hui, c'est le développement intranet qui doit permettre de réaliser simplement des applications de consultation de base de données ou de saisie d'informations peu critiques.
Néanmoins, il reste clair que de telles applications ne sauraient convenir dès lors qu'il faut prendre en considération les contraintes supplémentaires que sont la sécurisation, la montée en charge, la haute disponibilité, l'évolutivité, et qui sont l'apanage des applications commerciales ou critiques.

III-B - Environnements graphiques

Si les premiers environnements permettant le développement d'applications JSF comme WSAD 5.0 ou Sun Studio Creator avaient le mérite d'exister, ils restaient en deçà de ce que l'on pouvait attendre d'un EDI. Aujourd'hui, les principaux éditeurs proposent des ateliers JSF parmi lesquels Oracle avec JDeveloper, SUN avec Studio Creator v2, IBM avec RAD 6, EXADEL avec son ensemble de plug-ins pour Eclipse ou BEA qui a récemment racheté l'éditeur M7 et intégré leur produit NitroX pour faire partie du BEA Workshop Studio.
Avec des EDI disponibles en version gratuite et d'autres atteignant plusieurs centaines d'euros par machine, il est légitime de se demander ce que l'on peut réellement attendre de ces environnements. Voici donc une petite liste des points les plus importants, et donc des tâches les plus répétitives et les moins amusantes du développement JSF :

- un éditeur visuel de navigation permettant de comprendre aisément la structure de l'application tout en automatisant l'écriture des règles de navigation. La figure suivante montre l'utilisation du diagramme Web dans l'environnement d'IBM ;

Figure 7 : Navigation avec RAD6

- un éditeur graphique pour les pages JSP permettant non seulement de glisser des composants graphiques dans la fenêtre de conception, mais permettant aussi de glisser les objets Java du modèle que l'on veut lier aux composants. La figure vous montre un exemple de conception visuelle avec SUN Studio Creator permettant de lier directement le résultat d'une requête de sélection avec une DataTable JSF ;

- la possibilité de personnaliser facilement la palette des composants, que ce soit pour rajouter ses propres composants, comme pour rajouter des bibliothèques supplémentaires. La figure montre la palette de composants d'ExadelStudio (version gratuite) contenant les composants de base, mais aussi d'autres bibliothèques de composants ainsi que des composants développés en interne ;

- la possibilité de générer les classes représentant les vues JSF (ou « backing beans ») même si cela s'avère finalement moins nécessaire que prévu.

Figure 8 : Studio Creator 2, modeleur graphique

Même s'il y a un gouffre entre une démonstration de produit et un développement informatique, il est intéressant de constater que le contenu d'une base de données peut être intégré dans une page Web, sous la forme d'un tableau permettant de gérer le tri ou la pagination des éléments en quelques minutes. Certains éditeurs permettent de réaliser cet exploit sans écrire une seule ligne de code et c'est d'autant plus intéressant que le code généré est très propre puisqu'il repose sur des composants JSF de haut niveau. Le code produit par l'éditeur est donc quasiment le même que celui que vous auriez écrit vous-mêmes.
Avec peu d'expérience et un bon éditeur, il est donc possible de se lancer dans le développement Web grâce à JSF pourvu que l'on dispose de composants graphiques adéquats…

Figure 9 : Exadel Studio 3, palette de composants personnalisée

III-C - Bibliothèques de composants

Passée la première déconvenue causée par le peu de composants fournis de façon standard dans l'implémentation de SUN, de nombreux développeurs se sont mis au travail pour fournir des composants plus ou moins spécifiques.
Ainsi, différents éditeurs comme Business Objects ou ILOG possèdent leur propre bibliothèque de composants spécifiques, mais il convient avant tout développement JSF de trouver une bonne bibliothèque de composants génériques. Il s'agit de ces composants qui servent dans tout développement Web comme le tableau triable, le calendrier avec ou sans JavaScript, l'arbre de visualisation, la boite à onglets…

Figure 10 : MyFaces, calendrier avec ou sans JavaScript

Parmi les éditeurs, c'est Oracle, avec sa librairie ADF Faces, qui a le premier proposé une bibliothèque de composants gratuite et assez générique, mais, comme souvent, c'est une initiative open source qui remporte aujourd'hui les suffrages de la communauté JSF : MyFaces. Liée à la communauté Apache, MyFaces est avant tout une implémentation de la spécification JSF parmi les plus utilisées et il serait assez logique qu'elle devienne l'implémentation de référence des futures versions de JSF. Mais MyFaces ne serait pas aussi intéressant sans sa bibliothèque d'extensions « Tomahawk », disposant d'une trentaine de composants supplémentaires ou étendant les fonctionnalités des composants standard. Signe de cette réussite, un grand nombre de projets open source ont finalement rejoint MyFaces et, tout récemment, Oracle a décidé de leur faire cadeau de sa bibliothèque de composants.
Le dernier obstacle qui pouvait entraver le développement rapide d'applications avec JSF est donc levé.

IV - Conclusion

Si JSF possède des qualités qui en font le framework Web J2EE le plus prometteur, n'allez pas croire que sa mise en œuvre est de tout repos. Si cet article avait pour but de vous montrer en quoi JSF permet d'accélérer la production des vues donc des pages d'une application Web dynamique, il n'en reste pas moins vrai qu'une bonne compréhension des principes sous-jacents reste nécessaire à la création d'une application JSF maintenable, robuste, rapide et capable de monter en charge.

Ceci étant dit, voilà encore quelques lignes pour vous présenter d'autres aspects prometteurs de JSF avec, tout d'abord, le projet Facelets. Afin de simplifier le développement des vues et de disposer de modèles de pages pour rendre possible la mise à jour de la charte graphique d'un site, Facelets reprend les idées qui ont fait la reconnaissance de Tapestry et de Tiles.

La prochaine version de la bibliothèque de composants MyFaces s'oriente vers l'utilisation de composants « AJAXisés » permettant d'utiliser cette technologie très en vogue afin d'alléger JSF de certains allers-retours complets avec le serveur, ce qui se révèle très précieux en pratique, par exemple pour réaliser une liste de suggestions lors d'une saisie. Est-ce un moyen de rapprocher JSF de ces fameuses technologies de client riche dont on entend tellement parler ? La dernière figure ci-dessous vous aidera peut-être à vous faire une idée.

Ce qui est sûr, c'est que rien dans JSF n'impose la production de pages HTML, puisque le principe des « renderers » permet l'indépendance entre le composant et son affichage. Il est donc tout à fait envisageable de prévoir des familles de « renderer » ou « render-kit » fournissant un affichage des composants JSF avec une technologie comme Flash. C'est loin d'être une idée en l'air puisqu'apparaissent actuellement les premières extensions de ce type, notamment avec XulFaces, mais point trop de choses à la fois.

Figure 11 : Composants avancés de la sandbox Tomahawk

V - Remerciements

Cet article a été mis au gabarit de developpez.com : voici le lien vers le PDF d'origine : AR12-JSF-Article.pdf.

L'équipe Java de Developpez.com tient à remercier la société Valtech pour la mise à disposition de cet article aux membres de Developpez.com.

Nous tenons à remercier également Philippe DUVAL pour sa relecture attentive de cet article et Régis Pouiller pour la mise au gabarit.