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

Chapitre 4

Développer des applications

Web avec les frameworks Struts et JSF

Les Frameworks Struts et JSF

2M.Romdhani, INSAT, Mars 2009

Sommaire

Le modèle MVC2

Architecture du Framework Struts

Fonctionnement de Struts

Architecture du Framework JSF

Fonctionnement de JSF

Comparaison de Struts et JSF



MVC2

Le design pattern Modèle-Vue-Contrôleur



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

MVC Model 2

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 !



Le Framework Struts



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



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 :

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

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

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



Source : IBM redbookEJB 2.0 Development with WSAD





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.



Le schéma suivant résume les différentes étapes de traitement d’une requête HTTP :

Source : IBM redbookEJB 2.0 Development with WSAD

Fonctionnement de Struts



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



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>

Le contrôleur : ActionServlet



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.



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>



Résumé des éléments Clés

ActionServlet 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’

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’

ActionForms 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’

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



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.

Le fichier de configuration XML



Le Framework JSF



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 standard J2EE 1.4

Ressemble aux WebForms de la plateforme .Net de Microsoft.

Introduction



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)



Quelle place dans Java/J2EE?

Interagit généralement avec les pages JSP

JSF utilise les bibliothèques de balises JSTL.



Architecture

Architecture JSF suivant MVC2



Architecture de JSF (le MVC 2)



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)



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

Cycle de vie d’une page JSF



JSF Tag Libraries

- HTML L Tag Library

- Core Tag Library

JSTL (JSP Standard Tag Libraries)

- Core Tag Library

- XML Tag Library

- SQL Tag Library

- Fmt Tag Library

Bibliothèques de balises



Composants et renders de JSF



Composants de l’interface utilisateur

Modèle des événements

Modèle de validation

Modèle de conversion

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.

Modèle de composants



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

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




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.

…





Composants standards

Composants Open source




Composants commerciaux



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){…}

}

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.

Rendering model



Tag Rendrerd as (en HTML)

<h:commandButton value= "Bouton" />

<h:commandLink value= "lien" /> lien

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

Rendering model



Modèle d'évènementsde JSF



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>

Modèle de composants : modèle d'évènements



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>

Schéma de navigation



Modèle de validationde JSF



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>

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

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.

Modèle de composants : modèle de validation



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.





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>



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

Étapes de développement



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.

Étapes de développement : Développer les objets du modèle



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.

Étapes de développement : Création de pages JSF



<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>

o La définition de taglib JSF standard

o On charge un fichier de message afin d'externaliser les chaînes de caractères et rendre l'application I18N via

Un des points forts de JSF est de pouvoir utiliser des composants "graphiques" beaucoup plus riches

<f:loadBundle basename="messages" var="messages" />

Le fichier messages.properties est présent dans le répertoire propertiesPlusieur 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}" />

Structure de la page JSF



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>

Étapes de développement : Création de pages JSF (suite)



Affectation de l’IU au Managed Beans :

Étapes de développement : Création de pages JSF (suite)



Faces-config.xml :

<navigation-rule>


<navigation-case>

<from-outcome>success</from-outcome>

<to-tree-id>/menu.jsp</to-tree-id>

</navigation-case>

</navigation-rule>

<navigation-rule>


<navigation-case>

<from-outcome>failure</from-outcome>

<to-tree-id>/error.jsp</to-tree-id>

</navigation-case>

</navigation-rule>

Étapes de développement : définir le schéma de navigation



web.xml :

<context-param>

<param-name> javax.faces.application.CONFIG_FILES</param-name>

<param-value>/WEB-INF/faces-config.xml </param-value>

</context-param>

<servlet>

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

<servlet-class> javax.faces.webapp.FacesServlet</servlet-class>

<load-on-startup> 1 </load-on-startup>

</servlet>



<servlet-mapping>

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

<url-pattern>/faces/*</url-pattern>

</servlet-mapping>

Étapes de développement : Configurer web.xml



Archive web

Configurer le fichier web.xml

configuration des extensions du framework

déclarer la servlet JSF

Structure du fichier de configuration JSF faces-config.xml

Configurer les backing beans (managed bean)

– déclarer un bean

– associer des backing-beans

Configurer la navigation

– le navigation handler

– configuration avancée (les outcomes, effectuer une redirection, règles de navigation pour un groupe de pages, commenter une règle de navigation)

Résumé de la configuration JSF



Développer un composant JSF



Principe: Un composant JSF consiste en trois éléments dont un est optionnel:

1. la classe du tag : définit une classe qui va faire le lien entre la page JSP et le composant.

2. la classe du composant : implémente le composant aux travers ses attributs et méthodes.

3. la classe du renderer : optionnelle, cette classe est spécialisée dans le rendu du composant(HTML,XML,XUL, ...)

JSF établit des conventions de nommage pour ces classes: La classe du tag aura pour nom <nomducomposant> Tag, La classe du composant UI<nomducomposant> La classe du renderer <nomducomposant>Renderer.




Notre composant hérite de UIComponentBase. Cette classe est la classe de base pour créer un composant JSF. Notez que UIComponent Base a des classes filles qui modélise des types de composants plus spécifiques : UIPanel, UICommand, ...

public class UIPager extends UIComponentBase {

public void encodeBegin (FacesContext facesContext) throws IOException {ResponseWriter responseWriter = facesContext.getResponseWriter();// Encode le contrôle page précédenteresponseWriter.startElement("a", this);responseWriter.writeAttribute("href","#","href");responseWriter.write("<<");responseWriter.endElement("a");

}public void encodeChildren(FacesContext facesContext) throws IOException {…}}public void encodeEnd(FacesContext facesContext) throws IOException {….}public boolean getRendersChildren(){

return true;}




Nous devons indiquer à JSF qu'un nouveau composant est disponible. Le fichier de configuration faces-config.xml va nous permettre cela:

<faces-config>...<managed-bean>…..</managed-bean>...<navigation-rule><from-view-id>/index.jsp</from-view-id>….</navigation-rule>

<component><component-type>insat.component.Pager</component-type><component-class>com.insat.component.UIPager</component-class></component>

</faces-config>




Un tag JSF permet de créer un composant particulier via une page JSP. Pour cela nous devons créer une classe PagerTag:

Cette classe étends UIComponentTag qui est la classe ancêtre de tout tag JSF. Un tag JSF n'a d'autre but que de créer une instance de composant.

public class PagerTag extends UIComponentTag {

public String getRendererType(){return null;

}public String getComponentType(){

return "insat.component.Pager";}

}




Nous devons maintenant créer le fichier /Web Pages/META-INF/insat.tld afin de déclarer notre tag :

<taglib version="2.0" xmlns="http://java.sun.com/xml/ns/j2ee"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-jsptaglibrary_2_0.xsd">……..<tag><name>pager</name><tag-class>com.insat.tag.PagerTag</tag-class><body-content>empty</body-content></tag></taglib>




Notre composant et notre tag sont désormais connus grâce aux fichiers de configuration. Nous devons maintenant les utiliser dans la page de liste

<%@ page contentType="text/html" %><%@ taglib uri="http://java.sun.com/jsf/html" prefix="html" %><%@ taglib uri="http://java.sun.com/jsf/core" prefix="core" %><%@ taglib uri="/META-INF/facestut.tld" prefix="ft" %><core:view><html:form><html:dataTable id="customers" binding="#{bankCtrl.view.dataTable}"value="#{bankCtrl.model.datas.customers}"var="customer" border="1"><core:facet name="header"><ft:pager/></core:facet><html:column><html:selectBooleanCheckbox binding="#{bankCtrl.view.checkbox}"/></html:column>……</html:form></core:view>




Comparaison de Struts et JSF



..JSF Struts

Possède un modèle de composants assez riche

Ne possède pas un modèle de composants.

Possède un modèle d’évènement pour gérer les évènements des composants de l’interface utilisateur.

Ne possède pas un modèle d’évènement pour les composants de l’IU.

Gère les états des composants de l’IU. Ne gère pas les état des composants de l’IU.

Possède un support pour des multiples renderers.

Ne possède pas un support pour des multiples renderers.

Basé sur des bibliothèques de balises standards JSTL.

N’est pas standardisé malgré sa popularité.

JSF versus Struts

Documents

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