Le Touilleur Express » jsf

Comparaison de l'approche JSF 2.0 et Play! Framework pour du CRUD

Nicolas Martignole — Tue, 27 Jul 2010 07:45:00 +0000

Soyons décontracté pendant l’exercice qui va suivre. Dire du bien ou dire du mal, c’est facile. On peut passer des heures sur des blogs à s’envoyer des commentaires à la figure, ou sinon on peut prendre son temps pour regarder les choses. Moi vous voyez, je suis un gars avec un esprit ouvert. Il y a 3 ou 4 ans je me serai coupé un bras pour vous faire apprendre JSF à la place de Struts. Je me suis ensuite coupé un deuxième bras pour vous parler de Seam et de la gestion de la conversation, par rapport aux soucis des premiers frameworks Webs. Je vous ai bassiné les oreilles avec Grails l’hiver dernier, et en ce moment je ne vous parle que de Play! Framework. Donc dans la logique des choses, je devrai tomber amoureux d’un nouveau framework PouetPouet d’ici quelques semaines. En attendant, et là je me sens à l’aise dans mes baskets, je peux vous parler de ce que j’observe. Quand je dis « JE » cela veut dire que j’ai eu le temps et l’occasion de tester ce que je vois sur de vrais projets.

Il n’y a pas de mauvais frameworks Webs. Selon votre projet je vous encourage à tester différentes approches et à évoluer selon vos besoins fonctionnels. Essayez aussi de prototyper avec un outil comme Balsamiq ou iRise Studio par exemple.

Pensez incrément lorsque vous faîtes du Web. Essayez de construire par petites étapes votre solution, et faites valider par l’utilisateur final les écrans. Le plus important : un logiciel qui marche et une interface qui répond à la demande du client. C’est cela qui doit vous guider pendant votre développement.

And now… JSF 2 and Play! Framework

Si vous souhaitez suivre le code de cet article, je vous encourage à suivre le petit tutorial que j’ai écris sur NetBeans 6.9. Cela vous permettra de générer rapidement une petite application en JSF 2 et Java EE 6 pour la partie Bean. Vous pouvez télécharger le code complet de la partie JSF ici afin de pouvoir suivre simplement la discusssion.

Pour écrire cet article, j’ai écris la partie Play! Framework après la partie JSF 2.0. Je vous guiderai donc sur la partie Play! Framework.

Création d’une application avec Play! Framework
- Télechargez Play! Framework sur le site de Play!
- Décompressez l’archive, ajoutez ensuite le répertoire de play à votre PATH.
- Ouvrez un terminal, dans un répertoire de test, tapez « play » afin de vérifier qu’il est bien installé. J’ai utilisé la version 1.0.3
macbook-pro-de-nicolas-martignole:NetBeansProjects nicolas$ play ~ _ _ ~ _ __ | | __ _ _ _| | ~ | '_ \| |/ _' | || |_| ~ | __/|_|\____|\__ (_) ~ |_| |__/ ~ ~ play! 1.0.3, http://www.playframework.org ~ framework ID is macbookpro ~ ~ Usage: play cmd [app_path] [--options] ~ ~ with, new Create a new application ~ run Run the application in the current shell ~ help Show play help ~

- Tapez ensuite « play new micromarket » afin de créer une application de test

macbook-pro-de-nicolas-martignole:NetBeansProjects nicolas$ play new micromarket ~ _ _ ~ _ __ | | __ _ _ _| | ~ | '_ \| |/ _' | || |_| ~ | __/|_|\____|\__ (_) ~ |_| |__/ ~ ~ play! 1.0.3, http://www.playframework.org ~ framework ID is macbookpro ~ ~ The new application will be created in /Users/nicolas/NetBeansProjects/micromarket ~ What is the application name? micromarket ~ ~ OK, the application is created. ~ Start it with : play run micromarket ~ Have fun! ~ macbook-pro-de-nicolas-martignole:NetBeansProjects nicolas$

- Placez vous dans le répertoire micromarket puis tapez play run et vérifiez que la page de démarrage de Play! se lance sur http://localhost:9000/

Bravo, vous avez créé une application Play.

Entité JPA
Vous pouvez prendre l’entité JPA MicroMarket du projet NetBeans et la placer dans le répertoire de Play!, cela fonctionne. En effet, il utilise JPA et Hibernate, donc pour lui, cela ne change pas grand chose. Voici le code initial de l’entité MicroMarket avant modification :


package org.letouilleur.demo;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.Table;

/**
 *
 * @author nicolas
 */
@Entity
@Table(name = "MICRO_MARKET")
@NamedQueries({
    @NamedQuery(name = "MicroMarket.findAll", query = "SELECT m FROM MicroMarket m"),
    @NamedQuery(name = "MicroMarket.findByZipCode", query = "SELECT m FROM MicroMarket m WHERE m.zipCode = :zipCode"),
    @NamedQuery(name = "MicroMarket.findByRadius", query = "SELECT m FROM MicroMarket m WHERE m.radius = :radius"),
    @NamedQuery(name = "MicroMarket.findByAreaLength", query = "SELECT m FROM MicroMarket m WHERE m.areaLength = :areaLength"),
    @NamedQuery(name = "MicroMarket.findByAreaWidth", query = "SELECT m FROM MicroMarket m WHERE m.areaWidth = :areaWidth")})
public class MicroMarket implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @Column(name = "ZIP_CODE")
    private String zipCode;
    @Column(name = "RADIUS")
    private Double radius;
    @Column(name = "AREA_LENGTH")
    private Double areaLength;
    @Column(name = "AREA_WIDTH")
    private Double areaWidth;

    public MicroMarket() {
    }

    public MicroMarket(String zipCode) {
        this.zipCode = zipCode;
    }

    public String getZipCode() {
        return zipCode;
    }

    public void setZipCode(String zipCode) {
        this.zipCode = zipCode;
    }

    public Double getRadius() {
        return radius;
    }

    public void setRadius(Double radius) {
        this.radius = radius;
    }

    public Double getAreaLength() {
        return areaLength;
    }

    public void setAreaLength(Double areaLength) {
        this.areaLength = areaLength;
    }

    public Double getAreaWidth() {
        return areaWidth;
    }

    public void setAreaWidth(Double areaWidth) {
        this.areaWidth = areaWidth;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (zipCode != null ? zipCode.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof MicroMarket)) {
            return false;
        }
        MicroMarket other = (MicroMarket) object;
        if ((this.zipCode == null && other.zipCode != null) || (this.zipCode != null && !this.zipCode.equals(other.zipCode))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "org.letouilleur.demo.MicroMarket[zipCode=" + zipCode + "]";
    }

}

A cet instant, je vais vous proposer une approche un peu différente. J’insiste lourdement sur le fait que ce n’est pas obligatoire mais intéressant. Play! propose d’utiliser une approche orientée DDD où les objets du domaine ne sont pas anémiques, mais capables d’effectuer des services simples. Pour cela, le pattern que j’utilise est de donner une référence à ce que l’on appelle le « Repository » dans DDD, et de l’injecter dans mon Entité. Grâce à une classe générique, dans laquelle l’EntityManager sera injecté, et dans laquelle je vais déclarer mes méthodes standards type CRUD, toutes mes Entités pourront alors exécuter du code d’accès au Repository.

Ce que nous allons voir n’est pas mieux ou moins bien que l’approche services/par couche que vous connaissez tous. J’ai envie de vous dire de laisser tomber les couches et de grandir pour faire un bon mot.

Play! propose (n’impose pas) d’étendre soit la classe JPASupport, soit la classe Model, afin que l’accès à l’EntityManager soit injecté par le framework. C’est un couplage fort, mais sur la modélisation du domaine ce n’est pas un souci. Je n’ai pas vu de projets avec de l’héritage d’Entité, et j’ai souvent vu que les problèmes de composition ou d’agrégation étaient résolus sans faire appel à de l’héritage de classes.

J’effectue d’abord 3 modifications : le package, un import en plus et l’extends :

// Fichier micromarket/app/models/org/letouilleur/demo/MicroMarket.java
// dans le répertoire de l'appli Play!
// Changement 1
package models.org.letouilleur.demo;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.Table;

// Changement 2
import play.db.jpa.*;

@Entity
@Table(name = "MICRO_MARKET")
@NamedQueries({
    @NamedQuery(name = "MicroMarket.findAll", query = "SELECT m FROM MicroMarket m"),
    @NamedQuery(name = "MicroMarket.findByZipCode", query = "SELECT m FROM MicroMarket m WHERE m.zipCode = :zipCode"),
    @NamedQuery(name = "MicroMarket.findByRadius", query = "SELECT m FROM MicroMarket m WHERE m.radius = :radius"),
    @NamedQuery(name = "MicroMarket.findByAreaLength", query = "SELECT m FROM MicroMarket m WHERE m.areaLength = :areaLength"),
    @NamedQuery(name = "MicroMarket.findByAreaWidth", query = "SELECT m FROM MicroMarket m WHERE m.areaWidth = :areaWidth")})

// Changement 3
public class MicroMarket extends JPASupport implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @Column(name = "ZIP_CODE")
    private String zipCode;
    @Column(name = "RADIUS")
    private Double radius;
    @Column(name = "AREA_LENGTH")
    private Double areaLength;
    @Column(name = "AREA_WIDTH")
    private Double areaWidth;

    public MicroMarket() {
    }

    public MicroMarket(String zipCode) {
        this.zipCode = zipCode;
    }

    public String getZipCode() {
        return zipCode;
    }

    public void setZipCode(String zipCode) {
        this.zipCode = zipCode;
    }

    public Double getRadius() {
        return radius;
    }

    public void setRadius(Double radius) {
        this.radius = radius;
    }

    public Double getAreaLength() {
        return areaLength;
    }

    public void setAreaLength(Double areaLength) {
        this.areaLength = areaLength;
    }

    public Double getAreaWidth() {
        return areaWidth;
    }

    public void setAreaWidth(Double areaWidth) {
        this.areaWidth = areaWidth;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (zipCode != null ? zipCode.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof MicroMarket)) {
            return false;
        }
        MicroMarket other = (MicroMarket) object;
        if ((this.zipCode == null && other.zipCode != null) || (this.zipCode != null && !this.zipCode.equals(other.zipCode))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "org.letouilleur.demo.MicroMarket[zipCode=" + zipCode + "]";
    }

}

Ensuite, éditez le fichier micromarket/conf/application.conf de Play! afin d’activer une base de données. Nous allons utiliser une base en mémoire. Pas besoin de s’embêter avec le schéma, car Play! va créer une table MicroMarket identique à notre spécification, sans même avoir besoin de relancer le serveur.

A cet instant, si vous sauvez et que vous rechargez votre page, Play! compile le code, et vous serez notifié d’éventuelles erreurs. Pour l’instant nous n’avons pas d’entrées dans notre base, ni de page. Il faut continuer.

Allons encore plus loin. Les NamesQuery sont utilisables, mais je vais utiliser des fonctions de Play! afin d’avoir le support de la pagination intégré, sans devoir écrire cette logique dans une autre classe. Cela équivaut au code utilisant PaginationHelper de la classe MicroMarketController. Je n’invente rien. Avec ce que je vous montre nous n’avons pas besoin de déclarer ce système de PaginationHelper comme dans la version JSF, puisque c’est Play! qui vous le donne. Deuxième modification : je passe en public les attributs, puisque les getters/setters ne me servent à rien ici.

L’entité au final est donc encore plus simple :

package models.org.letouilleur.demo;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;

import play.db.jpa.*;
import java.util.*;

@Entity
@Table(name = "MICRO_MARKET")
public class MicroMarket extends JPASupport implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @Column(name = "ZIP_CODE")
    public String zipCode;
    @Column(name = "RADIUS")
    public Double radius;
    @Column(name = "AREA_LENGTH")
    public Double areaLength;
    @Column(name = "AREA_WIDTH")
    public Double areaWidth;

    public MicroMarket() {
    }

    public MicroMarket(String zipCode) {
        this.zipCode = zipCode;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (zipCode != null ? zipCode.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof MicroMarket)) {
            return false;
        }
        MicroMarket other = (MicroMarket) object;
        if ((this.zipCode == null && other.zipCode != null) || (this.zipCode != null && !this.zipCode.equals(other.zipCode))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "org.letouilleur.demo.MicroMarket[zipCode=" + zipCode + "]";
    }

    /** Retourne la liste des MicroMarket en utilisant la méthode find hérité de JPASupport
      * zipCode : critere de recherche
      * page: numéro de la page à charger, si vous affichez un tableau paginé par exemple
      * length: taille de la page, par exemple 10 pour charger 10 entrées
      */
    public List findByZipCode(String zipCode, int page, int length) {
        return  find("from MicroMarket m where m.zipcode like :p").bind("p",zipCode).fetch(page,length);
    }

   //.. autre finder
}

Voilà, comme vous pouvez le constater, ce n’est pas une révolution, simplement une approche différente pour le domaine.

La partie Java EE 6

Pour commencer, je vais regarder comment fonctionne la page qui donne la liste des Entités, avec la pagination. Dans la version JSF, nous avons un ManagedBean, la class MicroMarketController. Celui-ci utilise un EJB Stateless, MicroMarketFacade, qui donne accès à l’EntityManager, un DAO en quelque sorte.

public abstract class AbstractFacade {
    private Class entityClass;

    public AbstractFacade(Class entityClass) {
        this.entityClass = entityClass;
    }

    protected abstract EntityManager getEntityManager();

    public void create(T entity) {
        getEntityManager().persist(entity);
    }

    public void edit(T entity) {
        getEntityManager().merge(entity);
    }

    public void remove(T entity) {
        getEntityManager().remove(getEntityManager().merge(entity));
    }

    public T find(Object id) {
        return getEntityManager().find(entityClass, id);
    }

    public List findAll() {
        javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        return getEntityManager().createQuery(cq).getResultList();
    }

    public List findRange(int[] range) {
        javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        javax.persistence.Query q = getEntityManager().createQuery(cq);
        q.setMaxResults(range[1] - range[0]);
        q.setFirstResult(range[0]);
        return q.getResultList();
    }

    public int count() {
        javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        javax.persistence.criteria.Root rt = cq.from(entityClass);
        cq.select(getEntityManager().getCriteriaBuilder().count(rt));
        javax.persistence.Query q = getEntityManager().createQuery(cq);
        return ((Long) q.getSingleResult()).intValue();
    }

}

Sa spécialisation en classe MicroMarketFacade est super simple et propre :

package org.letouilleur.demo;

import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class MicroMarketFacade extends AbstractFacade {
    @PersistenceContext(unitName = "WebApplication1PU")
    private EntityManager em;

    protected EntityManager getEntityManager() {
        return em;
    }

    public MicroMarketFacade() {
        super(MicroMarket.class);
    }

}

Jusqu’ici, on voit qu’avec 2 classes et Java EE 6 vous pouvez faire l’équivalent de ce que vous avez l’habitude de faire avec Spring par exemple. Je trouve le code simple et efficace.

JSF et la partie ManagedBean

Attention là c’est un poil plus compliqué. La classe MicroMarketController est un ManagedBean JSF, capable de gérer la pagination. Le moins que l’on puisse dire, c’est que ce n’est pas simple.
Pour être plus équitable, j’ai retiré la pagination, et l’on voit alors que le code est simple, pas plus compliqué que la version Play! Framework. La version originale est plus complexe, avec la gestion de la pagination et un Converter pour retenir l’élément sélectionné. S’il y a possibilité de critiquer JSF, c’est sur cette partie, que je vous laisse regarder dans le fichier original.

package org.letouilleur.demo;

import javax.ejb.EJB;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.convert.FacesConverter;
import javax.faces.model.DataModel;
import javax.faces.model.ListDataModel;

@ManagedBean (name="microMarketController")
@SessionScoped
public class MicroMarketController {
    private DataModel items = null;
    @EJB private org.letouilleur.demo.MicroMarketFacade ejbFacade;

    public MicroMarketController() {
    }

    private MicroMarketFacade getFacade() {
        return ejbFacade;
    }

    public String prepareList() {
        recreateModel();
        return "List";
    }

    public DataModel getItems() {
        if (items == null) {
            items = new ListDataModel(getFacade().findAll());
        }
        return items;
    }

    private void recreateModel() {
        items = null;
    }

}

Et si nous écrivions le controleur de la version Play ? Vous êtes prêt ?

Ouvrez la class app/controllers/Application.java et ajouter une nouvelle méthode static list comme ci-dessous:

// CODE PLAY dans app/controllers/Application.java
package controllers;

import play.mvc.*;
import models.org.letouilleur.demo.MicroMarket;
import java.util.List;

public class Application extends Controller {

    public static void index() {
        render();
    }

    public static void list() {
	    List listOfMicroMarkets=MicroMarket.findAll();
        render(listOfMicroMarkets);
    }
}

Voilà, c’est tout.

La vue

Si vous le voulez bien, terminons par la vue. Pour Play c’est assez simple, voir un peu simpliste. Créez une page list.html dans le répertoire views/Application. La page portant le même nom que la méthode du contrôleur, elle sera chargée automatiquement par Play!

#{extends 'main.html' /}
#{set title:'List of MicroMarket' /}
List of MicroMarket

#{list items:listOfMicroMarkets, as:'currentMicroMarket'}
${currentMicroMarket.id} ${currentMicroMarket.zipCode} ${currentMicroMarket.radius} ${currentMicroMarket.areaLength} ${currentMicroMarket.areaWidth} 
#{/list}

Si vous sauvez cette page et que vous testez… petit déception. Il n’y a rien dans notre base de données. Comment tester ? Et bien nous allons créer un Bootstrap (comme avec Grails) afin de charger un fichier YAML. Ce fichier contiendra 3 entrées pour tester.

Créez un fichier BootStrap.java dans le répertoire app de Play:

import play.Play;
import play.jobs.*;
import play.test.*;

import models.*;
import models.org.letouilleur.demo.*;

@OnApplicationStart
public class BootStrap extends Job {

    public void doJob() {
        if (Play.mode == Play.Mode.DEV) {
            Fixtures.load("test-data.yml");
        }
    }

}

Ensuite créez un fichier test-data.yml dans le répertoire conf:

models.org.letouilleur.demo.MicroMarket(m1):
    zipCode: 95051.0
    radius: 255.59
    areaLength: 689.856
    areaWidth: 478.479

models.org.letouilleur.demo.MicroMarket(m2):
    zipCode: 33740.0
    radius: 12.59
    areaLength: 389.52
    areaWidth: 528.41

models.org.letouilleur.demo.MicroMarket(m3):
    zipCode: 89211.0
    radius: 120.3
    areaLength: 39.856
    areaWidth: 452.52

Relancez le serveur, et chargez alors la page pour lister nos entrées (http://localhost:9000/application/list). Hop voilà la liste des entrées de la base. Notez que la page est moche par rapport à la version JSF.

La version JSF est plus complète, mais on va revenir là dessus à la fin:

Et pour terminer, regardons le code la partie JSF, dans le fichier List.xhtml. J’ai retiré la pagination afin d’alléger la page :

Alors pour enfoncer le clou, je propose de piquer la CSS de JSF, de mettre un tableau HTML simple, et de voir ce que cela donne. Play! Framework utilise le langage Groovy comme moteur de template dans la vue. Cela rend plus simple l’écriture des pages, mais ne permet pas de se faire aider lors de la création des pages, comme avec JSF dans NetBeans. Il y a donc un risque d’erreur. La bonne nouvelle, c’est que vous n’avez pas à arrêter Play! pour voir vos modifications. Il suffit de recharger la page dans votre navigateur.

Et le code HTML associé :

#{extends 'main.html' /}
#{set title:'List of MicroMarket' /}

List of MicroMarket
Play! Framework


#{list items:listOfMicroMarkets, as:'currentMicroMarket'}

#{/list}




   ZipCode
   Radius
   AreaLength
   AreaWidth



	${currentMicroMarket.zipCode}
    ${currentMicroMarket.radius}
    ${currentMicroMarket.areaLength}
    ${currentMicroMarket.areaWidth}

ZipCode	Radius	AreaLength	AreaWidth
${currentMicroMarket.zipCode}	${currentMicroMarket.radius}	${currentMicroMarket.areaLength}	${currentMicroMarket.areaWidth}

Analyse des 2 approches

Que pensez-vous de la partie vue de la version JSF ? Objectivement, j’ai l’impression d’écrire en tag JSF du code HTML. Je sais la puissance de JSF et que je peux gagner du temps, mais au prix d’une complexité dont je n’ai pas besoin dès le départ. Côté Play! Framework, les tableaux paginés et triés existent aussi, grâce aux librairies de jQuery. D’ailleurs, le code généré par JSF utilise aussi la librairie jQuery. Au final cela ne change pas grand chose dans le navigateur. Donc je préfère la simplicité de Play! Framework à l’approche complète de JSF, mais il faut reconnaître que JSF sera en mesure de construire des interfaces plus riches que Play!, qui reste très basique.

Côté serveur, la partie Entité et DAO ne change pas beaucoup. La philosophie est différente, mais cela correspond à une manière de coder. Le ManagedBean et son Converter dans la version complète est lui aussi un peu compliqué. Pourquoi avoir un DataModel (regardez le code de la méthode List) alors qu’une List d’entité ferait l’affaire ?

Conclusion

Après avoir vu tout ce code, on voit bien la différence d’approche. Il n’y a pas de vainqueur, il y a deux approches différentes. Côté Model et Controleur, c’est du pareil au même. A part l’approche orientée DDD de Play! nous n’avons pas vu de grosses différences. Côté vue, j’ai le choix entre JSF qui me permet d’écrire plutôt une application type client riche, ou Play! qui me laisse me débrouiller avec ma page HTML.

La conclusion ?

C’est parce que Play! Framework est proche de ce que nous avons déjà l’habitude de faire que je vous recommande de regarder. Il vous faudra quelques heures à peine pour vous en servir, et vous serez surpris. Productivité, plaisir et impression d’avancer.

Références:
Le code du projet Play! zippé et du projet JSF sont disponible ici: http://touilleur-express.fr/divers/jsf/.

Spring Faces+WebFlow+Java classique comparé à Play! Framework

Nicolas Martignole — Thu, 13 May 2010 13:23:31 +0000

Dans cet article, je vous propose de regarder 2 approches différentes pour résoudre un même problème : construire une application web sécurisée, moderne et Ajaxisé. Je vais vous présenter les différences de conceptions sur la partie Java essentiellement. Cet article ne sera pas une introduction à l’une ou l’autre des technologies. Je souhaite vous éclairer sur quelques concepts différents dans Play! par rapport à l’approche classique.

Pour comparer 2 choses, il faut un référentiel comparable. JBoss Seam propose sur cette page plusieurs versions d’une application de réservation de chambres d’hôtels. La version originale basée sur JSF 1.2 n’est plus toute jeune mais fonctionne très bien. J’en avais parlé sur le Touilleur Express il y a 3 ans et demie… Quand je me dis que cela fait plus de 3 ans que j’ai vu cela, et qu’à l’époque je vous avais convaincu de regarder JSF par rapport à Struts, je me dis qu’il faut que je réussisse dans cet article à vous montrer la nouvelle approche, celle de 2010.

Nous allons prendre Spring Faces et Spring Webflow, une approche que je trouve très intéressante et qui permet de réaliser des applications Webs avec les technologies de Spring.

I. Le match : télécharger, installer et lancer la démo

Voyons tout d’abord comment télécharger, compiler et lancer la démonstration avec chacun des environnements. Je souhaite évaluer la rapidité de prise en main. Je souhaite que le projet soit configuré dans IDEA IntelliJ ou Eclipse pour travailler, et je vais évaluer la facilité à monter chacun des environnements. Je regarderai aussi le temps de démarrage des serveurs Webs testés.

I.1) Préparation de l’espace de démo pour Spring

SpringSource propose « Spring Travel« , une version basée sur Spring Faces, Spring WebFlow 2.0.9 et une librairie JSF avancée pour le rendu. J’ai regardé précisément le code « booking-faces » dans le répertoire projects/spring-webflow-samples pour écrire cet article. Si vous souhaitez tester par vous même :
- téléchargez la version Spring WebFlow 2.0.9 sur le site de SpringSource
- décompressez l’archive
- ouvrez le répertoire projects/spring-webflow-samples/booking-faces
- tapez mvn eclipse:eclipse pour créer un nouveau projet
- ou sinon tapez mvn idea:idea pour créer un projet IDEA IntelliJ
- ou enfin, si vous avez IDEA IntelliJ, celui-ci importe sans problème le pom.xml et vous prépare un projet configuré… Pas besoins de plugins.

Faire tourner la démo en local
Pour faire fonctionner la version Spring en local, éditez le pom.xml et ajoutez Jetty dans la balise build/plugins comme ici:

   ...
   
        swf-booking-faces
        
        	...

            
                org.mortbay.jetty
                maven-jetty-plugin
            

        
    
    
        2.5.6.SEC01
        1.2.0.09

Vous pourrez alors lancer la démo avec mvn jetty:run dans le répertoire de la démo de Spring.

I.2) Configuration de la version Play! Framework

Play! Framework se télécharge sur le site de Play!. Voici comment suivre mes explications pour la deuxième partie :
- décompressez le zip dans un répertoire C:\Soft\play par exemple
- ajoutez C:\Soft\play à votre PATH

Pour lancer l’application :
- allez dans le répertoire C:\Soft\play\samples-and-tests\booking
- tapez « play run » et connectez-vous sur http://localhost:9000/

Pour travailler avec Eclipse ou IDEA IntelliJ
- allez dans le répertoire C:\Soft\play\samples-and-tests\booking
- tapez play eclipsify pour créer un projet Eclipse
- OU tapez play idealize pour créer un module IDEA IntelliJ
c’est tout !

I.3) Résultat du match :

Facilité d’installation : match nul
Qualité de la doc sur le site : match nul
Création du projet dans IDEA IntelliJ : match nul
Serveur : la démo Spring n’embarque pas de serveur, il a fallut ajouter Jetty pour tester alors que Play! Framework dispose de son propre serveur
Temps de démarrage : avantage Play! qui démarre très rapidement en 2 secondes.

Vainqueur : Play! Framework d’une courte longueur

II. Le modèle

II.1) Spécification fonctionnelle

L’objectif de l’application est de réaliser un site de réservation d’hôtel. Pour cela, l’utilisateur peut chercher un hôtel, puis ensuite créer une réservation (Booking en Anglais).

L’utilisateur doit s’authentifier avant de pouvoir terminer sa réservation. Une entité User permet donc de gérer la sécurité facilement avec un moteur de persistence.

Nous utiliserons JPA et une base en mémoire pour les 2 versions. L’essentiel est que Play! Framework comme la version Spring, utilisent JPA. Donc les entités sont presque identiques.

II.2) Une entité simple : l’Hotel

Prenons tout d’abord l’entité Hotel qui représente un hôtel. Voici la version de la démo Spring Webflow/JSF :

package org.springframework.webflow.samples.booking;

import java.io.Serializable;
import java.math.BigDecimal;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

/**
 * Version Spring Web Flow. La sérialisation est nécessaire pour JSF.
 */
@Entity
public class Hotel implements Serializable {
    private static final long serialVersionUID = 4011346719502656269L;
    private Long id;
    private String name;
    private String address;
    private String city;
    private String state;
    private String zip;
    private String country;
    private BigDecimal price;

    @Id
    @GeneratedValue
    public Long getId() {
	return id;
    }

    public void setId(Long id) {
	this.id = id;
    }

    public String getName() {
	return name;
    }

    public void setName(String name) {
	this.name = name;
    }

    public String getAddress() {
	return address;
    }

    public void setAddress(String address) {
	this.address = address;
    }

    public String getCity() {
	return city;
    }

    public void setCity(String city) {
	this.city = city;
    }

    public String getZip() {
	return zip;
    }

    public void setZip(String zip) {
	this.zip = zip;
    }

    public String getState() {
	return state;
    }

    public void setState(String state) {
	this.state = state;
    }

    public String getCountry() {
	return country;
    }

    public void setCountry(String country) {
	this.country = country;
    }

    @Column(precision = 6, scale = 2)
    public BigDecimal getPrice() {
	return price;
    }

    public void setPrice(BigDecimal price) {
	this.price = price;
    }

    public Booking createBooking(User user) {
	return new Booking(this, user);
    }

    @Override
    public String toString() {
	return "Hotel(" + name + "," + address + "," + city + "," + zip + ")";
    }
}

Voici la version Play! Framework :

package models;

import play.db.jpa.*;
import play.data.validation.*;
import javax.persistence.*;
import java.math.*;

/**
 * Version Play! Framework
 */
@Entity
public class Hotel extends play.db.jpa.Model {

    @Required
    @MaxSize(50)
    public String name;

    @MaxSize(100)
    public String address;

    @Required
    @MaxSize(40)
    public String city;

    @Required
    @MaxSize(6)
    @MinSize(2)
    public String state;

    @Required
    @MaxSize(6)
    @MinSize(5)
    public String zip;

    @Required
    @MaxSize(40)
    @MinSize(2)
    public String country;

    @Column(precision=6, scale=2)
    public BigDecimal price;

    public String toString() {
        return "Hotel(" + name + "," + address + "," + city + "," + zip + ")";
    }

}

Les différences entre les 2 versions :
- Play! Framework étend la classe « play.db.jpa.Model » qui fournit le support JPA.
- Les attributs sont publics dans la version Play!, ce qui logiquement évite des getters/setters comme dans la version Spring classique. Moi depuis que l’encapsulation n’est plus à la mode en soirée, j’ai arrêté.
- La syntaxe JPA est un peu plus poussée dans la version Play! Nous verrons si cela permet d’améliorer l’expérience utilisateur dans l’interface graphique ou non.

Le bean de Spring n’étend pas une classe de base contrairement à Play!, ce qui permet d’étendre éventuellement Hotel. Mais est-ce que c’est quelque chose que nous faisons pour des Entities ? Je me pose la question. Perso je décourage l’héritage avec JPA. FBI = Fausse bonne idée.

[Update] Avec Play! Framework vous pouvez étendre la classe Model afin de simplifier la gestion JPA de l’entité. Cela fait partie des bonnes pratiques comme expliqué par Nicolas Leroux dans les commentaires. Pour en savoir plus, regardez la doc de la partie JPA de Play!

Play! gère l’identité dans la class Model avec un attribut Id de type Long par défaut. Si vous souhaitez gérer votre propre id, vous ~~devez~~ pouvez par exemple étendre la class JPASupport de Play!, puis simplement définir un attribut @Id comme d’habitude avec JPA. C’est tout à fait possible.

On voit que dans la version Spring, il y a une méthode « createBooking » qui permet de créer au niveau de l’Hotel une réservation.

Il n’y a donc pas de vainqueur dans cette partie pour moi. Les 2 approches se valent je pense. Je préfère la simplicité de Play! Framework qui remet en question quelques habitudes du monde Java, comme l’encapsulation systématique.

Par contre je n’aime pas trop l’approche de placer les annotations JPA sur les getters/setters plutôt que sur les attributs de la classe dans la version Spring. On perd beaucoup en lisibilité.

II.3) Une entité plus compliquée : Booking

Une réservation est l’association d’un User, d’un Hotel, d’une date d’arrivée et de départ et de différents autres attributs. Je vais faire exprès de vous donner la version complète des 2 frameworks, afin de vous montrer les différences flagrantes entre les 2 approches.

La version de la démo Spring WebFlow telle qu’elle est livrée, sans trucages, sans effets spéciaux :

package org.springframework.webflow.samples.booking;

import java.io.Serializable;
import java.math.BigDecimal;
import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;

import javax.persistence.Basic;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
import javax.persistence.Transient;

import org.springframework.binding.message.MessageBuilder;
import org.springframework.binding.message.MessageContext;
import org.springframework.binding.validation.ValidationContext;

/**
 * A Hotel Booking made by a User.
 */
@Entity
public class Booking implements Serializable {

    private static final long serialVersionUID = 1171567558348174963L;

    private Long id;
    private User user;
    private Hotel hotel;
    private Date checkinDate;
    private Date checkoutDate;
    private String creditCard;
    private String creditCardName;
    private int creditCardExpiryMonth;
    private int creditCardExpiryYear;
    private boolean smoking;
    private int beds;
    private Amenity amenities;   // Absent de la version Play!

    public Booking() {
    }

    public Booking(Hotel hotel, User user) {
        this.hotel = hotel;
        this.user = user;
        Calendar calendar = Calendar.getInstance();
        setCheckinDate(calendar.getTime());
        calendar.add(Calendar.DAY_OF_MONTH, 1);
        setCheckoutDate(calendar.getTime());
    }

    @Transient
    public BigDecimal getTotal() {
        return hotel.getPrice().multiply(new BigDecimal(getNights()));
    }

    @Transient
    public int getNights() {
        if (checkinDate == null || checkoutDate == null) {
            return 0;
        } else {
            return (int) (checkoutDate.getTime() - checkinDate.getTime()) / 1000 / 60 / 60 / 24;
        }
    }

    @Id
    @GeneratedValue(strategy = GenerationType.TABLE)
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Basic
    @Temporal(TemporalType.DATE)
    public Date getCheckinDate() {
        return checkinDate;
    }

    public void setCheckinDate(Date datetime) {
        this.checkinDate = datetime;
    }

    @ManyToOne
    public Hotel getHotel() {
        return hotel;
    }

    public void setHotel(Hotel hotel) {
        this.hotel = hotel;
    }

    @ManyToOne
    public User getUser() {
        return user;
    }

    public void setUser(User user) {
        this.user = user;
    }

    @Basic
    @Temporal(TemporalType.DATE)
    public Date getCheckoutDate() {
        return checkoutDate;
    }

    public void setCheckoutDate(Date checkoutDate) {
        this.checkoutDate = checkoutDate;
    }

    public String getCreditCard() {
        return creditCard;
    }

    public void setCreditCard(String creditCard) {
        this.creditCard = creditCard;
    }

    @Transient
    public String getDescription() {
        DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM);
        return hotel == null ? null : hotel.getName() + ", " + df.format(getCheckinDate()) + " to "
                + df.format(getCheckoutDate());
    }

    public boolean isSmoking() {
        return smoking;
    }

    public void setSmoking(boolean smoking) {
        this.smoking = smoking;
    }

    public int getBeds() {
        return beds;
    }

    public void setBeds(int beds) {
        this.beds = beds;
    }

    public String getCreditCardName() {
        return creditCardName;
    }

    public void setCreditCardName(String creditCardName) {
        this.creditCardName = creditCardName;
    }

    public int getCreditCardExpiryMonth() {
        return creditCardExpiryMonth;
    }

    public void setCreditCardExpiryMonth(int creditCardExpiryMonth) {
        this.creditCardExpiryMonth = creditCardExpiryMonth;
    }

    public int getCreditCardExpiryYear() {
        return creditCardExpiryYear;
    }

    public void setCreditCardExpiryYear(int creditCardExpiryYear) {
        this.creditCardExpiryYear = creditCardExpiryYear;
    }

    @Transient
    public Amenity getAmenities() {
        return amenities;
    }

    public void setAmenities(Amenity amenities) {
        this.amenities = amenities;
    }

    public void validateEnterBookingDetails(ValidationContext context) {
        MessageContext messages = context.getMessageContext();
        if (checkinDate.before(today())) {
            messages.addMessage(new MessageBuilder().error().source("checkinDate").code(
                    "booking.checkinDate.beforeToday").build());
        } else if (checkoutDate.before(checkinDate)) {
            messages.addMessage(new MessageBuilder().error().source("checkoutDate").code(
                    "booking.checkoutDate.beforeCheckinDate").build());
        }
    }

    private Date today() {
        Calendar calendar = Calendar.getInstance();
        calendar.add(Calendar.DAY_OF_MONTH, -1);
        return calendar.getTime();
    }

    @Override
    public String toString() {
        return "Booking(" + user + "," + hotel + ")";
    }

}

Voyons la version Play! Framework de l’entité Booking maintenant :

package models;

import play.db.jpa.*;
import play.data.validation.*;
import javax.persistence.*;
import java.util.*;
import java.text.*;
import java.math.*;

@Entity
public class Booking extends Model {

    @Required
    @ManyToOne
    public User user;

    @Required
    @ManyToOne
    public Hotel hotel;

    @Required
    @Temporal(TemporalType.DATE)
    public Date checkinDate;

    @Required
    @Temporal(TemporalType.DATE)
    public Date checkoutDate;

    @Required(message="Credit card number is required")
    @Match(value="^\\d{16}$", message="Credit card number must be numeric and 16 digits long")
    public String creditCard;

    @Required(message="Credit card name is required")
    @MinSize(value=3, message="Credit card name is required")
    @MaxSize(value=70, message="Credit card name is required")
    public String creditCardName;
    public int creditCardExpiryMonth;
    public int creditCardExpiryYear;
    public boolean smoking;
    public int beds;

    public Booking(Hotel hotel, User user) {
        this.hotel = hotel;
        this.user = user;
    }

    public BigDecimal getTotal() {
        return hotel.price.multiply( new BigDecimal( getNights() ) );
    }

    public int getNights() {
        return (int) ( checkoutDate.getTime() - checkinDate.getTime() ) / 1000 / 60 / 60 / 24;
    }

    public String getDescription() {
        DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM);
        return hotel==null ? null : hotel.name +
            ", " + df.format( checkinDate ) +
            " to " + df.format( checkoutDate );
    }

    public String toString() {
        return "Booking(" + user + ","+ hotel + ")";
    }

}

Tout d’abord il manque des choses dans la version Play! Framework, et on ne compare donc plus exactement la même chose. Notez l’absence de l’entité Amenity. Ensuite, la version Spring utilise une approche différente pour l’attribut @Id et spécifie le générateur alors que la version Play! hérite de ce que la super-classe Model propose.

Ce qui me dérange dans la version Spring c’est la présence de la méthode validateEnterBookingDetails. Celle-ci est intéressante fonctionnellement, mais dépose une dépendance vers MessageContext un peu trop forte à mon goût.

Regardez aussi la différence sur la validation du numéro de carte de paiement. La version Play! utilise un moteur simple similaire à Hibernate Validation, mais propriétaire à Play! Au contraire la version Spring ne précise rien, et on imagine donc que la validation des 16 digits se fera dans la vue… et pas dans le modèle.

Conclusion : j’ai de plus en plus de mal avec la sauce des getters/setters, surtout lorsque les entités dépasse les « HelloWorld » et que l’on commence à sortir des cas d’usages compliqués. Souvenez-vous de ce que je vous disais : pour résoudre des problèmes compliqués il faut des solutions simples…

III. Le contrôleur

Après avoir regardé 2 entités différentes pour le modèle, voyons maintenant la différence d’approche entre Spring WebFlow et Play! Framework. Je vais étudier le cas de l’affichage de la liste des Hôtels, lorsque l’utilisateur clique sur le bouton Search par exemple.

III.1) Spring WebFlow

L’approche de Spring WebFlow est la suivante : afin d’éviter d’écrire un controller classique, Spring propose de définir les chemins logiques de navigation en XML, et d’associer directement des méthodes sur des services pour récupérer la partie Model. Cette approche a l’avantage de simplifier le développement de workflow webs complexes. Je vais vous présenter le concept.

Pour commencer, nous définissions un flow en XML pour l’action qui affiche la liste des Hotel correspondant à un critère de recherche. Je ne vous montre que la view-state « reviewHotels » afin de ne se concentrer que sur l’exemple :

« main-flow.xml »




	

	
		// Effacé pour simplifier l'exemple...

Le point fort de Spring WebFlow/JSF ici : il sera possible de ne redessiner qu’une partie de l’interface. En effet, vous avez noté le tag ? Grâce à ce système très pratique avec Spring WebFlow et JSF, si vous avez une partie cliente en Ajax il devient alors possible de ne redéfinir qu’une partie de l’interface.

Dans la démo Play! Booking, ce mécanisme est implémenté « à la main » dans la page index.html. Tout est fait avec du jQuery et le tag jsAction de Play!, qui appelle des actions du controller Play. Celui-ci retourne alors des fragments de HTML, ce qui fait que la version Play! est aussi ajaxisé. Je reconnais que c’est moins évident et facile, mais les 2 se discutent.

Il y a donc un BookingService avec une méthode findHotels pour rechercher la liste des hôtels, d’après le Flow XML. Il s’agit d’une interface, ce qui permet de changer l’implémentation. Dans notre cas nous n’aurons que la version JPA. Si vous avez une forte envie de faire une version PasJPA notez que c’est super utile…

public interface BookingService {
   // j'ai effacé les autres méthodes ici pour ne garder que l'essentiel

    public List findHotels(SearchCriteria criteria);

}

Le service implémente l’interface, j’ai supprimé une bonne partie du code afin de ne vous laissez que ce qui nous intéresse. Mais croyez-moi, la version complète est assez verbeuse. Ce qui nous intéresse ici c’est uniquement la méthode findHotels

@Service("bookingService")
@Repository
public class JpaBookingService implements BookingService {

    private EntityManager em;

    @PersistenceContext
    public void setEntityManager(EntityManager em) {
        this.em = em;
    }

   // Note : j'ai effacé du code ici pour ne garder que quelques méthodes

    @Transactional(readOnly = true)
    @SuppressWarnings("unchecked")
    public List findHotels(SearchCriteria criteria) {
        String pattern = getSearchPattern(criteria);
        return em.createQuery(
                "select h from Hotel h where lower(h.name) like " + pattern + " or lower(h.city) like " + pattern
                        + " or lower(h.zip) like " + pattern + " or lower(h.address) like " + pattern + " order by h."
                        + criteria.getSortBy()).setMaxResults(criteria.getPageSize()).setFirstResult(
                criteria.getPage() * criteria.getPageSize()).getResultList();
    }

   // Note 2 : j'ai effacé du code ici pour ne garder que quelques méthodes

   // helpers
   private String getSearchPattern(SearchCriteria criteria) {
        if (StringUtils.hasText(criteria.getSearchString())) {
            return "'%" + criteria.getSearchString().toLowerCase().replace('*', '%') + "%'";
        } else {
            return "'%'";
        }
    }

}

Le plus intéressant est donc la méthode findHotels. Elle permet d’effectuer la recherche, de retourner une List d’Hotel à la vue, que nous verrons tout à l’heure si vous êtes toujours motivé.

III.2) Le contrôleur version Play! Framework

L’approche de Play! est un peu plus simple mais demande un peu plus de code Java.
Je précise tout de suite : j’ai modifié l’exemple afin de retirer la partie Authentification et pour ne me concentrer que sur le Use-Case de récupérer la liste des Hotel correspondant à un critère entré dans l’interface utilisateur.

public class Hotels extends Controller {

    public static void list(String search, Integer size, Integer page) {
        List hotels = null;
        page = page != null ? page : 1;
        if(search.trim().length() == 0) {
            hotels = Hotel.all().fetch(page, size);
        } else {
            search = search.toLowerCase();
            hotels = Hotel.find("lower(name) like ? OR lower(city) like ?", "%"+search+"%", "%"+search+"%").fetch(page, size);
        }
        render(hotels, search, size, page);
    }
   ...
    // Note : code effacé pour ne conserver que la méthode list
   ...
}

L’approche de Play! Framework est donc la suivante :
- écrire une classe dans le répertoire « controllers » qui étend la class Controller de Play!
- écrire une méthode public static avec en argument les paramètres de la vue. Play! se charge de vous récupérer ce que l’utilisateur a entré. Notez ensuite l’appel pour récupérer la liste des Hotels :

            search = search.toLowerCase();
            hotels = Hotel.find("lower(name) like ? OR lower(city) like ?", "%"+search+"%", "%"+search+"%").fetch(page, size);

La méthode find est une méthode statique définie dans la classe JPASupport. Elle permet d’exécuter des requêtes JPA. Vous pouvez aussi écrire une méthode dans l’entité Hotel pour éviter de placer ici du code technique par exemple. Les 2 approches se valent.

III.3) Différence d’approche

La version Spring WebFlow demande plus de XML, ce qui personnellement me dérange. Je trouve que la définition des flows n’est pas simple. C’est même une fausse bonne idée. Je préfère une approche fortement typée en Java, où par contre pour que la magie opère, je dois étendre des classes spécialisées de Play! Framework.

Côté test, il est assez simple de tester Spring WebFlow, mais je n’ai pas testé personnellement.

Je vais être méchant avec Spring WebFlow : je trouve cela bien compliqué pour résoudre un problème simple. Ici quel est l’apport du XML ? Des annotations ? Est-ce que notre vie est plus simple grâce à ce système ? Permettez-moi d’en douter.

C’est peut-être une révolution par rapport à l’approche Struts, mais tant qu’à faire la révolution, il ne faut pas s’arrêter à un concept basé sur un fichier XML pour définir la navigation d’une application Web.

III. 4) Synthèse

Avantages de Spring Web Flow

- possibilité de déclarer en quelques lignes un bout de code pour que la vue récupère le Model sans devoir définir un controller.
- gestion de la navigation de l’utilisateur fine dans le site
- se repose sur des Services facile à tester pour s’assurer que le Model est correct
- bien meilleur que l’approche classique où les DAO dans les Services ne servent à rien
- Spring MVC récupère les paramètres de la vue et les dénormalise, ce qui est très pratique.
- bonne intégration de la sécurité

Inconvénients de Spring Web Flow

- clairement plus compliqué que Play! sur ce point
- XML tu aimes ou tu n’aimes pas, mais c’est ton environnement de développement Web
- gestion pas facile pour les débutants entre les view-states, les action-states, les transitions etc.
- l’EntityManager à la main dans le service : pas top. Mais c’est quelque chose qui est souvent factorisé dans des classes de GenericService par exemple, avec un DAO… Bref encore 3 ou 4 classes Java en plus.

Avantages de Play! Framework :

- le controlleur déclare des méthodes static et public qui deviennent autant d’URL dans la vue
- le framework se charge de récupérer et dénormaliser les paramètres de la vue
- approche full java
- les entités ont un moteur comme GORM en Grails mais plus simple. Cela permet d’avoir des finders comme méthode statique sur l’entité Hotel. C’est cependant statique et plus limité que Grails/GORM.

Inconvénients de Play! Framework :

- le controller de base étend une class de Play! (si la spécialisation vous dérange plutôt que la composition)
- la gestion des workflows compliqué demande un effort de développement par rapport à Spring WebFlow, qui sera capable de retomber sur ses pieds.

IV. La Vue

Je vais maintenant évaluer plusieurs critères :
- la création d’une page pour chacune des technos
- la qualité de l’expérience utilisateur avec l’utilisation d’Ajax
- la taille des pages webs et les temps de chargement

IV.1) Créer une page avec Spring Faces

Basé sur JSF, cette partie sera donc essentiellement une discussion sur JSF plutôt que sur Spring. Je parlerai un peu de la taglibs de Spring pour la partie validation du côté client, que je trouve très bien fait. Mais l’essentiel du débat porte plus sur JSF ici.

Dans le projet Spring Webflow, les pages sont construites à partir d’un template, avec la technologie Facelets. Très pratique, cela vous permet de construire le canevas de votre site, puis de spécialiser vos vues en écrivant peu de code.

Le template standard.xhtml :





	
	Spring Faces: Hotel Booking Sample Application

	
	
		
		
		
		
		
	
	
	



	
		
			Spring Travel: A Spring Faces Reference Application
			
				
	            	Welcome, ${currentUser.name} | Logout
				
				
	            	Login

La page « reviewHotels.xhtml » avec 52 balises HTML+JSF permet d’afficher la liste des Hôtels :







	
		Hotel Results
		
			
		
		
			
				
				
					
						
							
								
							
						
						#{h.name}
					
					
						Address
						#{h.address}
					
					
						
							
								
							
						
						#{h.city}, #{h.state}, #{h.country}
					
					
						Zip
						#{h.zip}
					
					
						Action

Ce que j’apprécie à titre personnel avec JSF :
- possibilité d’écrire du code de mise en forme sans avoir besoin de faire trop de CSS
- moteur de construction de page assez proche d’une vue client lourd
- possibilité d’écrire avec la syntaxe JSF et d’avoir un rendu riche sans se prendre la tête avec du Javascript ou des feuilles de style.
De toutes les façons, je suis pas développeur Web. Donc mort aux CSS…

Ce qui me fait un peu tiquer, c’est que l’on dit au développeur Java : tu n’auras pas besoin d’apprendre à faire une mise en page compliquée en HTML et CSS…

Mais bon, vous vous foutez pas un peu de nous là ?

La page demande 52 balises. Et ce dataTable pourrait très bien être un simple TABLE en HTML avec une CSS non ? Ce qui d’ailleurs est le cas au final non ?

IV.2) Créer une page avec Play! Framework

Attention cela pique les yeux. Comme JSF ou Wicket, vous pouvez utiliser un éditeur HTML pour construire votre page. En effet, le format des pages de Play! Framework est très original puisque c’est du HTML ni plus, ni moins. Il y a cependant l’utilisation de Groovy qui risque de faire peur à quelques uns. Je note cela comme un inconvénient par rapport à JSF.

La version livrée avec Play! utilise jQuery et Ajax à fond. Il y a en fait une page principale, puis un ensemble de fonction Javascript pour ne charger rapidement que ce qui change dans un DIV au format HTML. C’est radicalement différent, et peut-être moins facile d’abord pour des gens n’ayant jamais fait de Web. Je vous montre donc plutôt ici ma version « gars qui a fait du Java et du Web et qui découvre Play »

Play! Framework dispose aussi d’un moteur de template. Je vais donc vous montrer 2 fichiers. Le fichier main.html est un template de base que j’utilise pour le site :




    
        #{get 'title' /}
        
        
        #{get 'moreStyles' /}
        
        
        
        #{get 'moreScripts' /}
    
    

        
            play framework booking demo
            #{if user?.id}
                
                    Connected as ${user.username}
                    |
                    Search
                    |
                    Settings
                    |
                    Logout
                
            #{/if}
        

        
            #{if flash.error}
                
                    ${flash.error}
                
            #{/if}
            #{if flash.success}
                
                    ${flash.success}
                
            #{/if}

            #{doLayout /}

        

        
            Created with play framework and really inspirated from the booking sample application provided by seam framework

Voici la page qui affiche la liste des Hotels. Le fichier s’appelle « list.html » comme le nom de la méthode list du Controller Hotels que nous avons vu plus haut. Il est bien entendu possible de déclarer un nom différent et de configurer une autre route avec Play! Framework.

Le fichier est assez simple : il reçoit un objet List, il itère en Groovy avec un tag spécifique à Play et il affiche le résultat dans un tableau HTML :

#{extends 'main.html' /}
#{set title:'Search result'/}

#{if hotels}

    #{list hotels, as:'hotel'}
    
    #{/list}
    
    
    
        Name
        Address
        City, State
        Zip
        Action
    
    
    
        ${hotel.name}
        ${hotel.address}
        ${hotel.city}, ${hotel.state}, ${hotel.country}
        ${hotel.zip}
        
            View Hotel
        
    


    More results

#{/if}

#{else}

    No more results

#{/else}

Name	Address	City, State	Zip	Action
${hotel.name}	${hotel.address}	${hotel.city}, ${hotel.state}, ${hotel.country}	${hotel.zip}	View Hotel

La version Play! est très dépouillée. L’inconvénient : il sera nécessaire dans les 2 cas (JSF comme Play!) d’apprendre la technologie de rendu et les tags pour travailler efficacement. Mais Play! n’est pas orienté composant comme JSF. Il n’y a pas d’utilisation de l’Expression Language, ici c’est Groovy. Ce moteur Groovy est un poil plus lent que Japid, un autre moteur Java qui est disponible pour Play!

Regardez aussi la liste des modules de Play! Framework. Il y a du lourd comme le support de Scala, le moteur NoSQL MongoDB, Guice, GWT ou le module Search avec Lucene (comme Hibernate Search en plus simple).

Un inconvénient de Play! pour les personnes qui n’ont jamais fait de Web : la mise en page et la partie CSS. Lorsque je monte un projet avec Play! Framework, j’utilise par exemple CSS 960 grid system. Je connais ces systèmes car j’ai un gros background Web. Pour le CSS, pour sélectionner des couleurs qui ne font pas vomir l’utilisateur, j’ai pleins d’outils comme Kuler d’Adobe pour préparer des styles… Donc pour moi qui suit très Web : je peux faire un truc joli avec Play! Framework. Je pourrai styliser mes tableaux sans soucis. Je pense que ce qui est bien avec JSF, c’est que cela vous aide à monter vos pages facilement, à construire vos formulaires ou vos tableaux sans devoir devenir une bête en HTML/CSS. Mais c’est un peu dommage, lorsque l’on voit le potentiel d’HTML 5 pour les années qui viennent.

IV.3) Expérience utilisateur

J’ai lancé les 2 applications et j’ai effectué une comparaison en tant qu’utilisateur. Je donne l’avantage à la version Spring Faces. Je trouve que la librairie de Spring de validation du côté client est très sympa.

En terme de rapidité, la version Play! Framework est vraiment plus réactive. Si je clique comme un dingue avec un script Selenium, la version Spring WebFlow est à la peine alors que la version Play! se tourne les pouces sans s’essoufler.

IV.5) Taille des pages Webs

La page d’affichage de la liste des Hôtels sur Spring WebFlow (cliquez sur l’image pour l’afficher en grand) :

La version Play! Framework :

Mes tests avec YSlow en effectuant 10 chargements de la page puis en prenant la moyenne :

Moyenne des temps de chargement de la page liste des Hotels pour 10 hotels:
- Play! Framework en mode Dev ou Prod : 0,234 secondes
- Spring WebFlow avec Jetty : 1.286 secondes
- Spring WebFlow avec Tomcat 6.0.20 : 1.092 secondes

Le mode Prod de Play! ne prend qu’un peu plus de temps à démarrer, mais je n’ai pas constaté de différence une fois le serveur lancé.

Volume de la partie HTML sans CSS/Images et temps de chargement :
Si je ne regarde que la partie HTML sans prendre en compte le temps de chargement des images, je teste réellement que la partie serveur.

Play! Framework : chargement de 3.1 kb en un temps moyen de 14ms
Tomcat+Spring : chargement de 14kb en un temps moyen de 52 ms

Donc pour un affichage similaire, vous voyez le souci ? la version Spring Faces de cette démonstration est 5 fois plus lourde et demande 4 à 5 fois plus de temps. Je ne dis pas qu’en général c’est le cas, mais pour notre exemple oui c’est le cas. Et nous sommes sur le même cahier des charges : afficher dans un tableau une liste d’Hôtel.

V. Conclusion

Si vous avez pris le temps de lire cet énorme article jusqu’au bout, merci. Revenez voir le code des deux version en détail. Téléchargez chacune des versions et donnez vos propres arguments techniques en faveur de l’un ou de l’autre.

J’ai envie de taper du poing sur la table : il est temps de revoir le développement Web en Java.
Le développement Web demande des compétences. Si vous ne les avez pas, ne prenez pas une techno pour couvrir vos lacunes. Apprenez à faire du Web. Désolé, le XML ne m’excite pas. Play! est plus facile à apprendre que toute la stack Spring que je vous ai présenté. Car elle est plus simple et tout aussi puissante.

Pour construire une application Web compliquée ou d’entreprise, est-ce que dans 5 ans nous ferrons toujours du JSF ? ou est-ce que nous ferrons du HTML+CSS+jQuery ? Je pose la question. Evidemment, Play! Framework doit encore faire ses preuves et on peut me retourner l’argument. Mais c’est plus simple, plus réaliste et plus facile à maintenir.

Le point faible de Play! par rapport à un framework comme Spring Faces+Spring WebFlow+JSF c’est qu’il faut plus d’efforts pour construire ses composants dans la partie vue. D’un autre côté, lorsque vous avez un framework aussi puissant que JSF, vous avez envie de prendre des tableaux avancés, des richTables, ou des composants plus puissants. Cela entraîne parfois le risque de prendre des composants qui font trop par rapport à un tableau simple. D’ailleurs, si vous ne preniez pas ces composants, quel intérêt à utiliser une librairie JSF ? Je pose la question.

Un risque est donc d’utiliser des composants riches trop facilement dans une application Web avec JSF. Vous vous retrouvez avec un tableau avec des colonnes triables, alors que vous n’en n’avez pas besoin. Et votre page pèse 15-20kb au lieu de peser 2-5kb, et demande de la mémoire et du CPU du côté serveur.

Le site « eXpress-Board » tourne sur la même machine que le blog « Le Touilleur Express » avec 3 parts chez Gandi, soit 768Mo. Le process Java tourne avec 128 Mo de mémoire, et prend entre 5 et 16% de l’utilisation de la machine, bien loin de MySQL qui est très sollicité par WordPress pour le Blog.

Je vais me faire taper par les maîtres Javas qui ne vont pas être d’accord. Mais c’est la première fois où j’en ai rien à faire, car je suis sûr de mes arguments.

Allez SuperTroll, sort du bois, je t’attends.

On va bien s’amuser…

A propos d'ICEFaces 1.6, JBoss Seam et mon projet de dans deux ans

Nicolas Martignole — Thu, 12 Jul 2007 07:27:18 +0000

Je suis sur un nouveau projet personnel. Basé sur JBoss Seam, j’ai besoin de librairies JSF assez puissante pour gagner du temps. Ce matin j’ai vu qu’ICEsoft Technologies, Inc a annoncé la sortie officielle de la librairie JSF ICEFaces en version 1.6. Cette nouvelle version s’intégre avec JBoss Seam 1.2.1 GA. Des tutoriaux permettent d’apprendre à coder des pages rapidement. Le mieux cependant est peut-être de regarder la page de démonstration pour vous faire une idée.

Par rapport à d’autres librairies comme tomahawk qui a du mal à s’intégrer avec Seam, ICEFaces a été testé et validé avec JBoss Seam. Pour ma part je cherche un composant jsf d’agenda qui tienne la route. J’aimerai bien tester MyFaces Schedule mais pour mettre en place tomahawk dans JBoss il faut désactiver l’implémentation jsf par défaut. Je n’ai pas encore testé, car je regarde une autre alternative utilisant Google Agenda. L’idée est de récuperer l’agenda via du HTML, ce que j’ai réussi à faire hier soir sans trop d’effort. Google met aussi à disposition une API Java pour poster des évenements vers un agenda Google. Bref j’ai tout, sauf qu’au niveau de l’ergonomie l’agenda qui s’affiche en mode HTML est moins sympa à utiliser que la vraie version de Google Agenda… Donc me voilà revenu au point de départ.

Sinon JBoss Seam est vraiment puissant… mais chut, tant pis pour ceux qui se réveilleront trop tard…

Ajax4jsf 1.0.2 fonctionne avec JBoss Seam

Nicolas Martignole — Thu, 12 Oct 2006 07:04:33 +0000

Bonne nouvelle, Ajax4jsf fonctionne sans aucuns problèmes avec JBoss Seam. Ajax4jsf est une api open source qui offre à JSF (Java Server Faces) des possibilités AJAX sans devoir écrire une ligne de Javascript. Ajax4jsf utilise cependant toutes les fonctionalités de l’architecture JSF (validation, conversion, gestion du cycle de vie) tout en facilitant la mise en place de composants dynamiques.

Le site Ajax4jsf: https://ajax4jsf.dev.java.net/nonav/ajax/ajax-jsf/

Comment AJAX-iser ses composants JSF

Nicolas Martignole — Sun, 18 Jun 2006 13:05:10 +0000

Ajax Anywhere est une librairie open source qui permet de transformer des composants JSF existant en composant compatible AJAX. Ainsi au lieu de rafraichir l’ensemble d’une page lorsque l’utilisateur soumet un formulaire, vous pouvez délimiter des zones dans votre page et enchainer un rafraichissement uniquement de cette zone. L’avantage d’AJAX Anywhere contrairement à d’autres JSF existant, c’est que cette API n’est pas orientée composant mais plutôt « zone ». D’autre part il est possible d’ajouter ou retirer AJAX anywhere facilement car les composants JSF eux-même ne sont pas impactés. Vous pouvez donc ajouter une couche « AJAX » sur votre application JSF existante, et ce, très facilement

Mise en oeuvre:

Téléchargez l’api ici
Placer le fichier aa.js à la racine de votre répertoire web, les fichiers .class dans le répertoire WEB-INF/lib, le fichier ajaxanywhere.tld dans le répertoire META-INF\tlds.

Configurez un nouveau filter:


      
        AjaxAnywhere
        org.ajaxanywhere.AAFilter
    

    
        AjaxAnywhere
        *.jsp
    
    
        AjaxAnywhere
        *.do 
    
    
        AjaxAnywhere
        *.htm

Il faut maintenant brancher AjaxAnywhere sur vos composants JSF dans une page JSP. Vous pouvez voir ici une démo avec les composants MyFaces et l’intérêt de ne pas recharger toute la page. Pour ajouter AjaxAnywhere à une page JSP existante il faut:

Importer la librairie de tag
Appeler la methode AAUtil.addZones sur l’élement JSF à ajaxiser
Importer les librairies JS et définir la FORM qui contient le composant
Changer la target action de la balise FORM pour appeler du code JS d’AjaxAnywhere
Pre et post fixer votre composant avec le tag JSF

Si vous avez déjà une application avec JSF et que vous désirez tester le principe d’AJAX rapidement, alors AjaxAnywhere est pour vous

JBoss Seam 1.0 GA est disponible depuis le 13 juin

Nicolas Martignole — Thu, 15 Jun 2006 08:10:44 +0000

A peine une semaine après le séminaire JBoss, la version 1.0 GA de JBoss Seam est disponible. En fait les archives étaient disponibles dès samedi 11 juin. Suite à cela nous avons vu cette semaine une pluie d’article sur les sites anglophones. Parmis ceux-ci, je vous conseille la lecture d’une interview de Gavin King le créateur d’Hibernate et de JBoss Seam sur InfoQ complète et intéressante. En deux pages il présente les idées phares de JBoss Seam qui en font un Framework de 3ème génération.

Pour ma part, depuis la semaine passée j’ai avancé sur ma maquette. J’ai intégré les tags JSF de l’api Jenia.org pour permettre d’avoir accès facilement dans JBoss Seam à JFreeChart. J’en aurai besoin pour la partie charting de notre application financière. Promis dès que j’ai un peu de temps je poste ici les modifications effectuées dans la build pour tester tout cela. Il a fallut notamment changer le build.xml pour pouvoir packager des JAR à la racine de l’EAR et changer le Manifest.mf pour le jar packagé dans le WAR… mais bon c’est du charabia et je prendrai le temps d’expliquer les modifications pour intégrer ces différents tags.

Pour tester JBoss Seam Remoting, en fait il ne m’a fallut qu’une petite heure pour reprendre « helloWorld » et créer un tag inputSearch à la AJAX. C’est vraiment simple. Seam = Simplicité.

La prochaine étape sera de voir comment appeler un web service à partir de la partie Seam. Il y a des specifications en cours dans EJB3 mais pour l’instant je n’en sais pas trop… A suivre donc

Migrer de JSF 1.2 vers JBoss Seam

Nicolas Martignole — Sun, 11 Jun 2006 08:15:24 +0000

Sur cet article vous trouverez des explications claires et complètes pour intégrer JBoss Seam sur une application utilisant JSF 1.2. L’article comporte une deuxieme partie ici. Seam permet de remplacer les backed-bean de JSF par des ejb3 rapidement et facilement.

J’ai commencé hier une maquette en reprenant une application financière qui utilise notre propre framework pour évaluer le coût, la complexité et l’intérêt de passer à Seam. A suivre…

Sinon la Suisse joue contre la France mardi soir… clin d’oeil à Luc et Thomas de Jboss inc.

Installation de JBoss Seam

Nicolas Martignole — Sat, 10 Jun 2006 09:14:54 +0000

Pour tester JBoss Seam 1.0.0.RC3 vous devez installer JBoss AS 4.0.4 GA. Sur la page http://labs.jboss.com/portal/jbossas/download
sélectionnez l’installation via l’installeur en cliquant sur Run Installer. Ne téléchargez pas l’archive (via le bouton Download). En effet les EJB3 n’étant pas encore certifiés JEE5, l’ejb3 deployer n’est pas livré par défaut.

Une fois le téléchargement terminé, et après avoir accepté la licence, pensez à choisir l’installation de type EJB3 lorsque le programme d’installation démarre. Il vous faudra aussi Java 5 si vous ne l’avez pas déjà. A noter que si vous téléchargez jboss-4.0.4.GA-installer.jar, vous pouvez ensuite patcher votre installation de JBoss 4.0.4 de la manière suivante pour y ajouter le support des EJB3:

java -jar jboss-4.0.4.GA-installer.jar -installGroup ejb3 installpath=C:\\Software\\jboss-4.0.4-ejb3

C’est tout pour aujourd’hui.

Struts ou JSF ? ou les deux ?

Nicolas Martignole — Fri, 17 Jun 2005 18:11:13 +0000

Entre Struts et JSF mon coeur balance… En fait pas du tout. Après avoir mis le nez dans le code, je pense que les 2 ne sont pas antagonistes. Il est d’ailleurs possible d’intégrer Struts et JSF au sein d’une même application. Cependant ces 2 Frameworks se recoupent et il n’est pas évident de choisir l’un ou l’autre lorsque l’on commence à développer une application Web J2EE. Avant de vous donner mon avis, j’ai traduit et adapté un article de Roland Barcia dispo en anglais ici

Quelles sont les différences entre JSF et Struts ?

Tout d’abord JSF est jeune. Par rapport à Struts, la première version de JSF est sortie en main 2004. Struts au contraire est maintenant un framework mature. En cours de dévelopement, il est plus facile de trouver de l’aide pour Struts que pour JSF.

Au niveau du design, je pense que JSF est plus puissant que Struts, surtout pour la partie View.
Struts se base sur un FrontController et le pattern Command. JSF est basé sur le pattern Page Controller. Pour Struts, une servlet recupere la requête HTTP et transforme en ActionForm les paramètres avant de déléguer le tout à une Action class. Cela permet de coder simplement et rapidement des actions. L’inconvénient est qu’une seule Action est executée par appel. Le Model et les Actions (Controller) sont parfois mélangés.

JSF est basé sur le pattern Page Controller. Chaque requête passe par une seule servlet comme Struts à la différence que cette servlet recupère une Page complète avec ses composants (Input type, label, table…) et ensuite va déclencher des évenements pour chacun d’eux. En plus du contexte de la page il existe donc un contexte de vue (FacesContext). La partie rendu est ensuite déléguée à une couche de présentation qui se charge de rendre du HTML, du WAP ou autre. Les objets de votre modèle peuvent être cablé avec des componsants JSF (label, text, table) directement dans la page JSP en utilisant la syntaxe JSF EL (Expression Language). Lorsque l’utilisateur modifie et retourne la page vers le serveur, JSF peut mettre à jour le modèle de données automatiquement. C’est le principe du Backed Beans. JSF d’un point de vue évenement peut gérer le changement d’état de plusieurs composants sur une seule page et donc, par la gestion d’event inspirée de Swing, effectuer plusieurs tâches par requêtes. Côté Struts on ne gère qu’um seul évenement par requête. Enfin les ActionForms doivent étendre les class de Struts, ce qui force votre model à dépendre de Struts alors que JSF gére des POJO (Plain Old Java Object) ou Bean sans aucunes dépendances. La partie modèle de votre application avec JSF n’a aucunes dépendances sur JSF. D’ailleurs dans notre application de monitoring, nous nous contentons d’envoyer des simples POJO pour décrire une machine, une application et un processus.

Côté navigation les deux frameworks sont similaires. Cependant JSF ajoute en plus la possibilité de déclarer sur un élément de la page le nom de la vue suivante à afficher et à déléguer la partie « action » à une méthode.
Pour la mise en page et l’intégration, JSF permet d’écrire ses propres composants. MyFaces propose des composants vraiment puissant comme Tree2 que nous utilisons dans notre application.

Est-ce que JSF est mieux que Struts ? Il est bien trop tôt pour y répondre. Tout d’abord historiquement, Craig McClanahan l’un des auteurs de Struts a participé aux spécifications de JSF. Il est donc clair que l’un n’est pas le concurent de l’autre. Lisez ce post de Craig où il donne son point de vue sur JSF et Struts. Sa conclusion est que JSF est plus puissant que Struts sur la partie View, et que Struts dans le future devra se concentrer sur la partie Model-Controller. Il y a d’ailleurs une librairie Struts-Faces qui permet de faciliter l’intégration de JSF sur une appli utilisant Struts.

Le problème: Struts est un framework 100% MVC, alors que JSF est un framework basé sur la page que voit l’utilisateur. Avec Struts vous devez coder l’action doLogin et la câbler pour qu’elle soit déclencher lorsque l’utilisateur effectue une action précise.

Avec JSF vous pouvez:

- déclarer que doLogin est appelé si l’utilisateur clique sur le bouton Submit
- appeler la fonction doLogin parce que le champ Login et le champ Password ont été rempli
- valider que le champ « Login » n’est pas vide et fait au moins 8 caractères grâce à un Validator
- afficher en anglais, en japonais ou autre les labels « Login: » et « Password: »
- ne pas afficher par exemple le bouton Submit si l’utilisateur est déjà authentifié
- etc…

La différence est assez énorme: Struts est basé sur des Actions définies, JSF est basé sur un GUI représenté dans un navigateur sur lequel l’utilisateur a la possibilité de tout faire. Vous voyez pourquoi JSF gére plusieurs événement à la fois ? JSF est donc adapté lorsque ce que vous représentez à l’utilisateur est un GUI complexe composé de plusieurs actionneurs. Sinon pour la petite histoire, JSF est fortement inspiré des WebForms du framework Microsoft ASP.NET.

Voici donc les liens que j’ai le plus visité sur mon Bookmark JSF avec Firefox:

JSF Tutorial très complet, avec des tutoriaux.
JSF QuickStart est un tutorial qui explique les grands principes de JSF.
MyFaces est une implémentation open-source de JavaServer(tm) Faces
La page de SUN sur JSF donne accès à des articles, des FAQ et la possibilité de télécharger l’implémentation de référence.
JavaServerFaces sur Java.Net est le site de la communauté open-source Java.Net sur JSF. C’est ici que l’on peut suivre le boulot des développeurs de l’implémentation de référence.