BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Sortie de Play 2.3 : Modularisation, Java 8 et WebJars

Sortie de Play 2.3 : Modularisation, Java 8 et WebJars

L'équipe Play de Typesafe a publié la version 2.3 de leur framework web pour Java et Scala. Une des premières choses que les développeurs vont remarquer est l'absence de la commande play qui a été remplacée par Typesafe Activator. Cette dernière prend toujours en charge toutes les options de la commande play originale, mais elle est également livrée avec un support pour les modèles de projet et d'une interface utilisateur basée sur le navigateur comme alternative au shell de Play.

Play 2.3 a également un meilleur support pour les ressources statiques via SBT-web. Ce dernier fournit un framework commun pour les plug-ins de sbt tels que sbt-coffeescript, sbt-less,... etc, et qui gèrent les ressources côté client. Il apporte aussi un support WebJars pour Play. Par exemple, la bibliothèque d'amorçage peut être désormais fournie avec une seule ligne lors de la configuration :

libraryDependencies += "org.webjars" % "bootstrap" % "3.0.0"

La bibliothèque des templates Play a également été déplacée vers son propre projet et a été renommée Twirl, ce qui rend plus aisée l’utilisation d’un moteur de template différent. Une autre bibliothèque qui a été extraite de Play : le client des Web services.

Outre ces réorganisations du framework, Play 2.3 prend en charge également (en plus de Scala 2.10) Scala 2.11 récemment publié, ainsi que des améliorations de l'API pour rendre l'utilisation de Java 8 avec Play plus agréable (la documentation présente des exemples de la syntaxe à la fois en Java 7 et 8).

Anorm, une simple couche d'accès aux données de Play, vient d'améliorer le support pour l'écriture des requêtes avec interpolation des chaînes de caractères :

SQL"SELECT * FROM table WHERE id = $id"

Si vous utilisez Slick de Typesafe, l'intégration de play-slick est ainsi disponible en tant que plug-in.

Travailler avec les Web sockets a toujours été facile avec Play en utilisant les Iteratees. Avec la version 2.3, il est également possible de câbler les websockets directement à un système d'acteurs, de sorte que les messages entrants au socket sont envoyés à un acteur et les réponses peuvent être renvoyées via socket au client (voir la documentation pour des exemples de code).

InfoQ a eu l'occasion de parler à James Roper, Directeur technique de Play, pour en savoir plus sur la nouvelle version et leurs plans d'avenir pour le framework.

InfoQ : Cela pourrait surprendre certains utilisateurs de Play de voir que le shell Play a été remplacé par l’Activator. Quelle est la raison derrière ce changement ?

D'abord, je dois souligner que l'activator est simplement un wrapper autour du shell de SBT avec quelques fonctionnalités supplémentaires intégrées telles que la capacité à démarrer une interface utilisateur et créer un nouveau projet. Le shell Play était également juste un wrapper autour du shell SBT avec quelques fonctionnalités supplémentaires intégrées comme la possibilité de créer un nouveau projet. La commande shell activator est donc un substitut pour la commande shell play. Vous pouvez assimiler play à activator et vous ne verrez pas de différence au vu de l'expérience utilisateur. Lorsque nous avons publié le premier jalon de play 2.3, nous avons constaté que les gens n'étaient pas au courant de cela, et ceci a créé une certaine confusion, ou une surprise, comme vous le dites. Mais dans notre documentation et les notes de version pour la RC1, on espère que maintenant tout est clair.

Activator a été développé comme extension, ou prochaine évolution, de l'environnement de développement productif que les gens aimeraient avec play. Chez Typesafe, nous voulions prendre cet environnement de développement et l'étendre au-delà de Play, afin que d'autres projets, Typesafe ou non, puissent en profiter. Nous voulions également offrir de nouvelles fonctionnalités telles que les modèles de contributions communautaires, dans des tutoriels de contexte, et une série de nouveaux outils de développement liés à play, et c’est ainsi que cet effort a été fait dans l'activator, tandis que l'amélioration du shell play et de la distribution ont été suspendus, avec l'intention de les remplacer finalement par le shell activator et la distribution. Cela a porté ses fruits avec play 2.3.

InfoQ : Anorm est encore le composant d'accès aux données par défaut dans play et non pas Slick de Typesafe. Envisagez-vous d'intégrer le plug-in play-slick plus étroitement dans play ou il restera comme plug-in tiers ?

Il y avait l'intention que dans Play 2.3, on devrait manier play-slick dans le noyau du projet play, il y avait une open pull request pour cela. Cependant, lorsque nous sommes arrivés à réviser et fusionner, nous avons rencontré un problème. Les modèles d'utilisation les plus courants de Slick sous play nécessitent l'utilisation d'une certaine forme d'injection de dépendances. Jusqu'à présent, play a essayé de rester complètement sans opinion sur l'injection de dépendances - en prévoyant des mécanismes d'injection de dépendances lors de la compilation ou à l’exécution, mais ne nécessitant pas leur utilisation, et fournir la documentation qui est neutre vis-a-vis de toute stratégie d'injection de dépendances particulière. Cependant, cela signifierait un débordement, nous ne pouvions pas documenter l'utilisation de Slick sous play sans prendre position dessus ou en imposant une fragrance particulière de l'injection de dépendances.

Nous avons donc décidé qu'il était temps de changer ceci, que nous avions besoin de devenir pragmatique sur l'injection de dépendances, d'offrir un meilleur soutien et l'inclure comme une meilleure pratique dans notre documentation, mais c’était trop tard pour remédier à ceci sous play 2.3. Donc, l'intégration de play-slick comme étant membre de première classe dans play a été mise en attente et retardée jusqu'à 2.4. Le déplacement de la repo play-slick dans l'organisation du playframework est une étape que nous avons entreprise pour assurer aux utilisateurs que nous allons supporter play-slick, et que Typesafe s'est également engagé à fournir un support commercial pour le play-slick.

InfoQ : Beaucoup de changements dans play 2.3 semblent tourner autour de la modularisation du framework. Vous continuerez à faire ceci pour la prochaine version ?

Oui. Je pense que c'est une évolution naturelle de tout le framework lors de sa maturation. D'abord dans le framework, il est plus logique de regrouper tout ensemble, cela va supprimer les désaccords lors de la modification des API, permettant au framework de s’améliorer et proposer rapidement de nouvelles fonctionnalités. Lorsque les APIs deviennent plus stables, les avantages de la modularisation apparaîtront plus clairement, cela signifie que les composants individuels peuvent avoir leurs propres cycles de livraison, ce qui implique que les corrections sur ces modules peuvent être livrées plus rapidement et que d'autres changements qui auraient été autrement impossibles de faire dans un point release vu les règles strictes en matière de compatibilité binaire deviennent prêts à la livraison. Sous play 2.4, nous prévoyons de cibler la modularisation de notre support pour les bibliothèques de bases de données individuelles.

InfoQ : En parlant de la prochaine version, pouvez-vous partager ce que vous avez prévu pour Play 2.4 (ou même 3.0) ?

Nous avons publié une mise à jour de la feuille de route. Notez que la feuille de route n'est pas équivalente aux promesses ! Mais, les grands morceaux pour Play 2.4 devraient inclure la stratégie d'injection de dépendance, le support initial (éventuellement expérimental) pour les flux réactifs et akka-http, ainsi qu'une expérience de déploiement améliorée (unifiée à travers la plate-forme Typesafe).

Avec Play 3.0, nous espérons voir l'éradication de l'état global de play et nous allons certainement voir l'introduction de flux réactifs comme niveau de base de l’API IO de Play. Cela permettra d'ouvrir l’horizon de l’IO asynchrone dans toutes les composantes de play pour les utilisateurs Java, telles que la possibilité d'écrire des analyseurs de body personnalisés en Java, contrairement à ce que nous avions maintenant comme API, limitées pour quelques cas d'utilisation spécifiques.

InfoQ : Merci pour l'interview !

Après le téléchargement du nouveau play 2.3, n'oubliez pas de jeter un oeil sur le Guide de migration pour voir les changements dont vous auriez besoin pour faire fonctionner votre application déjà existante.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT