Chapitre 4 Développer des applications Web avec les frameworks Struts et JSF

1. Chapitre 4Développer des applications Webavec les frameworksStruts et JSF

2. Sommaire • Le modèle MVC2 • Architecture du Framework Struts • Fonctionnement de Struts • Architecture du Framework JSF • Fonctionnement de JSF • Comparaison de Struts et JSF

3. MVC2Le design pattern Modèle-Vue-Contrôleur

4. Modèle Vue Contrôleur • 1980 - Introduit par SmallTalk • Design Pattern reconnu (GoF) • Consiste à séparer les aspects suivants d'une application • Modèle : données/métier • Vue : aspect visuel (présentation) • Contrôleur : gestion de l’interaction • Ce modèle est largement connu en programmation graphique ( MFC Document/View, Motif, Swing/AWT, ...) • MVC est un modèle bien adapté aux applications Web ! MVC Model 2

5. Le Framework Struts

6. Présentation de Struts • Struts est un Projet Open Source développé par la communauté Jakarta d’Apache. Il a débuté en mai 2000 sous la direction de Craig R Mc Clanahan • Struts est un framework dont l’objectif est de faciliter le développement d’applications désirant respecter le modèle MVC2 • Qu’est ce qu’un framework ? • Framework = squelette pouvant servir à une base de construction d’application • Structure logicielle définissant un cadre dans lequel viennent s’insérer les objets et concepts spécifiques à une application

7. Architecture de struts • Struts s’appuie sur MVC2. • Struts repose ainsi sur un contrôleur principal qui aiguille les requêtes reçues du client vers des sous contrôleurs qui à leur tour effectuent le traitement correspondant. • Les 3 composants de Struts : • Le modèle : Struts ne fournit aucune implémentation pour le modèle. Le développeur doit donc définir lui-même le(s) modèle(s). • Les vues : dans Struts, ce sont principalement des pages JSP. Pour cela, Struts fournit plusieurs bibliothèques de ‘taglibs’ permettant de réaliser les pages JSP rapidement. • Le contrôleur : Struts implémente un contrôleur principal (représenté par la classe ActionServlet) et des sous contrôleurs (correspondant aux classes Action).

8. Architecture de struts Source : IBM redbook EJB 2.0 Development with WSAD

9. Architecture de struts • On retrouve sur ce schéma les éléments principaux de Struts, à savoir : • ActionServlet : c’est le contrôleur principal. Cette servlet reçoit les requêtes du client et les renvoi ensuite vers les sous contrôleurs. • Action : il s’agit des sous contrôleurs. Ils effectuent le traitement correspondant à une requête précise. • ActionForm : ce sont des containers pour les pages JSP. Ils peuvent être utilisés par les Action lors du traitement. • Le fichier de configuration ‘Struts-config.xml’ : C’est le composant principal de Struts puisqu’il permet de faire le lien entre tous les composants précédents.

10. Fonctionnement de Struts • Le schéma suivant résume les différentes étapes de traitement d’une requête HTTP : Source : IBM redbook EJB 2.0 Development with WSAD

11. Le contrôleur : ActionServlet • Servlet d’entrée unique (classe ActionServlet) • Lac entralisation des accès à l'application permet un contrôle fin et personnalisé des accès aux traitements (Actions). • L'Action de l'application prend alors le relais et effectue ce que la logique du business lui dicte de faire. • A chaque formulaire est associé un bean ActionForm contenant les setters et getters de chaque champ, ainsi que d’autres méthodes définies par le développeur

12. Le contrôleur : ActionServlet • Le contrôleur ActionServlet doit être déclarée dans le descripteur de déploiement "web.xml" : <web-app> <servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> ... </servlet> <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> ... </web-app>

13. Les sous contrôleurs : les Actions • La classe Action permet de définir un traitement spécifique. Le développeur doit donc étendre de cette classe afin d’implémenter les différents sous contrôleurs de l’application.Chaque Action créée doit être déclarée dans le fichier de configuration XML. En voici un exemple pour une la classe MyAction qui étend de Action : <action path="/actionPerso" input="/index.jsp" name="myForm" type="myPackage.MyAction"> <forward name="error" path="/index.jsp" /> <forward name="success" path="/autre.jsp" /> </action> • Il existe des attributs supplémentaires en relation avec les autres composants de Struts. Ainsi, l’attribut "validate" permet de forcer ou non l’appel à la méthode "validate" de l’ActionForm lié à l’Action.

14. Les containers : les ActionForm • Les ActionForm sont les containers pour les pages JSP, ils fonctionnent comme des beans. Ils permettent de stocker les différentes valeurs saisies dans une page JSP grâce aux accesseurs sur ses différents membres. • Comme pour les Action, le développeur doit étendre cette classe pour créer ses propres containers. • Les ActionForm doivent être déclarés dans le fichier de configuration XML de la manière suivante : <form-beans> <form-bean name="myForm" type="myPackage.MyForm"> <form-property name="membre1" type="java.lang.String" /> <form-property name="membre2" type="java.lang.String" /> </form-bean> </form-beans>

15. Résumé des éléments Clés • Contrôleur principal de Struts . • Reçoit toutes les requêtes du client et les dispatche ensuite vers les Actions • Configuré grâce au fichier de configuration ‘Struts-config.xml’ ActionServlet Actions • Une classe Action permet de définir un traitement spécifique. • Interagit avec la couche métier et manipule les données récupérées • Doit être déclaré dans le fichier de configuration ‘Struts-config.xml’ • Les ActionForms sont des containers pour les pages JSP. • Fonctionnent comme un bean, sont donc conformes au standard Java Bean • Doivent être déclarés dans le fichier de configuration ‘Struts-config.xml’ ActionForms • Permet de faire le lien entre les différents composants de Struts • Permet de décrire les différents éléments: Actions, Forms, Ressources… • Doit être précisé dans le fichier ‘web.xml’ de l’application. Struts-config.xml • Utilisés dans Struts pour l’internationalisation • Comprennent chacun une liste de clés et leur valeur associée • Doivent être déclarés dans le fichier de configuration ‘Struts-config.xml’ Fichiers de ressources

16. Le fichier de configuration XML • Le fichier struts.config.xml est le descripteur de déploiement de toute application Struts, il permet de faire le lien entre les différents composants de Struts dont : • les ActionForm • les Action • les ressources… • Le fichier struts-config.xml doit être déclaré dans le fichier web.xml comme suit : <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> • De plus, comme le fichier "web.xml", "Struts-config.xml" doit obéir à une DTD. Par conséquent la définition des balises et leur ordre d’apparition ont leur importance.

17. Le Framework JSF

18. Introduction • Java Server Faces est un framework développé par Sun pour la création des interfaces utilisateur coté serveur pour les applications web . • JSF est basé sur l’architecture MVC. • JSF est construit sur un modèle de développement orienté événement. • JSF offre un modèle d’architecture extensible en terme de composants. • Pourquoi JSF? • JSF permet d'accroître la productivité des développeurs dans la conception d’interfaces graphiques d’applications Web exécutés coté serveur.JSF est un standardJ2EE 1.4 • Ressemble aux WebForms de la plateforme .Net de Microsoft.

19. Qu’apporte JSF ? • Simplifier le développement d'interface utilisateur Web • Rendre indépendante la logique de présentation et ses rendus (renderers) • Fournir un modèle simple pour la gestion des évènements côté client et côté serveur • Autoriser les créations ou l'enrichissement de composants graphiques utilisateur (custom)

20. Quelle place dans Java/J2EE? • Interagit généralement avec les pages JSP • JSF utilise les bibliothèques de balises JSTL.

21. Architecture Architecture JSF suivant MVC2

22. Architecture de JSF (le MVC 2)

23. Cycle de vie d’une page JSF • La première fois qu'une page dynamique est affichée sur le poste du client, le processeur JSF construit un arbre de contrôles coté serveur (même principe que les WebForms). • Cet arbre est constitué de l'ensemble des composants utilisées par les formulaires HTML (simples ou complexes)

24. Cycle de vie d’une page JSF Reconstruction de l’arbre des contrôles (composant graphiques) Application des valeurs de la requête cliente Validation des données saisies Mise à jour des valeurs du modèle d’objets Invocation d’une application (via une EJB par exemple) Affichage de la réponse

25. Bibliothèques de balises • JSF Tag Libraries - HTML Tag Library - Core Tag Library • JSTL (JSP Standard Tag Libraries) - Core Tag Library - XML Tag Library - SQL Tag Library - Fmt Tag Library

26. Composants et renders de JSF

27. Modèle de composants • Composants de l’interface utilisateur • Modèle des événements • Modèle de validation • Modèle de conversion

28. Modèle de composants • Les JSF UI sont des éléments configurables et réutilisables qui compose les interfaces utilisateurs des applications JSF. Le composant peut être simple comme un bouton ou composé de plusieurs composants comme une table. • La technologie JSF nous offre une architecture de composants riche et flexible, cité ci-dessous: • Les classes UIComponent pour spécifier l’état et le comportement du composants UI • Un Modèle de Rendering permet d’adapter les composants de l’interface graphique à un langage spécifique de markup (HTML, WML). • Un modèle d’évenement ou Listener • Un modèle de conversion qui définit comment enregistrer des données converties dans un composant • Un modèle de validation qui définit comment enregistrer des données de validation dans un composant.

29. Modèle de composants : Composants de l'UI Les classes UIComponent : • La technologie JSF fournit une série de classes de composant d’interface utilisateur et d'interfaces comportementales associées qui spécifient tout le caractère fonctionnel de composant de UI Exp : maintenir une référence aux objets, l'événement de contrôle et rendering pour une série de composants standard. • Les classes de composant sont des composants extensibles et permettant de créer leurs propres composants personnalisés. • Toute les classes de composants de JavaServerFaces héritent la classe UIComponentBase, qui définie l’état et le comportement par défaut de UIcomponent

30. Modèle de composants : Composants de l'UI • La bibliothèque de balises HTML de JSF contient les composants graphiques de base servant à la construction des interfaces utilisateurs. • Exemples de composants: - Command, Form, OutputText. - Graphic, InputText, Panel. - SelectBoolean, SelectMany, SelectOne. Exemple: Nom: <h:inputText id="userNumber" value="#{UserNumberBean.userNumber}"/>

31. Modèle de composants : Composants de l'UI • UIData: Represents a data binding to a collection of data represented by a DataModel instance. • UIForm: Encapsulates a group of controls that submit data to the application. This component is analogous to the form tag in HTML. • UIGraphic: Displays an image. • UIInput: Takes data input from a user. This class is a subclass of UIOutput. • UIMessage: Displays a localized message. • UIMessages: Displays a set of localized messag • UISelectItems: Represents an entire set of items. • …

32. Modèle de composants : Composants de l'UI • Composants standards • Composants Open source

33. Modèle de composants : Composants de l'UI • Composants commerciaux

34. Rendering model • Un renderer est une classe spécialisée dans l'encodage et le décodage de l’arbre des composants dans un langage compréhensible par le client (HTML,WAP…) • Le composant JSF définit le composant en dehors de toute représentation. Cependant, la présence des méthodes d'encodage et de décodage brise cette indépendance. • Un renderer est une classe Java qui hérite la classe javax.faces.Renderer • public class PagerRenderer extends Renderer { • public void encodeBegin (FacesContext facesContext,UIComponent component) throws IOException {….} • public void encodeEnd(FacesContext facesContext,UIComponent component){…} • public void decode (FacesContext facesContext,UIComponent component){…} • }

35. Rendering model • L'intérêt du Renderer est de pouvoir déléguer des responsabilités du composant à une classe spécialisée pour une configuration particulière. • La correspondance entre le type de la classe du renderer est réalisée par faces-config.xml: <render-kit> <renderer> <component-family> facestut</component-family> <renderer-type>facestut.renderer.Pager</renderer-type> <renderer-class>com.facestut.renderer.PagerRenderer</renderer-class> </renderer> </render-kit> La balise render-kit définit un kit de rendu. Un kit de rendu est un ensemble de renderer. Ainsi vous pouvez changer le rendu d'un composant en changeant son renderer. Ici, il suffit de changer la classe com.facestut.renderer.PagerRenderer en un autre nom de classe.

36. Rendering model • La spécification JSF propose un ‘Rendering Model’ pour adapter les composants de l’interface graphique à un langage spécifique de markup (HTML, WML).

37. Modèle d'évènementsde JSF

38. Modèle de composants : modèle d'évènements La spécification JSF propose deux types de Listeners : • actionListener: intercepte un évènement signalé par un composant de type Command (commandButton ou commandLink). • Il survient quand un utilisateur click sur un component qui implémente ActionSource.Ces composants incluent les boutons ou lien Hypertexte Exemple: <h:commandLink id="English" action="login" actionListener="#{testBean.commander}"> </h:commandLink> • ValueChangeListener: intercepte un évènement signalé lors du changement de la valeur d’un composant de type Input • Il survient lorsque l’utilisateur modifie la valeur d’un composant comme UIInput ou une de ses sousClasse Exemple: <h:inputText id="firstName" value="#{customer.firstName}" > <f:valueChangeListener type="testBean.FirstNameChanged" /> </h:inputText>

39. Schéma de navigation • Le schéma de navigation détermine l’enchaînement des pages de l’application, c’est-à-dire à quelle page aller dans un cas déterminé (Navigation Case). • La conception du schéma de navigation est la tâche du développeur de l’application. Elle est définie dans le fichier de configuration de l’application (FacesConfig.xml). • Exemple: <navigation-rule> <from-tree-id>/login.jsp</from-tree-id> <navigation-case><from-outcome>success</from-outcome> <to-tree-id>/menu.jsp</to-tree-id> </navigation-case> <navigation-case><from-outcome>failed</from-outcome> <to-tree-id>/error.jsp</to-tree-id> </navigation-case> </navigation-rule>

40. Modèle de validationde JSF

41. Modèle de composants : modèle de validation • Les Validateurs permettent de valider les données d’un composants de type Input. • Un ou plusieurs Validateurs peuvent être enregistrés pour un seul composant. • Les Validators génèrent un ou plusieurs messages en cas d’erreur. • Exemples de Validateurs: validateLength, validateDoubleRange, validateLongRange, validator. Exemple: <h:inputText value=”testingBean.today”/> <f:validateLength minimum=”6” maximum= ” 10” /> </h:inputText>

42. Modèle de composants : modèle de validation • Les validators concernent les composants qui permettent la saisie de valeurs. • Ces composants implémentent les interfaces ValueHolder et EditableValueHolder. Par exemple, UIInput est le composant ancêtre de tous les composants de saisie. • Principes • La validation se déclenche lors de la phase ProcessValidation. • JSF récupère la valeur soumise par le client et la stocke dans l'attribut submittedValue (interfaceEditableValueHolder). • Cette valeur qui est une chaîne de caractères (HTTP ne connaît que ce type de données) est convertie dans le type adéquat. • Le but d'un validator est de protéger la cohérence du modèle. • La phase UpdateModel n'est atteinte que si la donnée est valide, ce qui évite de positionner le modèle dans un état incohérent.

43. Modèle de conversion Les converters concernent les composants qui publie une valeur. Ces composants implémentent les interfaces ValueHolder. • Par exemple, UIOutput est le composant ancêtre de ce type de composants. • Les converters sont également utilisés lors de la saisie de valeurs. • Principes • La conversion se déclenche lors de la phase ProcessValidation. • JSF récupère la valeur soumise par le client et la stocke dans l'atrribut submittedValue (interface EditableValueHolder). • Cette valeur qui est une chaîne de caractères (HTTP ne connaît que ce type de données) est convertie dans le type adéquat puis stockée dans l'attribut localValue du composant.

44. Modèle de conversion • JSF choisit un converter par défaut lorsque la valeur du modèle est un type primitif (integer, float, .., ). • Pour affiner cette conversion ou pour les types non primitifs il faut spécifier un converter • JSF fournit deux converters standards : • Le premier pour les nombres. • Le deuxième pour les dates. • Pour utiliser ces converters, il faut importer la librairie de tags core. • <html:outputText value="#{accountDatas.total}"> • <core:convertNumber type="currency" • currencyCode="EUR" minFractionDigits="3"/> • </html:outputText>

45. Étapes de développement 1. Développer les objets du modèle (Managed Bean) qui encapsulent les données. 2. Ajouter les déclarations des objets du modèle (Managed Bean) au fichier de configuration Faces-config.xml 3. Créer les pages JSP en utilisant les bibliothèques de balises de JSF. 4. Définir le schéma de navigation dans Faces-config.xml 5. Configurer web.xml

46. Étapes de développement : Développer les objets du modèle • C’est la partie Model du modèle MVC. • Il s’agit d’implémenter des JavaBeans avec les accesseurs. • Ils sont utilisés pour encapsuler les données des IU. • Ils peuvent contenir des méthodes métiers et des gestionnaires d’évènement. • La création et le cycle de vie de ces Beans sont gérés par le JSF Runtime: application, session et request. • Le moteur JSF assure la synchronisation des données entre les Beans et les IU.

47. Étapes de développement : Création de pages JSF • Les pages JSF contiennent essentiellement les balises JSF (HTML et core). • Tous les balises JSF doivent être contenues dans la balise view. <f:view> … JSF Tags … </f:view> • Les pages JSF peuvent contenir des Validators, Convertors et des gestionnaires évènements pour n’importe quel composant.

48. Structure de la page JSF • La définition de taglib JSF standard <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> Un des points forts de JSF est de pouvoir utiliser des composants "graphiques" beaucoup plus riches • On charge un fichier de message afin d'externaliser les chaînes de caractères et rendre l'application I18N via <f:loadBundle basename="messages" var="messages" /> Le fichier messages.properties est présent dans le répertoire properties Plusieur versions du fichier peuvent exister en plusieurs langes: messages_fr.properties version française messages_.properties version italienne …  Internalisation Dans la vue ces messages sont accessibles par des balises du type : <h:outputText value="#{messages.email}" />

49. Étapes de développement : Création de pages JSF (suite) Exemple d’une page JSF: <f:view> <f:form formName=”logonForm”> <h:panelGrid columns=”2”> <h:outpuText value=”Username:”/> <h:inputText id=”username” length=”16” value=”#{loginFormBean.userName}”/> <h:outputText value=”Password:”/> <h:inputSecret id=”password” length=”16” value=”#{loginFromBean.password}”/> <h:commandButton type=”submit” label=”Log On” action=”success”/> <h:commandButton type=”reset” label=”Reset”/> </h:panelGrid> </f:form> </f:view>

50. Étapes de développement : Création de pages JSF (suite) Affectation de l’IU au Managed Beans :