Warry

Cet article est une réponse à celui de Florent Messa qui abordait l’opportunité offerte par l’arrivée de PHP 5.3, pour découvrir et adopter d’autres langages et frameworks. Il propose une comparaison entre Django, Symfony et Zend. Pour ma part je vais, sur les mêmes critères, me concentrer sur Play! Framework, bien que je ne connaisse pas ce framework sur le bout des doigts.

Play! est un framework relativement jeune en version 1.1, codé en Java et compatible avec Scala. Il a la particularité, par rapport aux autres frameworks Java, d’être complètement stateless, autoriser le rechargement à chaud (sans re-compilation), et de cibler les architectures REST. C’est en somme un RoR/Django like en Java. Et cocorico, il est français, initié et maintenu par Guillaume Bort et  la communauté.

notes:

• Dans Play! les modules sont eux-même des applications Play! Ils s’installent à l’aide de la commande “play install module-name-version”
• Les Samples sont disponibles dans le répertoire samples-and-test de Play! et sont des exemples des fonctionnalités les plus répandues à travers des exemples concrets (blog, forum, jobboard…).

Fonctionnalités

Comme Florent, je vais détailler l’utilisation de fonctionnalités dans Play!Framework, en réponse à des besoins très basiques, voire récurrents.

1. La gestion de mots clés (tags)

Besoin : taguer n’importe quel type de ressources : article, commentaire, lien, vidéo, etc.

Il n’existe pas de module Play! pour les tags, mais il est extrêmement simple de le créer grâce aux annotations JPA. D’ailleurs, une implémentation est disponible dans les samples de Play! (celui de Yabe plus précisément).

2. Recherche full-text

Besoin : effectuer une recherche sur l’ensemble du contenu et des ressources de l’application.

Le module Search permet de faire de la recherche full texte en base. Et ce module permet de s’interconnecter avec Solr.

3. Gestion des utilisateurs

Besoin : offrir un système complet d’authentification (connexion, déconnexion, validation du compte utilisateur, récupération du mot de passe, etc.), de gestion de groupes d’utilisateurs et de permission.

Il y a l’application Deadbold sur Github, ainsi que certains samples (Yabe, Jobbard…) qui démontrent différentes interprétations de l’authentification. Il y a d’autres exemples, l’authentification est un thème récurrent.

4. Interconnexion avec d’autres plateformes sociales

Besoin : se connecter via des applications tierces et pouvoir partager des liens vers celles-ci.

L’authentification HTTP (pratique pour bootstraper un projet) et OpenID sont build-in. Il existe également plusieurs module pour l’authentification dont OAuth, Facebook connect et un sample pour Facebook. 

5. Ajouter des commentaires

Besoin : commenter n’importe quel type de ressource (article, vidéo, etc.) et modérer

Idem que pour les tags, démontré dans le sample Yabe.

6. Gestion d’avatars

Besoin : permettre à l’utilisateur de télécharger un avatar personnel afin de l’affecter à son compte ou utiliser un système décentralisé comme Gravatar.

Non développé, mais la manipulation des images est simple et expliquée dans cet article. Pour Gravatar il y a ce module qui existe déjà.

Spécificités pour les développeurs

1. Intégration des tests unitaires et tests fonctionnels

Besoin : tester toute l’application afin de rajouter des fonctionnalités sans pour autant avoir peur de casser l’existant.

Les tests unitaires et fonctionnels sont accessibles (build-in) via la commande “play test”, et utilisent JUnit. A noter également la possibilité de faire tourner des tests selenium dans votre browser (en mode DEV: mon-site/@test), et affiche en temps réel les echecs et réussites.

2. Héritage dans les templates (template inheritance)

Besoin : définir un template de base que l’on va hériter comme dans un contexte de programmation orientée objet. Ainsi, on affecte à son template des blocks qui peuvent être surchargés dans les templates enfants. Grâce à cette fonctionnalité, les intégrateurs peuvent préparer plusieurs templates de base pour hiérarchiser leurs layouts.

Le moteur de templates par défaut ressemble assez à celui de Django et bénéficie de l’héritage. Il existe d’autre moteurs que vous pouvez découvrir (Mustache, basé sur le moteur Javascript du même nom, ou Scalate en scala).

3. Minification automatique des fichiers statiques (CSS/JS) sur un serveur tiers dédié

Besoin : compresser des fichiers statiques afin de réduire les requêtes HTTP et diminuer le temps de chargement de la page, les télécharger à la volée sur un serveur tiers dédié à cet usage afin de ne pas surcharger le serveur web principal et offrir une réactivité plus importante côté client (performance).

Fonctionnalités offertes par le module greenscript, bien qu’il ne semble pas y avoir la fonctionnalité de l’hébergement sur un serveur tiers, mais seulement la minification.

Courbe d’apprentissage

Dans le contexte d’un switch d’un langage ou framework vers un autre, la courbe d’apprentissage est un critère primordial, et certainement la plus grosse barrière pour une adoption massive de Python ou Ruby.

Points positifs :

Play! est en Java, donc la syntaxe est extrêmement simple et connue, basé sur C++ donc proche de PHP, avec un modèle objet également assez proche. Il est aussi compatible Scala pour ceux qui préfèrent les langages plus fonctionnels. Pour ceux qui ne connaissent pas, Scala est un langage qui est compatible avec la JVM, mais qui ressemble beaucoup plus à Ruby à la fois dans la syntaxe et dans la philosophie.

La philosophie même du framework tend vers un maximum de simplicité (peu de configuration), et de souplesse (tout est facultatif, sauf les controlleurs). Par exemple, tout fonctionne out-of-the box, et le déploiement se fait aussi simplement qu’en PHP, directement avec le serveur Apache Mina intégré à Play.

Play! est full MVC et a été conçu pour faire du vrai Web (REST, XHR, WebSockets…), et très orienté mashups.

Play! utilise par défaut Hibernate et JPA pour la persistance des données. Doctrine utilisant les annotations JPA, si vous connaissez Doctrine: vous connaissez Play!. J’ajouterai que c’est même plus simple puisque tous les setter/getter sont facultatifs.

Play! permet le rechargement à chaud des pages en mode DEV, mais est compilé en mode PROD. Cela a pour conséquences des performances significatives, si l’on compare avec PHP par exemple.

Play! est compatible avec pratiquement toutes les librairies Java existantes. En fait c’est même l’essence du framework qui est principalement utilisé dans un monde Java (déployé dans des banques et assurances), il bénéficie en outre de la solidité de la JVM. J’ajouterais que ce framework est jeune, mais est une compilation de plusieurs librairies très éprouvées (Hibernate, Sienna, Apache Mina…). Play! ne sort pas de nul part. Il est même possible d’exporter votre application dans un war si vous avez un Tomcat (serveur Java classique à papa), mais vous perdrez de l’intérêt du stateless.

Point négatifs :

Le framework est jeune, et la communauté, bien que grandissante, ne vaut pas celle d’un Django ou Symfony, et la documentation, comme les tutoriaux, ne sont pas abondants. De même que les modules ne sont pas très nombreux.

Le langage Java, fait fuir autant qu’il attire. Or Play! utilise Java, est compatible Java, mais n’a rien à voir avec les autres frameworks Java ! Par exemple, l’utilisation d’un IDE est complètement facultative dans Play!. C’est un positionnement qui potentiellement peut plaire au gens de Java, comme au gens pures web, mais aussi le contraire.

L’interrogation concernant l’acquisition de Java par Oracle ? Quel avenir pour Java ?Bien que Play! fonctionne aussi très bien avec OpenJDK.

Les plateformes d’hébergement ne sont pas aussi répandues que celles pour PHP. A noter l’initiative de PlayApps qui permet de déployer ses applications avec la commande “play playapps:deploy”.

Conclusion

En conclusion, Play! est certainement le framework le plus simple d’accès, et d’apprentissage parmi tous ceux que j’ai pu tester, tout en permettant d’aller très loin. Il n’y a pas un gros socle de connaissance à obtenir (ex: connaître des dizaines de lignes commande pour générer une table…), tout se fait assez naturellement. Ceux qui viendront exclusivement de PHP auront principalement à s’approprier le langage plus que le framework (ex: nouveaux types pour les collections, pas seulement des array…).

Enfin, je pense que Play! vaut largement le coup si l’on vient de PHP (Zend, Symfony, Ci…) ou du Java à papa (Spring, JBoss…), mais est-ce le cas si l’on vient de Django ou Rails ? Probablement pas. Les langages et la philosophie font que l’on rentre dans ces frameworks comme l’on rentre en religion, source de nombreux trolls. Mais au delà de cela, il y a des choses dans Play! qui pourront frustrer les développeurs qui viennent de Django ou RoR (ex: CRUD moins puissant que dans Django). Si je ne m’étais pas spécialisé dans le développement FRONT-SIDE, j’hésiterai probablement entre Play! et Django.

Voilà, je vous laisse regarder la vidéo d’intro sur le site de Play! qui montre assez bien l’esprit du framework : Vidéo