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) { Listarticles = 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)
Bonjour !
Merci pour l’info.
J’aimerais beaucoup avoir votre avis par rapport à Grails vu que vous avez l’air de vous passionner pour les deux 🙂
PS: Y aussi lift sous Scala dans le style « rails ».
Merci pour cette présentation. Je me permet juste de dire que je trouve que GWT n’est pas du tout à classer à côté de Wicket, JSF ou tapestry. GWT est plutôt est un outil pour fabriquer des clients de service web hébergés dans le navigateur, et s’inscrit donc dans une logique plus REST : le clent connait son état, le serveur non. Comme il est dit dans cet article Wicket et toute la bande font tout le contraire : c’est le serveur qui connaît l’état de l’application.
J’aimerais bien aller a la présentation de Play!, mais lorsqu’on essaye de s’inscrire :
« We are unable to process your registration at this time. Thank you for your interest. »
🙁
Tant pis. Je réseesayerais demain …
Bonjour Nicolas,
Bonne chance pour tes nouvelles activités 🙂
Pourquoi indiques tu que GWT implique une session coté serveur ? Comme indiqué plus haut , il est naturel de maintenir l’état coté client et donc d’avoir un serveur stateless.
a+
Autant que je sache, Bazaar (http://bazaar.canonical.com/en/) est simplement le gestionnaire de code source utilisé par le projet. C’est l’équivalent d’un CVS, SVN ou Git, sponsorisé par Canonical (l’éditeur d’Ubuntu).
Bazaar, c’est pas un gestionnaire de sources distribué, comme GIT ou Mercurial? Utilisé par je ne sais plus quels projets open source… Oublié..
J’avais jeté un coup d’oeil à Play! il y a 8 mois, et il y a une autre particularité qui m’avais surpris : l’absence totale de session côté serveur. Je ne sais pas si c’est ce dont tu parlais dans cet article, mais sur le plan technique c’est vraiment particulier.
C’est le client qui garde les informations de session dans un cookie. Le cookie est signé (=intégrité). Cela permet de multiplier les instances de serveur sans devoir mettre en place de mécanisme complexe de synchronisation de la session… Juste génial!
Merci pour cette présentation, ça donne envie d’essayer!
Ça rejoins bien ce que je pense sur la gestion de la session côté serveur, ça me fait toujours un peu peur quand je vois tout ce Wicket stocke en session…
Peut être qu’on arrivera à régler complètement ce genre de problème avec html5 et le stockage de session côté client…
A propos de la conso mémoire des session selon les framework, je suis retombé sur ce lien qui fait quand même relativiser un peu…
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
Bonjour,
J’ai eu la chance en 2008 de suivre une brève présentation de ce framework. A l’époque je présentais une formation EJB 2.1 dans une école d’ingénieur à Cergy, les pauvres élèves les EJB 2 ils ont pas aimé alors qu’ils maitrisaient pour certain hibernate.
Un élève était un contributeur au projet et il avait organisé un petit séminaire le soir après les cours.
Malgré une bonne présentation, j’avoue qu’à l’époque je n’avais pas trop accroché à l’idée. Oh my goodness créer des propriétés public c’était une étape trop difficile à franchir pour mon petit être élevé dans le dogme irréfutable de l’encapsulation sacrée. Mais depuis, j’ai fais le deuil et je me penche sur des framwork qui me permettent d’avoir une meilleure productivité. J’ai regardé Ror, et Grail mais là c’est vrais que c’est du full java et qu’il y a des idées sympas alors peut être que … 🙂
Un peu dans le même genre j’ai depuis peux un oeil sur le projet AribaWeb (http://aribaweb.org) quelqu’un a t’il déjà eu l’occasion de l’utiliser ?
@ Bonne soirée
Salut,
En tout cas j’ai hâte d’être au 27 Janvier pour un Coding Dojo spécial Play Framework que nous fera Guillaume Bort grâce à AlpesJug et au CARA :o)
Emmanuel
Nicolas, je suis d’accord avec ygrenzinger Play! ou Grails ?