Play!

Ce mercredi 27 janvier, nous avons assisté à la présentation du framework Play! au travers d’un défi simple : développer la mini application Web de gestion de contacts ZenContact. L’avantage de l’application ZenContact est d’avoir un point de référence à partir duquel nous pouvons comparer les frameworks entre eux.

La présentation était très attendue. La salle était comble et nous avons dû refuser des inscriptions pour manque de place. En effet, bien que sortie en version 1.0 en octobre, le framework Play! a déjà fait parler de lui. Nous pouvons par exemple le trouver dans le livre blanc de Xebia, ce qui est étonnant pour un si jeune framework ; un livre blanc étant en général destiné à présenter l’état de l’art, donc de ce qui a fait un minimum ses preuves.

Pour commencer, comme avec Grails, la structure d’une application Web est imposée par Play! et n’est pas compatible avec un système de gestion de cycle de build comme Maven. D’ailleurs, dans Play! le cycle de build du code est rendu transparent en compilant à la volée le moindre changement dans les sources, et ceci grâce à l’intégration du compilateur Java d’Eclipse. A la différence de Grails, le choix a été fait d’utiliser Java comme langage, ce qui permet de profiter des fonctionnalités avancées d’un IDE dédié. D’ailleurs, tout le travail d’édition de code se fait via l’IDE ; pas besoin d’un outil spécifique pour créer telle ou telle classe d’objet. ( Pour illustrer la simplicité d’écriture de code avec Play!, Guillaume Bort a fait le choix de n’utiliser qu’un simple éditeur de texte avancé (Text Mate)).

Guillaume Bort

Du côté Web, malheureusement (c’est mon avis), pas de surprise, comme la plupart des frameworks Web, Play! repose sur une approche classique MVC et sur un moteur de templates côté IHM ; la nouveauté ne se trouve donc pas de ce côté-ci. Le moteur et le langage de template est maison et repose sur un socle Groovy. Les choix de conception sur le langage sont à mon avis pertinent et intéressant : ils rendent l’usage de templating plus aisé. A côté de ceci, comme le veut la nouvelle vague, l’ensemble IHM client/serveur repose sur la convention : ainsi à un contrôleur correspond un répertoire de même nom dans lequel sont regroupés les fichiers Web (HTML, XML, …) avec pour intitulé l’action défini dans le contrôleur. A côté de ceci, comme avec d’autres frameworks, l’association URL avec le contrôleur est réalisé par un fichier de mapping relativement simple.

Ensuite, comme la majorité des frameworks Web Java, Play! fait usage des technologies ou outils qui ont fait leur preuve ou qui apportent un réel gain de productivité. On peut citer par exemple Hibernate pour le mapping Objet/Relationnel et JPA pour la gestion de la persistance. Le tout est évidemment intégré de façon quasi-transparente pour le développeur. D’ailleurs, l’intégration est le maître mot de Play! mais à un point que ses concurrents n’ont pas osé franchir : ils ont cassé le modèle Java Web classique à base de servlet pour proposer leur propre solution. Le résultat est qu’ils intègrent directement le serveur d’application Web avec l’application, donc un serveur Web maison dédié. La raison ? Au même titre que pour le développement, faciliter aussi le déploiement en production de l’application Web. Ce point n’a pas été montré et il reste encore à le vérifier dans un contexte réel ; et ceci d’autant plus qu’il aura à faire face à une forte opposition culturelle dans les entreprises où souvent la simplicité est vue, parfois inconsciemment, plus comme quelque chose de soupçonneux.

Pour finir, Play! a fait donc le choix de la rupture tout en s’inscrivant dans la tendance actuelle que l’on pourrait appeler la REST way. Play! est avant tout un framework pour construire une application Web et rien d’autre. Les concepteurs de ce framework sont d’ailleurs bien insisté sur ce point. Et pour eux, le Web est mieux servi par une approche REST que par toute autre autre. Ainsi, chaque page Web est un rendu de l’état courant d’une ressource identifiée par l’URL, celle-ci pouvant être représentée par un objet métier dans l’application. Dans Play!, la représentation de la ressource Web peut aussi bien être du HTML (pour une interaction avec un utilisateur finale), que du XML ou du JSON ou encore du PDF.

Voici le compte-rendu fait par Loïc Descotte de son dojo.

Sinon vous pouvez aussi consulter les slides présentées lors de la session du GenevaJug.
Et enfin Romain a traduit le tutorial Play! en français et vous pouvez le suivre si vous n’avez pu participer au dojo.
Le résultat du dojo est téléchargeable sous la forme d’une application de démonstration ici .