Le Touilleur Express » web

Comment tester son site sur les différentes versions d’Internet Explorer

Nicolas Martignole — Thu, 03 Nov 2011 08:06:08 +0000

Je ne sais pas pour vous, mais moi Windows j’ai dit bye-bye en 2008 pour prendre un Mac. Alors on peut dire ce que l’on veut d’Apple, râler très fort en disant que c’est cher, mais il y a un truc qui échappe encore au monde de Windows : ça marche.

En même temps on a un vrai métier « dans la vraie vie » comme disent les gens. Or dans ma vraie vie de développeur indépendant, je code des sites Internet avec Play! Framework pour des clients. Et les sites de mes clients doivent fonctionner sur le navigateur de Microsoft, à savoir Microsoft Internet Explorer. La question aujourd’hui, cher public, c’est comment tester facilement que le fruit de votre travail fonctionne sur IE7, IE8 et IE9 ? Et bien voici la réponse : Virtual Box et des VMs, un script intelligent et quelques heures de patience.

Je commence par la fin, pour montrer à la salle qu’il n’y a aucuns trucages :

Le site Artstechnica montre dans cet article que pour la première fois, Internet Explorer est passé sous la barre des 50% des navigateurs utilisés dans le monde, en octobre 2011. Bref si IE6 est presque mort, il faut bien voir qu’IE8 est actuellement le navigateur le plus utilisé dans le monde.

Alors voyons comment configurer des machines virtuelles rapidement avec IE7, IE8 et IE9. Pour IE7 nous allons utiliser Windows Vista. Et pour IE8/IE9 nous prendrons Windows 7 Ultimate Edition. Ce qui suit fonctionne pour Mac OS X et pour Linux.

Virtual Box
Commencez par installer Virtualbox, une machine virtuelle gratuite et géniale, développée par SUN Microsystems et qui appartient maintenant à Oracle. Sur Mac OS X avec un processeur Intel, ceci vous permet d’avoir un Windows fonctionnel et qui tourne parfaitement.

Les machines virtuelles Microsoft
Microsoft propose des machines virtuelles pour les développeurs Webs, afin de tester leurs sites webs facilement sur les différents navigateurs depuis août dernier. Ces images sont même patchées avec les dernières corrections de sécurité. Cependant vous ne pourrez pas activer l’image virtuelle. Ce ne sera donc pas une installation de Windows sur laquelle vous pourrez installer d’autres logiciels. Tous les 30 jours il faudra revenir à l’image de départ, mais je vais vous expliquer cela plus loin.

In order to help web designers and web developers test their websites in older versions of Internet Explorer, we’ve provided the following VHD with Windows set up with the specified version of Internet Explorer. The images are patched with the latest security updates and are otherwise clean installs of the operating system with very few modifications.

This download page contains different VPC images, depending on what you want to test. These images are specifically designed to run on Microsoft Virtual PC, and may or may not work in other hosting environments.

Due to the size of the Windows 7 and Windows Vista VHDs, it is split across several files, you’ll need to download all files for that version of the Internet Explorer and uncompress them to the same directory to unpack the VHD file.

The password to login to all of these images is Password1 and the username will be present when you first login.

*Note: You may be required to activate the OS as the product key has been deactivated. This is the expected behavior. The VHDs will not pass genuine validation. Immediately after you start the Windows 7 or Windows Vista images they will request to be activated. You can cancel the request and it will login to the desktop. You can activate up to two “rearms” (type slmgr –rearm at the command prompt) which will extend the trial for another 30 days each time OR simply shutdown the VPC image and discard the changes you’ve made from undo disks to reset the image back to its initial state. By doing either of these methods, you can technically have a base image which never expires although you will never be able to permanently save any changes on these images for longer than 90 days.

Le nom d’utilisateur sera Admin et le mot de passe par défaut est Password1.

Je veux un script
Je ne sais pas pour vous, mais moi je ne me vois pas télécharger chacune des VMs et ensuite configurer pas à pas les installations. En cherchant un peu sur Github, j’ai trouvé un script développé par Greg Thornton qui marche super bien sur Mac OS X Lion. Allez voir https://github.com/xdissent/ievms.

Pour lancer le téléchargement et l’installation des VMs, pour peu que Virtual Box soit déjà installé, comptez 3 à 4 heures avec la commande suivante :

curl -s https://raw.github.com/xdissent/ievms/master/ievms.sh | bash

Voilà, vous aurez ensuite 3 VMs sur VirtualBox configurées avec IE7, IE8 et IE9.

Oui mais le numéro de série ?
Pas besoin de numéro de série. Il suffit de ne pas activer la version de Windows, et de reprendre à chaque fois l’image de base sans sauvegarder sur VirtualBox. Une autre possibilité plus compliquée est expliquée sur le site de Microsoft.

Au final, cela vous donne un moyen simple et rapide de tester avec IE7, IE8 et IE9 votre site Internet.

D’autres manières de tester

Via Twitter (@nmartignole) j’ai eu d’autres suggestions d’outils et de liens intéressants. Voici ce que j’ai reçu :

- http://www.browserstack.com est une solution dans le cloud qui permet aussi de tester un site en local sur votre machine, via une Applet Java. Vous pouvez tester le service gratuitement 60mn, sinon c’est payant. Outil proposé par @alanzirek.

- SauceOnDemand permet de tester un site via des VMs hostées dans le Cloud. Intéressant, il est possible de faire tourner des tests Selenium afin de vous notifier lorsqu’une des versions pour un navigateur donné est cassée. Merci @fcamblor du BordeauxJUG pour l’info.

[Update]
Après plusieurs essais, la solution la plus pratique est Browserstack. Cet outil vous permet de tester via votre navigateur puis des machines virtuelles, l’ensemble des navigateurs du marché. A découvrir d’urgence.

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…

Java et les frameworks Webs : une longue histoire compliquée

Nicolas Martignole — Sat, 01 May 2010 21:45:38 +0000

Crédit photo michael.heiss Licence Commons Creatives 2.0

Imaginons que vous êtes votre framework Web Java favori… Disons que vous habitez dans une maison, qui représente votre framework Web Java.

Fermez les yeux… visualisez une petite usine qui fume avec 345 tuyaux, plusieurs portes d’entrées, des grillages à certains endroits, une pelouse fatiguée, un panneau « Attention, Chien Dangereux (et Con)« , des panneaux solaires qui ne sont pas raccordés, un autocollant « Java 7 Rulez » et des empilements de briques… Il y a souvent des coupures, des problèmes d’allocations de ressources, des débordements de pile. Lorsque vous voulez fermer les volets, vous devez relancer le groupe électrogène. Pour ajouter une chambre supplémentaire, vous avez fait poser une extension sur le toit…

Un jour, un gars vient sonner chez vous. Vous ouvrez la porte et il vous dit : « Bonjour, moi je m’appelle PHP, j’ai l’air moins sérieux que toi, mais je fais tourner de gros sites Webs« . Et toi, tu le regardes comme un hippie Baba-Cool bien gentil, mais au final tu lui lances un « t’es incapable de monter en charge« .
Vlam, tu refermes la porte.

Le lendemain, un autre gars vient te voir et te tape sur l’épaule : « Bonjour, moi c’est Ruby on Rails. Je t’éclate en productivité et en plus mes développeurs s’amusent« . Là tu lui ris très fort au nez et tu lui dis : « Ouais mais Ruby c’est pas comme le Latin ? Une langue morte ?« . Vlam, et tu lâches le chien pour voir s’il a vraiment des soucis de montée en charge.

Le surlendemain, un mec qui semble avoir fumé un arbre sonne à ta porte. Il porte un teeshirt « NE TIREZ PAS : JE TOURNE SUR LA JVM ».
C’est Mr Grails.
Fier comme un pape : « Salut, moi c’est Grails. Je suis enfin là pour t’apporter de la productivité, je suis en Groovy et je tourne sur la JVM… Gentil… pas tirer…« . Et toi de répondre : « Grails c’est pas si performant en production, il faut apprendre Groovy, et en plus tu portes un teeshirt moche« . Le gars a juste le temps de reculer lorsque tu refermes la porte.

Quelques jours plus tard, un gars en costard-cravate, look banal, sonne à ta porte… « Salut, moi c’est JSF2. Je suis un standard, j’ai plusieurs implémentations possibles, je suis là pour tuer Struts2. Comme je suis un standard, je suis bon pour toi et pour ton CV. Par contre pour avoir des composants intéressants il faudra que tu prennes RichFaces/IceFaces ou autre. Et pour ce qui est du REST, on prendra mon pote JAX-RS… et pour la mise en prod on prendra le serveur Trucmuche de 80mo… et blablablabla…« .
Bon là c’est facile, le bonhomme se taille en 4 tout seul. Refermons la porte poliment et retournons à TéléFoot.

Licence Commons Creatives, crédit photo Kenichi Nobusue

Quelques idées sérieuses
Le développement Web fait-il partie du génome des développeurs Java ?
Autant PHP me semble fortement lié à une culture Web, autant Java n’est pas forcément associé au Web. Lors des présentations de Play! Framework, Nicolas Leroux et Guillaume Bort demandaient à la salle du Paris JUG :
Qui est développeur Web ?
Quelques mains timides se lèvent sur les quelques 450 personnes présentes. Guillaume demande ensuite qui a déjà fait des JSPs ou des Servlets. Et là, presque tout le monde lève sa main… Donc si nous comprenons bien ce qui se passe, vous n’êtes pas développeur Web, mais pourtant vous faîtes des JSPs, des Servlets et du Struts…
Ce qui est dommage si nous continuons sur cette idée, c’est que du coup, vous n’avez pas forcément de connaissances en HTML, en CSS, en JavaScript. Si je vous dis que le protocole HTTP est sans état, cela vous semble-t-il alors normal de voir des frameworks massivement avec état, comme le principe même de JSF par exemple ?

Le Web est un vaste espace documentaire. Chaque ressource doit disposer d’une adresse unique, d’une URI. Les répertoires virtuels d’un site doivent être autant de conteneur, pour classer et ranger vos objets, par catégorie. Le protocole Web dispose depuis 15 ans des verbes d’action pour manipuler les documents : GET,POST,DELETE et PUT essentiellement. Saviez-vous que JSF 1.x ne faisait que des POSTs pour échanger des données avec le serveur ? Qui imagine avoir des URLs bookmarkable avec ce type de framework ?

Chaque URL affichée par votre navigateur représente finalement une vue. Les premiers frameworks du monde Java, Struts 1.x pour n’en citer qu’un, ont été construit par dessus l’API des Servlets. Intéressant, lorsque l’on pense qu’une Servlet ajoute la notion de session du côté du serveur, concept qui va rendre la vie des développeurs Javas un peu plus compliqué que prévu. Tout d’un coup, un navigateur qui n’est pas connecté au serveur Web en permanence, demande au serveur de maintenir une session. Le concept magique de session, qui permet d’acheter des oiseaux dans un magasin, devient la référence pour les développeurs Webs. Cette démonstration a eu l’effet d’un lampadaire sur les moustiques : tout le monde a plongé dans le monde formidable de la session. J’y reviens plus loin dans quelques lignes.

Le jour où Gavin King a annoncé Seam, il explique entre autre avec fierté que son framework gère le bouton « Back » du navigateur… Chose qui me semble normal, et que nous savions gérer en 1997 avec du Perl, et un peu d’huile de coude.

La session dans les frameworks Webs Java est un objet assez mal compris. L’implémentation de certains frameworks Webs, que j’appelle « avec session » comme Tapestry, Struts ou Wicket, utilisent un Cookie pour identifier la session du navigateur avec une session en mémoire sur le serveur. Ce ticket permet de stocker sur le serveur des objets volumineux. Je vois alors le framework Web comme une sorte de Mont de Piété. Vous déposez vos valeurs, on vous donne un ticket. Lorsque vous revenez, vous récupérez alors vos valeurs, votre session contre ce ticket. Ce mécanisme est nécessaire car il n’est pas souhaitable de sérialiser vos données et de les passer au client. Le souci : cela entraîne une consommation de mémoire du côté serveur car le développeur Java aura tendance à mettre en session tout et n’importe quoi.

Il y a eu une tentative de faire travailler le navigateur Web, et de lui donner alors toutes les données de session. L’avantage ? Les Serveurs sans état peuvent alors être monté en cluster, et le navigateur passe les données de session de page en page. Cela fonctionne avec de la réécriture d’URL lorsque vous faîtes des GET ou en postant les données dans des champs cachés si vous faîtes du POST. Cela marche très bien, c’est le principe d’eBay. Il y a cependant quelques limitations, comme la taille des URIs par exemple. Vous ne vous êtes pas demandé quel serait la taille maximale d’une URI ?
Avant tout, la RFC 2616 (Hypertext Transfer Protocol — HTTP/1.1) précise dans la section 3.2.1 qu’il n’y a pas de limite sur la taille d’une URI. En théorie, il serait donc possible de passer des données de session énorme. Dans les faits, c’est faux. Internet Explorer ne dépasse pas 2083 caractères, Firefox pousse jusqu’à 65565 caractères. Mais les serveurs Webs comme Apache limitent à 4000 caractères par défaut, comme parfois les proxy qui se chargent de faire de la redirection ou du load-balancing.

En général, les frameworks Webs évitent d’avoir une notion de session qui coûte de la mémoire côté serveur lorsque celle-ci n’est pas indispensable. Les frameworks Javas ont proposé très tôt ce concept de Session. Pour monter plus de Sessions, il faudra souvent avoir plus de mémoire. Personne n’aura expliqué au développeur Web Java comment calculer la taille de sa session.

Il y eu ensuite le souci de la durée de vie des Sessions. Soit aucune session, proche des EJB stateless, soit avec une session, on pense aux EJBs statefull. Mais ce concept métier ne fonctionnait pas bien avec le Web. Lorsque les premières architectures Webs pour la partie vue ont commencé à discuter avec des architectures métiers écrites sur la base des EJB 2.x, ce fut assez amusant. Pour que le monde du Web puisse afficher des données sur plusieurs écrans successifs, il fallait les stocker dans le « Web Tiers ». Nous avons utilisé des DTO, représentant des données venues de la partie métier. Puis quelqu’un a dit un jour que la séparation entre le Web tiers et l’EJB Tiers était une grosse bêtise inventée par des vendeurs de machines. Et nous avons tué cette idée aussi rapidement qu’elle s’était diffusée. Je rigole pas trop fort car je connais encore beaucoup de systèmes en production avec un tiers Web, et un tiers EJB. Il y a un firewall entre le monde extérieur et le Web tiers. Puis un deuxième firewall entre le web tiers et l’ejb tiers. Bien entendu, 4 machines pour le tout, afin de faire du load-balancing… J’imagine le sourire du commercial qui a vendu les machines à l’époque.

Seam a introduit le concept de conversation. En décembre 2006 j’en parlais avec passion. Cela a été repris dans CDI, dans JEE6. Et le concept de conversation Flash est aussi maintenant partie intégrante de Grails ou de Play! Framework par exemple. Preuve qu’il est possible de gérer de manière fine la durée des sessions.

Tout ceci pour dire que je crois que les frameworks Javas et le monde Web ne se sont pas vraiment compris. Nous avons souvent une complexité culturelle avec Java, qui n’est pas nécessaire lorsque l’on fait du Web (idée de Guillaume Bort, auteur de Play! Framework). Les développeurs Javas que je connais, même les meilleurs, n’ont pas nécessairement la culture Web. Avoir une culture Web pour moi, c’est connaître le protocole HTTP, HTML, CSS, REST et les possibilités des architectures sans états. Ce n’est pas imposer une vision middleware, qui ne fonctionne pas avec le Web. C’est certainement une chose sur laquelle nous devons encore travailler, nous qui sommes développeur Java. Le jour où SUN Microsystems, IBM et HP ont décidé que pour vendre de la machine, il fallait de la complexité, nous aurions dû faire attention. Pourquoi les autres langages comme PHP, Python, Perl ou C# ont-ils des frameworks Webs digne de ce nom ? Parce qu’ils n’ont pas cherché à en faire une longue histoire compliquée. Parce qu’ils ont respecté HTTP pour ce qu’il était, sans essayer une danse du ventre pour séduire les développeurs, pour finalement les planter quelques mois plus tard. Que celui qui n’a jamais entendu un AdminSys râler à propos de Tomcat et des serveurs d’applications lève la main…

J’écris cela car je pense que le Web et Java ont encore des efforts pour se comprendre. Je ne suis pas extasié devant GWT, inventé pour masquer la complexité de JavaScript. Je ne suis pas impressionné par Apache Wicket qui permet de coder « à la Swing » dans un monde massivement orienté objet une application Web, qui n’a que faire de l’orienté objet. Je ne suis pas impressionné par JSF 2 qui a rattrapé le retard, mais qui dispose de plusieurs implémentations, qui demande le support d’une librairie externe pour faire de l’AJAX, et qui demande des librairies pour faire de l’orienté composant…

Je suis impressionné par contre par la créativité des développeurs Javas, qui cherchent parfois à faire du client lourd dans un navigateur, en appelant cela « un client léger ». Bon sang, une application Web n’a rien à voir avec la vision à papa, avec des fenêtres et des boutons qui font pouet-pouet… Prenez dans ce cas une techno comme Flex par exemple, pour faire un client déporté

Je pense qu’il est temps de faire simple. Les vraies architectures Webs c’est pour maintenant. Allez lire sur le blog de Guillaume Bort pourquoi Play! Framework n’est pas basé sur l’API Servlet. C’est très intéressant.

Merci de penser que Java et les frameworks Webs c’est simple.

Compte-rendu de la présentation de Wicket et du Web Sémantique

Nicolas Martignole — Wed, 11 Mar 2009 19:50:40 +0000

Atterrissage en douceur hier soir sur la planète Wicket, avec aux commandes les 2 fondateurs de Zénika : Carl Azoury et Nicolas André, anciens de Sysdeo et maintenant aux commandes de Zénika. Le format choisi était ambitieux : réaliser en une heure une application CRUD de gestion de contacts. Quelques sueurs froides au départ, mais pour la suite franchement c’était vraiment bien piloté. De mémoire de Jugeur, les derniers codeurs en direct étaient Jean-François Hélie et Christian Blavier d’OCTO Technologies en juin dernier, lors de la soirée TDD et Spring. Je trouve qu’ils ont vraiment bien assuré sur le contenu et sur la forme.

Avant cela, Antonio rappelle l’importance des sponsors, le Paris JUG a besoin de l’aide et du support de sponsors afin de continuer à pouvoir accueillir tout le monde. Concernant l’offre Java BlackBelt évoquée le mois dernier, vous pouvez contacter l’équipe en vous abonnant à la liste de diffusion du Paris JUG directement sur le site. Enfin chacun est venu avec son attestation d’inscription. Les places sont limitées pour des raisons de sécurité. Hier soir je pense que la salle était pleine avec ses 180 places.

La présentation Wicket elle-même était sympa, je pense que mes voisins seront en mesure de couvrir en détail la soirée. Allez voir Olivier (de Zenika) je pense que son blog ne manquera pas de vous expliquer le contenu de la soirée.

Carl a annoncé que le 29 avril prochain se tiendra une nouvelle soirée sur le thème de Wicket organisée comme la présentation de Lean. Le présentateur sera l’un des co-auteur de Wicket, je crois qu’il s’agit de Jonathan Locke. A suivre donc. Encore une fois bravo à Zénika qui après Ross Mason, Ari Zilka et la présentation sur Lean, prépare un événement sympathique.

Enfin pour terminer, Nicolas André et Carl Azoury ont montré qu’en 163 lignes de codes et 12 classes, il était possible de réaliser une application Web Ajaxisée avec le support du Drag-and-drop. Zenika propose un concours sur leur blog à ceux qui souhaitent coder la même application avec une autre technologie que Wicket. Le cahier des charges est assez précis, retrouvez l’article complet sur le blog de Zenika.

Après un buffer où j’ai croisé pas mal de monde, la deuxième partie de la soirée était une présentation du Web Sémantique par Alexandre Bertails d’Atos Origin Open Source Center. La présentation était très claire, alors que le sujet est assez compliqué à expliquer. Les notions de Triplet, d’URI, de Graphe ont peut-être fait peur à quelques-uns d’entre nous. Ce que j’ai retenu, c’est que l’objet du Web Sémantique est de séparer les Données des Applications qui les gèrent. Ainsi, à terme on imagine un moyen complet pour décrire de l’information. Cela ouvre la porte à la création d’applications capable de s’approprier l’information et d’y apporter de la valeur.
Alexandre prend l’exemple de la construction d’une phrase : SUJET – VERBE – COMPLEMENT pour expliquer la notion de Triplet. Par exemple :

Le Touilleur est un blog

Chacun des éléments du Triplet sont donc le sujet, le verbe et le complément. Le tout est décrit avec 3 URI différentes pour chacun des tuples. Bien entendu différents formats comme RDF ou OWL permettent de formaliser en langage informatique ces prédicats. Je discute un moment avec Sébastien Letélié, directeur technique d’Improve Santé. La formalisation du dossier médical avec le Web Sémantique permet de s’assurer que le format pour exprimer finalement nos données est ensuite utilisé au mieux. Il travaille je crois sur un projet avec le SAMU afin de proposer à terme un système médicalisé basé sur une ontologie médical, où les médecins décrivent et mettent au point ces concepts.

Alexandre présente un site que vous pouvez vous aussi tester si les concepts de Web Sémantique vous semblent un peu compliqué. Le site dbpedia.org est une extraction du contenu de Wikipedia, enregistré avec le format du web sémantique.
Vous pouvez ainsi entrer des requêtes simples en utilisant par exemple OpenLink iSPARQL. Un exemple de requête logique:

Barack Obama | est né | à un endroit
Un endroit | a | pour nom ?

Regardez par exemple la page sur Java de dbpedia avec les différents attributs (les tuplets). On constate que le contenu exprime avec des URI le type de contenu. La page web elle-même vous présente de l’information, mais démarque aussi le contenu avec des annotations afin de vous dire : « ici c’est le titre » « là c’est une image » « ici il s’agit d’un commentaire », ce qui permet alors à votre navigateur d’en déduire ce que vous voyez.

Je sens que je rame.

Imaginez le Touilleur Express : chaque article est balisé (de manière invisible pour vous). Lorsque je place une date dans un de mes articles, je précise qu’il s’agit d’un rendez-vous. Firefox qui affiche la page peut alors vous proposer par exemple de sauver ce rendez-vous dans votre agenda. C’est ce que l’on appelle les microformats, sans doute l’avenir du contenu intelligent sur Internet. Le site officiel sur les microformats nous informe qu’un certain nombre de format, spécifié avec RFC, sont dans les cartons. Tout ceci est encore assez jeune, Alexandre explique que les derniers travaux datent de l’an passé.

En conclusion, car j’ai du mal à vous retranscrire ici cette très bonne présentation, je pense que le Web sémantique est un concept qui sera mature d’ici quelques mois, voire quelques années. Avec la puissance des réseaux et ce besoin de libérer les données des applications, nous pourrons alors avoir une nouvelle forme de navigation sur Internet, un nouveau moyen d’échanger l’information.

Le mois prochain la prochaine présentation du Paris JUG sera sur Scrum, par Eric Mignot et moi-même. Nous travaillons avec Eric sur un format et un contenu qui sera spécialement formaté pour le Paris JUG, avec pour moi l’envie de vous proposer une présentation aux petits oignons.

Au mois prochain !

Références :
Blog de Sébastien Letélié

Quelques sites indispensables pour vos développements Webs

Nicolas Martignole — Tue, 17 Jun 2008 06:05:01 +0000

Ce matin un post qui n’a rien à voir avec Java, ni Apple… pour une fois !

J’ai en réserve un bon nombre d’adresse que j’utilise lorsque je dois valider un site, créer rapidement un logo ou trouver une mise en page CSS sympathique. Je n’ai pas tout repris ici mais voici déjà quelques uns de mes liens.

BrowserShots est un site qui vous permet de tester votre site internet avec différents navigateurs. Pour cela le site visite votre page et effectue une capture d’écran, que vous pouvez ensuite télécharger. Le Touilleur Express par exemple ne marche pas très bien avec certaines versions d’Opéra. Pratique et rapide.
http://browsershots.org/

L’adresse de courrier électronique poubelle, vous connaissez ? Disons que vous avez besoin de vous inscrire afin de recevoir un email d’un site marchand un peu douteux, le site SpamBox propose de créer un email valable une heure seulement. Cependant avant de m’en servir, je vérifierai bien si ce site lui-même n’en profite pas pour récupérer votre vraie adresse email pour la revendre… On est jamais trop prudent.

Le logo en flamme, le logo en flamme ! Si vous cherchez quelques tutoriaux afin de créer votre logo en flamme, allez jeter un oeil sur le blog de DesignVitality. J’aime particulièrement les designs Web 2.0.

Le site DaFont offre une très grande collection de polices pour réaliser des applications webs, des sites et des logos. Il y a des polices très originales qui permettent de réaliser la patte d’un site en quelques instants.

Le site qu’il faut avoir dans ses bookmarks car il contient finalement un peu prêt tout ce dont j’ai besoin lorsque je crée un habillage : http://webdevelopersfieldguide.com/. Par exemple une roue colométrique pour l’équilibre des couleurs. Ou un système comme DeGraeve.com qui se base sur une image pour vous proposer une carte de couleurs.

Pour suivre l’actualité autour d’Ajax et des librairies comme Prototype ou Script.aculo.us, je vous avais déjà parlé d’Ajaxian.com. Le site propose souvent des articles assez pointus sur Ajax et Javascript.

En ce moment nous corrigeons des problèmes de Closures en Javascript. Je cherchais sur le net un outil que j’avais testé il y a 2 ans pour identifier des closures… Je tappe quelques mots et je tombe… sur mon blog… Ca fait bizarre de se répondre à soi-même… Si vous voulez briller en société et expliqué à un client ou à un consultant ce qu’est une Closure, je vous redonne cette page très bien faite, avant de vous proposer à mon tour une explication en français dans le texte prochainement. Oui on ne le dit pas assez, mais un certain nombre de librairies Ajax peuvent causer des problèmes de mémoire du côté du navigateur.

Joomla, un gestionnaire de contenu pour votre site

Nicolas Martignole — Sun, 13 Jan 2008 18:17:48 +0000

Joomla est un système de gestion de contenu pour votre site web. Il est gratuit, simple et destiné à vous faciliter la vie. Basé sur PHP, Joomla permet de construire des sites Internets complexes (forum, système de vote, mailing…) sans taper une ligne de PHP ou d’HTML. Pour ma part, j’ai commencé à travailler avec la nouvelle version 1.5 RC4.

Vous avez besoin d’un serveur avec une base de données MySQL et le support PHP. Ensuite concernant le look, les templates permettent d’habiller d’un seul clic votre site. Et vous pouvez changer ensuite à tout moment d’habillage sans une ligne de code. Sous Mac, aucuns problèmes pour installer Apache+MySQL grâce à MAMP (Mac, Apache, MySQL et PHP). Sous Windows vous pouvez télécharger XAMPP. Comptez quelques heures pour maîtriser Joomla si vous avez déjà une expérience avec Internet. Sinon tout au plus une semaine je pense.

Concernant la compatibilité avec la version 1.0 vous pouvez activer le plugin System – Legacy afin de pouvoir utiliser un template 1.0 avec la version 1.5 de Joomla. Cela dit, les templates sont en fait une simple page PHP et quelques CSS.

Si vous utilisez Joomla et que vous chercher des templates gratuits, je vous conseille les sites suivants:

Pour le Touilleur, je suis hébergé sur le site JRoller. Il a l’avantage d’être gratuit et bien référencé. Mais je pense qu’à terme je prendrai un hébergement dédié afin de pouvoir d’une part mon blog, et d’autre part un site plus classique pour le boulot. Voili voilà