Pourquoi jouer! framework a choisi groovy pour le moteur de modèle

Oui, il y a JAppid. Qui est beaucoup, beaucoup plus rapide.

http://www.playframework.org/modules/japid

JSP n'est pas réalisable car chaque JSP compile avec un servlet et l'API de servlet fournit des éléments comme la session latérale du serveur qui ne sont pas compatibles avec le paradigme reposant. Nous ne voulons pas revenir à l'âges sombres des sessions latérales du serveur mal évolutif, retour des problèmes de boutonnage dans le navigateur, les republies, etc.

Les modèles jaillides sont intéressants, mais ils ne sont pas soutenus par une grande communauté et n'existaient peut-être pas au moment de la création de temps (je ne sais pas avec certitude). J'ai essayé Japeid comme un remplacement des modèles groovy dans ma propre application et j'ai découvert dans un test JMeter que la prestation ne serait que marginale, 10% à max. 25% d'amélioration.

Je suppose qu'à la fin, tout dépend de vos exigences d'évolutivité et de la structure de vos pages. J'ai choisi le cas d'utilisation de 90% de mon application et j'ai fait le test. Pour moi, la petite amélioration ne justifie pas les coûts supplémentaires de la dépendance supplémentaire (j'aime garder les dépendances au minimum pour la maintenabilité).

Les modèles groovy ne sont pas mauvais ni lents en général. Utilisez des variables dactylographiées dans la mesure du possible (au lieu de «def»), même dans des fermetures! Gardez des valeurs des propriétés accédées dans les variables locales. Faire des résultats raisonnables à la pagination. Ensuite, gardez vos doigts croisés que GSP pourrait être capable de courir sur Groovy ++ à l'avenir et vous avez terminé;)

Pour moi, la question ne serait pas la raison pour laquelle ils ont utilisé Groovy sur les points de vue. C'est-à-dire parce que je préfère me manquer beaucoup dans la couche de contrôleur. Groovy rendrait la codage du comportement du contrôleur beaucoup plus facile à imho.

Tout d'abord, JSP n'était pas une option de jeu valide car elle n'a pas choisi de ne pas descendre la route Java EE (que JSP fait partie de). Au lieu de cela, le jeu a choisi d'utiliser Groovy en tant que moteur de modèles intuitif, simple mais puissant.

Cependant, l'une des plus grandes fonctionnalités de la lecture est qu'il s'agit d'un système enfichable, ce qui signifie que de nombreuses parties du système de base peuvent simplement être remplacées. Cela inclut le moteur de modèle et il y a un couple déjà disponible.

Le plus populaire est JAppid. Il prétend être 2-20 fois plus rapidement que le moteur de modèles standard et existe depuis un moment. Pour plus d'informations, voir ici http://www.playframework.org/modules/japid . < / p>

Une deuxième option est Cambridge, bien que cela ne soit sorti que pendant un peu de temps, mais est raisonnablement actif dans les cartes de message (voir https://groups.google.com/forum/?hl=fr#!SearchIn/play -Framework / Cambridge / Play-Framework / IXSEI-9BGQ8 / X-3PF5TWAKAJ ).

J'ai tendance à coller à Groovy, comme j'aime la façon dont cela fonctionne et que cela ne l'a pas trouvé était trop mauvais en termes de performance, mais chaque application est individuelle, de sorte que vos propres tests de performance devraient vous amener dans votre propre chemin.

Je suis totalement d'accord avec le choix de la facilité sur la vitesse des concepteurs de jeu de jeux faits ici. Je suppose que si le modèle commence à entrer en termes de performances, vous pouvez (et devriez!) Mesurer les bits lents et les refacturer dans des étiquettes rapides dans la mesure du possible. Avec cela, vous économiserez probablement 80% de la CPU en déplaçant 20% dans des étiquettes rapides, vous laissant une flexibilité et une vitesse adéquate.

Cela dit, j'attends une expérience avec impatience, je prévois de voir à quel point les nouveaux modèles Scala (lâchement «empruntés» de Razor.net - Syntaxe Clean Netty) fonctionnent avec des contrôleurs / modèles Java. Le backend Scala n'est pas encore là en termes de facilité de comparaison, mais le langage des modèles bascule certainement.

Je suis peut-être en retard à la fête en 2016. Jouer 2 est sorti et le JDK (sans oublier le matériel) considérablement amélioré. Je n'utilise pas de jeu de jeu ni de printemps, car ma plate-forme n'en a pas besoin - juste une génération de textes / HTML pure d'exécution à partir de modèles.

Premièrement, lorsque vous parlez de modèles groovy, il y a plus d'un. J'utilise l'original Groovy SimpleTemplateEngine pour tout ce qui concerne les courriels à des pages Web riches, que la plupart des gens favorisent aujourd'hui le "avancé" MarkupTemplategine avec sa syntaxe non-HTML Builder. Je ne suis pas allé cette route à cause de la prise en charge de l'IDE (E.G.Tellij) pour les fichiers HTML JSPISH avec JavaScript - attraper des balises, des accolades, etc. En outre, comment allez-vous inclure JavaScript dans le modèle de style «Builder» BRACE BRACE BRACE BRACE?

Lequel vous avez choisi, le plafond SimpleTempline et Markuptemplate accompagnent statiquement leurs modèles, même si le Doc Groovy ne le mentionne que pour ce dernier. Pourquoi ne générerait-il pas de classe pour le premier? Je ne les ai pas comparables les uns contre les autres, mais je m'attendrais à ce que SimpleTemplategine soit plus rapide, car c'est ... Eh bien, plus simple - ne traduisez pas la syntaxe en concaténations à chaîne avec les IFS et les boucles entre les deux.

Et c'est vraiment très rapide. Je craignais d'invoquer dans une boucle. Ne fait aucune différence. Il n'y a pas de frais générale, car le modèle est compilé une fois.

J'utilise plusieurs petits modèles responsables de la génération d'un balisage de contrôle de formulaire individuel (HTML + JS) pour générer une forme composite, inclus dans un conteneur de niveau supérieur, inclus dans un autre conteneur, etc. jusqu'à ce que la page complète soit formée. Décomposer votre point de vue comme ça le fait, comme vous l'avez déjà deviné, modulaire, encapsulé et "orienté objet" - composé de nombreux composants de MVC individuels se développant les uns sur les autres. En quelque sorte comme de bonnes anciennes tags JSP personnalisés, évalué uniquement à l'exécution et compatible avec les technologies telles que la chaussure à ressort, si vous ne pouvez pas résister à la reprise des créances à la mode - Shatosting Stuff, comme ça.

Un formulaire de test avec un 100 champs (tous les contrôles «intelligents« intelligents »complexes avec la gestion et le comportement de l'état encapsulé) dans 150 ms la première fois, puis 10-14ms par la suite. Dans un débogueur de l'IDE sur ma mémoire-meurtronnée 4Y.o. carnet. J'ai également vérifié qu'il est en sécurité, car Groovy ne l'a jamais mentionné explicitement. Pourquoi ne serait-ce pas, s'il est compilé dans une classe groovy apatride comme une autre? CréeTemplate d'appel () Une fois, stockez le modèle quelque part et utilisez-le (template d'appel.make.make.make ()) dans votre servlet ou un autre contexte simultané. De toute évidence, je n'aurai jamais une forme de 100 champs dans une application réelle. Quiconque a besoin de reconsidérer son UX.

La performance est assez adéquate. J'accepterais même une seconde pour rendre une page de 100 champs. Pensez-y, vous n'avez pas besoin de performances ultimes de suivi nanotrading ou de missiles nucléaires dans une application Web. Si vous le faites, choisissez Jamon: http://www.jamon.org/overview.html , qui génère une classe Java, vous écririez normalement pour concaténer des chaînes. Je ne l'ai pas testé, car je n'aime pas les étapes de compilation supplémentaires (exécutées automatiquement par Maven, mais toujours). Compilé Groovy Bytecode est assez bon pour moi - comparé au Java compilé, oui, fortement typé. La différence serait marginale à moins que vous fassiez quelque chose de complexe, que vous ne devriez pas dans un modèle (voir ci-dessous). Jouer avec des variables groovy typées vs. Def comme suggéré dans ce fil, m'a sauvegardé quelques millisecondes sur cette course à 100 modèles.

Les modèles ne doivent pas avoir beaucoup de logique procédurale (variables internes, ifs et boucles) de toute façon - c'est la responsabilité du contrôleur, pas de la vue. Cela dit, les ifs et les boucles sont un must pour un moteur de gabarit. Pourquoi utiliserait-on un guidon / moustache, s'il / elle peut simplement appeler string.replace ()?

Le reste des moteurs de modèle est également hors de propos. Aucune concaténation à cordes (par exemple, VELOCITY ou FREEMARKER) ou interprété de la technologie JS-Basé (par exemple Jade) battrait toujours la performance d'approche la plus directe de Jamon. Et étant un programmeur Java, vous souhaitez utiliser votre langue / syntaxe préférée: soit directement (Jamon), soit 90% près de Java, Groovy est (étant un java interprété de concision centré sur script). Je ne commenterais pas Scala - la question de la préférence. Autre que sa syntaxe prétendument "concise" (moins et moins pertinente avec Java 8+) vient à un prix. Et seulement compte pour des boucles complexes. Vous ne voulez pas écrire votre application entière dans un modèle, comme je l'ai déjà dit. Quelques boucles et jusqu'à dix, si des déclarations max.

Et, comme tout le monde mentionné, la syntaxe intuitive et la facilité d'utilisation est la clé. Ils réduisent considérablement le nombre de bugs. Un bon serveur (supplémentaire) coûte 1 000 $, tandis que les salaires de développeurs - pour fixer tous les bogues stemming forment la complexité de l'optimisation de la performance marginale, sont 100 fois supérieures.