Framework Play! à découvrir le jeudi 17 décembre

J’ai découvert le framework Play! à Devoxx 2009 et j’avoue avoir été assez impressionné par les concepts et les idées. C’est du Java, du pur Java. C’est un framework Web, avec des idées novatrices dont je vais vous parler dans quelques minutes.

L’objet de ce post c’est de vous faire part d’un événement ce jeudi 17 décembre à Paris. L’équipe des contributeurs du framework organise une soirée découverte de 18h30 à 21h00 chez Zenexity. Les détails et l’inscription sont sur cette page.

Play! est un framework Java créé par Guillaume Bort, avec des références et des projets en production, qui mérite le détour. La vidéo de la page d’accueil montre qu’il faut à peine 1 minute pour passer sa ceinture blanche sur Play! (le classique HelloWorld) et moins de 5 minutes pour comprendre les principes. Play! est semblable à Grails, mais c’est du pur Java. Clairement orienté efficacité, il plie en 4 les projets lourds. Apparenté à Rails dans l’idée, il y a bien entendu du redéploiement à chaud sans recompilation.

Play! est intéressant aussi car il y a beaucoup d’idées vraiment nouvelles. C’est un framework orienté développeur web. Nicolas Leroux avait demandé à Devoxx 2009 aux gens dans la salle s’ils se sentaient plutôt « Web Developer » ou « Enterprise Developer ». Au départ, la majorité des gens lèvent la main et s’affirment « Enterprise Developer ». Il explique ensuite que sa définition du Web Developer est plus « toute personne devant faire une application avec du Web ». Et là… presque tout le monde lève la main. C’est un fait : nous faisons tous du développement Web. Mais finalement, nous ne faisons pas tous du développement Entreprise. La définition des applications Webs est simple : proposer un service qui tourne sur un navigateur et laisser le soin aux clients riches de proposer une application. Play! comme Grails se place sur le plan de la création des applications Webs.

Lancé par Guillaume Bort en 2007, la version 1.0 est disponible depuis le 19 octobre. Avec déjà des déploiements et un support pour ceux qui veulent être aidé, Play! est donc mature. je dis cela pour les frigides qui attendent toujours la version 11 d’un produit avant de commencer à regarder.

Ce framework Web fait partie des frameworks sans état comme Grails ou Django. Contrairement à Wicket, JSF ou GWT qui savent ce que vous voyez à un instant T en maintenant une session en mémoire sur le serveur. On est là plus sur du Web classique, et donc ceux qui recherchent un framework orienté composant seront déçus. Mais en fait je vais vous dire un truc : pour un site Web il vaut mieux faire le choix de ce type de framework qui suivent ce que nous propose pour l’instant le protocole HTTP : l’absence d’état.
Play! est donc un framework clairement orienté REST, qui s’adapte aux standards du Web et qui fait ce que les autres font très bien : cookie, gestion du bouton back, authentification, etc. A titre personnel, puisque j’ai fait le choix de Grails pour mon projet, je vous avoue que j’y crois plus pour faire des sites Webs à fort trafic, plutôt que JSF ou Wicket.

Alors là vous vous dîtes : « ouais… bon et alors ? ».

Il n’y a pas de WAR. Lorsque vous développez, devinez sur quoi vous allez travailler ? Vos fichiers Java. Et il n’y a pas de compilation non plus. Ah ça c’est marrant non ? Et il n’y a donc pas de packaging. J’ai une pensée émue pour ceux qui compilent et partent prendre un café… Avec Play! vous n’aurez plus le temps.

Complètement codé par des développeurs, il y a encore d’autres trucs assez marrant, bien plus puissant qu’avec Grails. En premier lieu je pense à la gestion des erreurs. Lorsque vous saisissez une erreur, et que vous tentez d’exécuter votre page, Play! vous expose des erreurs très claires, et vous propose même une solution :

Il y a beaucoup de fonctions : la sécurité, un moteur CRUD, la validation, la gestion des jobs asynchrones, de l’I18N, les Fixtures, des services REST, OpenId, l’envoi d’emails, des extensions à JPA, bref c’est assez complet.

Play! propose plusieurs scopes comme Seam ou Grails : Application/Session/Flash et Request. Il y a aussi un moteur de binding simple qui permet de déclarer le nom d’une méthode à appeler selon une URL:

GET    /clients/{id}        Clients.show

Récupérer les paramètres de la Query String est aussi un jeu d’enfant. Si j’appelle GET /clients/222?date=08/01/08&page=2

public static void show(Date date, Integer page) {
    List
 articles = Articles.fromArchive(date, page);
    render(articles);
}

Les points qui vont vous étonner
Si vous êtes habitués à Wicket, vous êtes déjà habitué à étendre certaines classes de Wicket pour que votre code fonctionne. Play! aussi vous offre une partie magique, si en retour vous étendez les classes standards. Grails se base sur le répertoire où vous stocker votre code, et sur le fait que votre class se termine par « -Controller » pour la transformer en Controller par exemple. J’ai bien aimé l’approche de Play! qui propose de casser l’encapsulation, mettre en public vos propriétés, et donc ne pas écrire des getter/setter qui ne servent à rien. Après tout, à quoi bon encapsuler sans réelle raison ?
Comme Wicket, Play! propose d’ajouter à des pages HTML standards des tags afin de rendre « playable » votre page. On retrouve la même idée chez Grails.

Concernant le modèle, Play! ajoute à JPA quelques options sympathiques. Il est possible mais pas obligatoire de faire hériter votre classe de base de la classe Model de Play! comme sur cet exemple (tiré de la doc de Play!):

package models;

import java.util.*;
import javax.persistence.*;

import play.db.jpa.*;

@Entity
public class User extends Model {

    public String email;
    public String password;
    public String fullname;
    public boolean isAdmin;

    public User(String email, String password, String fullname) {
        this.email = email;
        this.password = password;
        this.fullname = fullname;
    }

}

Cela simplifie la gestion de JPA. Est-ce que vous avez remarqué que les propriétés sont publiques ? Play! se chargera de générer les getters/setters pour vous, afin de conserver l’encapsulation plus tard. Mais à ce moment de l’écriture du code, c’est inutile.

Il y a encore quelques concepts que je n’ai pas compris comme l’idée du « bazaar », un gestionnaire de code source où vous reversez vos modifications. Je ne vous ai pas aussi parlé de toute la partie test unitaire et test fonctionnel, très complète. Enfin pour vous laisser sur une grosse note positivie : Play! est fait de telle manière qu’une modification dans votre code Java peut être testé tout de suite, sans recompiler, packager et déployer votre application. Comme Grails dont je suis amoureux, Play! est un outil méga-productif qui éclate sans soucis les frameworks à état que sont GWT, JSF et Wicket. Play comme Grails se base sur ce qui marche pour faire du Web : REST et l’absence d’état en mémoire. A part la session de l’utilisateur au sens HTTP, il n’y a pas de mastodonte en mémoire, qui représente ce que voit l’utilisateur. Bon je m’arrête là, j’en aurai pour une heure à vous détailler ces idées, mais c’est l’une des raisons pour lesquelles j’ai pris Grails pour mon projet.

Bref si vous voulez découvrir un framework différent, rendez-vous jeudi 17 décembre. Je vous conseille aussi de lire les articles de Guillaume Bort, le fondateur du framework Play! car ses articles sont vraiment intéressants (essayez celui-ci)

Articles similaires:

Play! Framework est disponible officiellement sur Heroku Git et Play! Framework Play! Framework : envoyer un email Revue du livre Play Framework Cookbook d’Alexander Reelsen