Question

Je viens de tombé sur le nouveau framework web java suivante: Play

http://www.playframework.org/

http://www.playframework.org/documentation/1.0/home

avec une telle liste étonnante de fonctionnalités, je suis assez surpris, je ne l'ai pas entendu parler avant ...

Sons comme le pays le développement web java promis ...

Quelqu'un at-il essayé? une expérience réelle avec elle? pensez-vous qu'il vaut la peine de l'étudier?

Était-ce utile?

La solution

Je suis d'accord avec Jason que le jeu pourrait bien se révéler être mieux que Grails. Avec quatre projets Grails sous ma ceinture (précédée de deux projets de tapisserie et un projet Wicket), je cherche sérieusement au jeu suivant.

L'une des choses que je pensais était cool Grails est que « tout est routinier. » Autrement dit, vous utilisez Groovy pour écrire tout (sauf le HTML et le CSS) - domaines, les contrôleurs, les services, les modèles de page (SGP), des bibliothèques de balises, API Hibernate (Gorm), tests unitaires (GUnit), et créer des scripts ( GANT). Vous pouvez même écrire des scripts shell dans Groovy. Donc, être capable de coder tous les aspects d'une application en utilisant une seule langue à nouveau semblait une simplification qui était attendue depuis longtemps - revenir aux prêter l'oreille jours d'écrire des applications de bureau dans une seule langue comme C ++ ou Delphi. Cependant, je l'ai appris qu'une taille ne convient pas à tous ici.

D'une part, le support IDE pour Groovy est pas grand. IntelliJ fait le meilleur travail, mais avec Groovy étant dynamique, il ne peut aller aussi loin. Les outils de refactoring ne le font pas (ne peut pas) attraper tout, donc vous ne pouvez pas leur faire confiance à 100%. Cela signifie que vous devez être particulièrement vigilant avec les tests unitaires. Là encore, parce que Grails repose tant sur la « magie » dynamique qui se produit lors de l'exécution, les tests unitaires dans Grails doit compter sur une vaste couche de moquerie pour l'imiter, et que la couche de moquerie est décalé. Un troisième problème est que beaucoup de code que l'on appelle le code Groovy que vous écrivez est en fait domaine langue spécifique (DSL). (Pour faire une longue histoire courte, DSLs sont sténographie Groovy, en profitant du fait que dans Groovy et beaucoup de la syntaxe est facultative.) Grails utilise différentes DSLs pour diverses configurations, mappage d'URL, etc., et il est incohérent. Comment vous spécifiez les paramètres log4j, par exemple, ne ressemble en rien la façon dont vous spécifiez les sources de données, et ne ressemble à Java pur sur lequel Groovy est basé. Ainsi, la promesse de « tout Groovy » se désagrège de toute façon.

Cela étant le cas, je vois où l'équipe de lecture vient.

  1. Pour revenir à Java régulier pour les domaines, les contrôleurs, les services et JUnits est logique. Le typage fort signifie que l'IDE peut aider de manière fiable avec INTELI sens, navigation de code, la refactorisation, etc. (et donc vous n'avez pas besoin de payer pour IntelliJ si vous êtes heureux avec Eclipse.) Le fait de devoir écrire du code plus prolixe pour regagner un fort soutien de l'outil semble être une bonne affaire pour moi en ce moment. On verra.

  2. J'aime que je reçois toujours utiliser Groovy dans les modèles de page. Je crains que je finir par mettre plus de code dans les modèles que je ne devrais, cependant.

  3. Je n'ai aucune expérience avec JPA, mais il semble que c'est assez proche de ce que GORM fait pour moi, c'est cool.

  4. Le soutien du CIO printemps dans Grails est complètement transparent tandis que le soutien de jeu semble minime; cependant, je pense que la COI est bien galvaudé et je suis tout à fait prêt à coder manuellement un mappage XML de printemps à l'occasion rare que j'ai vraiment besoin. (Un de mes questions ouvertes est que je suppose que JPA a un support de transaction qui est pourquoi jeu n'a pas besoin de printemps pour que, comme Grails ne, pas?)

  5. Je ne l'ai jamais été un fan de Python, donc je grincé des dents quand je lis que le jeu utilise Python pour ses scripts de compilation. Mais je suis d'accord que les scripts GANT de Grails fonctionnent assez lent. De plus, je trouve que, tout en GANT est une énorme amélioration par rapport à XML ANT, il est toujours difficile d'envelopper votre tête autour des concepts ANT. Les scripts Grails GANT sont assez alambiquée. Alors, je vais à elle avec un esprit ouvert.

  6. Le jeu modèle "module d'application" modèle semble être comme des Grails' "plugin", de sorte que c'est cool.

  7. Je suis très impressionné par la documentation de lecture que je l'ai lu jusqu'à présent. J'ai eu un grand nombre de questions en cours, mais la moitié d'entre eux ont répondu dès le départ.

Je ferai rapport plus tard que je plonge plus profondément dans.

Autres conseils

J'ai essayé Play et je suis impressionné: il fait un excellent travail de fournir un modèle de développement utile qui est beaucoup plus simple que la plupart des cadres. Plus que toute autre chose, la capacité d'exécution en « mode de développement » pour analyser les fichiers .java vaut beaucoup directement: il suffit de recharger la page Web dans le navigateur sans exécuter un script de construction ou en attente d'un redéploiement vaut beaucoup de vitesse de développement. Les messages d'erreur affichés dans le navigateur sont vraiment bons aussi.

Une autre chose qui m'a impressionné était l'esthétique globale: il est peut-être une petite chose que l'application de tutoriel semble vraiment bon (à la fois le code et la conception de page Web), mais cela s'étend à l'ensemble du cadre, l'API ainsi que la documentation.

Après aiguillonner d'un collègue je l'ai regardé, suivi le tutoriel, et suis devenu accro. Obtenir une rétroaction immédiate directement dans votre navigateur signifie que vous ne devez pas utiliser un IDE. J'adore Eclipse, mais avouons-le: après avoir ajouté quelques extras, ce n'est pas aussi stable que d'un simple éditeur de texte. Sur un Mac avec TextMate, vous pouvez même cliquer sur le message d'erreur dans votre navigateur et TextMate apparaît avec le curseur sur cette ligne.

Test de jeu est aussi bien fait, avec une seule touche vous exécutez les tests unitaires, tests fonctionnels et les tests basés sur Sélénium.

Le jeu est passionnant car il est encore petit et simple. Il utilise juste fourmi pour construire et fait en 25 secondes. Contribuer à la belle documentation est une question de modification des fichiers .textile et rechargeant les documents dans toutes les applications de jeu.

Voilà comment je me suis retrouvé dans une quête pour traduire le tutoriel pour utiliser Scala, ajoutant au soutien Scala au besoin pour obtenir le plus agréable possible.

Je l'aime, je l'utilise pour les petits projets et à ce jour il semble parfait pour le travail. Cependant, il y a une chose que je manque beaucoup qui a été laissé sur objectif: couches service / DAO / modèle de séparation! Documentation dit clairement, l'un des objectifs de jeu est d'éviter le « modèle de données anémiques »: http://www.playframework.org/documentation/1.0.1/model

mais dans mon expérience la séparation des couches de service classique / DAO / modèle permet d'économiser des tonnes de temps de développement lorsque l'application doit être refondus! Avec Play vous êtes coincé avec des méthodes statiques qui reposent sur la gestion des transactions spécifiques Play et particularités ...

Cependant, beaucoup de pouces vers le haut pour: la vitesse du développement, le code de la propreté et à la fin ... amusant

Je l'ai utilisé Grails, Tapestry 4/5 et Java / JSP / Spring / Hibernate droit.

Je pense que cela va dans la bonne direction pour la première fois depuis longtemps. Grails est un très bon premier pas, mais jouer! ressemble à quelque chose qui pourrait vraiment avoir les jambes. le soutien Scala vient en 1.1. S'il y a une chance que je peux écrire mes contrôleurs / domaine dans Clojure, je suis vendu;)

Depuis un an et aucun bug visible après 18 petites versions, nous utilisons Play! 1.2.4 dans une production "absences" application intranet pour une école (acteurs:> 100 enseignants,> 700 étudiants, administrativ équipe). côté client a été écrit avec FLEX 4.6 d'Adobe (très belle vue). Les données sont envoyer et recevoir au format AMF3 (module cannelle). Nous utilisons une couche propre dao simple basée sur JPA EclipseLink et MySql pour la DB. L'application est stockée sur un serveur virtuel Linux. Je suis un développeur très fan de jeu pour sa simplicité et son approche très productive.

J'aime le look de jeu, mais ne l'ai pas essayé. De la numérisation à travers la docs une chose qui est ressortie était l'utilisation intensive des méthodes statiques. D'un point de vue de tests unitaires ce qui rend toujours les choses beaucoup plus difficile (je pense simulacres), et un départ de l'approche OO-partout dans le développement typique de Java. Peut-être cela est le point, mais il est juste quelque chose qui m'a fait un peu moins enthousiasmés par ...

Je construis actuellement des applications web au travail en utilisant le framework de jeu qui ne traitement de données massives. Je dois dire que la vitesse que le jeu offre seule est importante et plus que ce que RoR peut fournir. Par ailleurs, le jeu est un cadre basé sur Java et donc multi-Threading peut se faire facilement. Vient ensuite la performance pure que vous obtenez lorsque vous utilisez des modules basés sur Java comme Japid et Netty ainsi de play.It comme une quantité infinie de peaufinage peut être fait pour la performance. A essayer à mon avis.

Je suis en utilisant le jeu dans un petit projet, et semble être exactement ce qu'ils ont dit au sujet. Mais une caractéristique que je pense devrait être présent par défaut dans le cadre: capacité à travailler avec plus d'un point d'émission (par exemple utiliser plus d'un schéma de base de données). Ceci est la fonction ne manque que j'ai trouvé jusqu'à présent.

Cordialement, Uilian.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top