Rendez-vous en terre inconnue : Play! Framework

Je me suis trouvé récemment (comme régulièrement beaucoup de développeurs je pense) devant une petite application web à réaliser sans architecture précise définie.

Après 12 ans de développement JAVA classique, je me suis dit qu’il était temps de voir autre chose.

Je regarde très vaguement les outils qui existent, demande deux-trois conseils à droite et à gauche et je commence à me diriger vers Groovy/Grails lorsqu’on me conseille de jeter un œil à Play.

Késako Play ?

Je me rends sur le site officiel (http://www.playframework.org) et j’y apprends que Play est un framework de développement qui se focalise plus sur la productivité du développeur et sur les architectures RESTful.

Justement, ça tombe bien, la productivité de mon développement, ça m’intéresse.

Je décide donc de creuser plus avant.

JAVA ou SCALA ?

Là, un premier choix, je vois une version 1.2.4 et une version 2.0.1 (nous sommes en mai 2012 à ce moment-là).

Je comprends rapidement que le framework est parti sur deux approches différentes : la version 1.X.X qui est une version JAVA et la version 2.X.X qui est une version SCALA.

Plusieurs éléments rentrent en compte dans mon choix :

-         Je connais JAVA mais pas SCALA (je sais que j’ai dit plus haut que je voulais voir autre chose mais le but est aussi de pouvoir comparer une augmentation de productivité donc SCALA, on verra plus tard).

-         Le framework en est à ce moment-là (mai 2012) à 15 versions différentes en JAVA et seulement 2 en SCALA. N’ayant pas envie de payer les pots cassés d’une version encore « neuve », la version JAVA me parait plus prudente.

-         De plus, la version SCALA n’ayant qu’un mois d’existence (officielle), je me dis aussi que plus de modules doivent exister pour la version JAVA.

Donc mon choix se porte sur la version JAVA du framework.

Installation (plus vite que son ombre)

Je télécharge le zip du framework (58.1 Mo pour la version 1.2.4, 90.1 Mo pour la 2.0.1, la version SCALA semble contenir plus de choses) et je l’extrais dans un répertoire sur le disque.

Je rajoute ce répertoire dans le PATH de mon système et c’est tout.

C’est tout ?

Presque. J’avais bien évidemment un JAVA installé sur mon système mais bon, tout développeur JAVA a déjà ça.

Je n’ai plus qu’à lancer la commande ‘play’ en ligne de commande pour voir que tout fonctionne.

~        _            _

~  _ __ | | __ _ _  _| |

~ | '_ | |/ _' | || |_|

~ |  __/|_|____|__ (_)

~ |_|            |__/

~

~ play! 1.2.4, http://www.playframework.org

~

~ Usage: play cmd [app_path] [--options]

~

~ with,  new     Create a new application

~ run      Run the application in the current shell

~           help     Show play help

~

Mon IDE bien-aimé

Je suis les premières parties du tutoriel en éditant mes fichiers avec un éditeur de texte standard (Notepad++, vim, emacs,…), je me demande « qu’en est-il de mon IDE préféré » (Eclipse pour ma part) et là, Play a tout prévu, il propose une petite commande sympathique permettant de créer la configuration nécessaire à l’import dans Eclipse (eclipsify), il suffit de lancer en ligne de commande « play eclipsify nom_du_projet » et ensuite d’importer dans Eclipse, Play aura tout généré y compris les serveurs de lancement de l’application depuis Eclipse.

Par contre, si l’on modifie le projet play dans sa configuration (comme rajouter des modules), il convient de répéter l’opération (effacer le projet d’Eclipse, eclipsify et réimport du projet).

Apparemment, cette ligne de commande existe aussi pour d’autres IDEs comme Netbeans (netbeansify) ou IntelliJ IDEA (idealize) et il existe des aides à la coloration syntaxique et d’auto complétion pour Textmate et VIM.

Premier exemple et tutoriels

Evidemment, le premier exemple qu’on me propose est le fameux Hello World, qu’on a tous fait 30000 fois (ou plutôt qu’on a jamais fait sauf peut-être la première fois mais qu’on a lu partout).

Là, l’exemple est un peu plus complet que d’habitude et  passe par les phases d’installation, de création d’un projet Play, de lancement de l’application en ligne de commande, aborde la création d’un formulaire simple, le mapping d’URLs, la partie visuelle de l’application, la validation des données et la création d’un test automatisé en Sélenium. Pas mal pour juste un Hello World.

Le tutoriel suivant donne un peu plus de grain à moudre et nous propose de créer du début à la fin un moteur de blog. Il est plutôt bien fait et montre bien toutes les possibilités du framework malgré quelques petites erreurs pas bien gênantes que l’on repère aisément (peut-être corrigées depuis). Ce tutoriel donne une bonne base pour démarrer une application web, personnellement, je suis parti de celui-ci pour construire la mienne en modifiant ce qui m’était inutile et en incrémentant dessus.

Il ne manque plus qu’à rajouter vos librairies préférées au projet, éventuellement un petit Twitter Bootstrap (pour rajouter un peu de nerd dans votre interface) et vous êtes prêts à conquérir le monde (ou au moins faire votre application web).

Et dans la vraie vie du développeur, ça change quoi ?

Premièrement, ça ne vous rendra pas séduisant, riche et puissant, je préfère vous le dire tout de suite.

Mais ça vous fera gagner du temps et ça c’est déjà pas mal.

La première chose qui m’a frappé, c’est que pendant tout mon développement, je n’ai jamais eu à redémarrer mon serveur. Ca parait peut-être minime mais je n’ai plus de long cycle de compilation-packaging-déploiement comme je pouvais avoir dans les plateformes J2EE classiques. J’ai un bug, je le corrige, je recharge ma page depuis mon navigateur, c’est tout.

Un vrai bonheur.

Play utilise MVC, littéralement. Les classes JAVA sont réparties entre Controllers et Models et les templates représentent la vue.

Les Controllers contiennent le code de gestion de l’application et les Models ne sont que des POJOs.

Les templates quant à eux sont (la plupart du temps) des fichiers HTML classiques mais le langage de templating de Play est du GROOVY (chic, je peux apprendre des nouvelles choses) qui garde une syntaxe cohérente avec le JAVA. Du coup, mes templates sont bien moins verbeux que si j’avais dû utiliser des JSPs et leur cohorte de taglibs classiques. On peut bien évidemment produire autre chose que du HTML (JSON, e-mail,…).

Je n’ai pas encore parlé base de données (peut-être parce que ce n’est pas mon fort). A priori, on peut raccorder n’importe quelle base à Play mais si on n’a pas envie de s’embêter dans un premier temps, on peut utiliser une base en mémoire. Play offre des facilités pour JPA, plus besoin de configurer, gérer ou synchroniser l’EntityManager, c’est fait de manière automatique et transparente, de plus, si votre POJO hérite de la classe play.db.jpa.Model, vous disposez de nombreuses méthodes rendant la requête et la modification de vos objets bien plus simples.

Les tests. Pas toujours la partie la plus excitante d’une application web.

Là aussi, Play vous facilite la vie avec des outils permettant d’écrire des tests unitaires, fonctionnels ou Selenium, de les jouer depuis le navigateur  et de facilement visualiser la couverture du code par les tests (via le module Cobertura). Les tests peuvent aussi être lancés en automatique et cela permet de gérer une intégration continue minimale très facilement.

Pour en venir au code lui-même, ce que j’apprécie particulièrement, c’est le binding des paramètres http avec la méthode JAVA d’un contrôleur. Par exemple, si vous avez un paramètre http ‘nom’, il suffit de déclarer comme paramètre de la méthode du contrôleur appelé et Play fait le binding tout seul (en convertissant si on utilise par exemple un objet Date ou Integer). Ca marche même avec les objets File (l’upload de fichiers tient en une ligne de code quasiment).

Exemple :

Pour une requête

/services/show?nom=MonService&date=05/01/2013

Il suffit de définir une méthode

public static void show (String nom, Date date){

}

Cela fonctionne aussi avec une classe :

public class Service {

public String nom ;

public Date date ;

}

<form action="/services/show" method="POST">
    Nom: <input type="text" name="s.nom" />
    Date: <input type="text" name="s.date" />
</form>
public static void show(Service s) {
        …
}

Et pour uploader une image par exemple:

#{form @uploadImage(), enctype:'multipart/form-data'}
    <input type="text" name="title" />
    <input type="file" id="photo" name="photo" />
    <input type="submit" value="Envoyer" />
#{/}
public static void uploadImage(String title, File photo) {
   ...
}

De même, en sortie de méthode, on appelle en général la méthode render() qui renvoie automatiquement vers la vue associée à la méthode du contrôleur appelée (via une norme de nommage ultra simple) et on peut lui passer n’importe quoi en paramètre du type simple à l’objet complexe, il suffira ensuite de récupérer dans la vue via le nom du paramètre envoyé avec render().

Plus besoin de lignes de code inutiles permettant de placer les objets en session ou en requête pour les récupérer ensuite dans les pages JSP. Là, c’est simple et concis.

Exemple :

Dans un framework JAVA classique, on utilise cette syntaxe :

Service service = Service.findById(id);
User user = User.getConnected();
Map<String, Object> model = new HashMap<String,Object>();
model.put("service", service);
model.put("user", user);
render(model);

Dans Play :

Service service = Service.findById(id);
User user = User.getConnected();
render(service, user);

Et on utilise par exemple dans le template les valeurs ${service.nom} ou ${user.id} pour récupérer respectivement le nom du Service ou l’id du User.

Avantages et inconvénients de Play

Bon, après quelques mois d’utilisation (j’écris ceci début janvier 2013, soit 9 mois plus tard), je suis assez content de mon utilisation de Play.

Pour moi, ces principaux avantages sont :

-         Rapidité d’installation et simplicité de configuration.

-         Gain de confort de développement JAVA grâce au fait de l’absence de temps d’attente entre la création ou la modification d’une fonction et son test.

-         Gain de productivité car le code produit est simplifié par plein de petites choses qui évitent de réinventer la roue à chaque fois (passage des paramètres notamment).

-         Facilité d’utilisation d’Hibernate/JPA.

-         Pas mal de modules existants dans la communauté.

Par contre, les quelques problèmes que j’ai pu rencontrer :

-         Le framework est encore récent et lorsqu’on tombe sur un problème précis voire même obscur, il n’est pas aisé de trouver une réponse satisfaisante (malgré les centaines de problèmes déjà résolus sur le web). Bien sur, la communauté est très présente mais tout le monde tombe parfois sur des bugs impossibles à reproduire ailleurs. Pour ma part, j’avais un souci Hibernate (‘found two representations of same collection’) que j’ai mis un temps fou à corriger malgré les dizaines de personnes ayant le même problème. Et ce problème ne se passait que sur mon serveur distant et pas sur mon serveur local.

-         Il me semble aussi (et c’est juste mon impression) que la communauté Play est plutôt en train de bifurquer vers la version SCALA du framework et est en train d’abandonner la version 1 (JAVA), c’est d’autant plus visible quand on cherche une info précise, il faut savoir naviguer entre les versions.

Conclusion

J’ai eu la chance de travailler en parallèle de mon projet Play sur un projet Groovy/Grails (qui était un de mes choix de départ pour cette application) et cela m’a permis de comparer le développement entre les deux.

Même si ma pratique de Groovy est loin d’être mon habitude de JAVA, je me suis souvent retrouvé à attendre la compilation dans Grails sur cet autre projet (pas longtemps à chaque fois mais souvent au final) et je pense vraiment qu’au global, cela finit par entamer la patience d’un développeur. Même si Groovy est plus concis en terme de syntaxe et donc permet une meilleure productivité que JAVA si le développeur connaît bien le langage, la simplification du JAVA utilisé dans Play, le Groovy dans les templates et la qualité de confort procuré par un serveur qui tourne sans s’arrêter me font préférer Play pour tout nouveau développement.

Je pense qu’il permet un accroissement de productivité rapide même chez un développeur débutant et je reviendrai sûrement vers ce framework même pour mes projets personnels.

Je n’ai pas abordé (par manque de temps) beaucoup d’autres aspects intéressants comme la facilité de configuration d’un environnement de production ou l’hébergement d’une application Play, je vous laisse découvrir tout ça sur le site officiel (http://www.playframework.org).

Pour ma part, je ne vais pas mourir idiot et je vais commencer à me mettre à Scala.

Un commentaire

  1. Bienvenue sur la planete Play Framework.

    J’ai le meme constat sur la version Scala. La communauté est en train de migrer.

    Au début, j’ai trouvé la version 2,X trés déroutante, à cause du langage scala,
    a cause de la non compatibilité entre la version 1,2,5 et 2,0.
    Avec le recul, j’ai découvert les avantages de ce nouveau langage.
    Un super java qui fonctionne dans une JVM.

    J’ai investi sur la version 1,2,5,
    J’ai utilisé de nombreux modules (GAE, siena)
    que je ne trouve pas dans la version 2.

    J’ai pris gout a cette bestiole, et je me demande comment on a pu faire des usines
    à gaz avec Struts, Spring, Hibernate et ainsi de suite,

    Pourquoi faire simple, quand on peut faire compliquer ?

    Petit a petit, je vois évoluer la version 2,X.

    Je me rend compte des impacts de scala sur mes développements java
    (amélioration globale de la qualité, testabilité).

    Je t’invite a passer à scala.

    @ Bientôt

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.