Gagner en productivité avec Java Server Faces

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.

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.

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é.

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 ».

<%@ 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▲

<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▲

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

<%-- 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▲

II-A-5. Des classes graphiques▲

<%-- 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>

// 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;
    }
}

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.

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).

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.

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 ;

• 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.

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…

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…

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é.