Pourquoi utiliser un moteur de création de modèles? jsp include et jstl vs tiles, freemarker, velocity, sitemesh

Je suis sur le point de choisir une manière d'organiser ma vue (avec spring-mvc, mais cela ne devrait pas avoir beaucoup d'importance)

Il y a 6 options pour autant que je vois (bien qu'elles ne soient pas mutuellement exclusives):

• Carrelage
• Sitemesh
• Freemarker
• Rapidité
• <jsp:include>
• <%@ include file="..">

Les tuiles et Sitemesh peuvent être groupés; tout comme Freemarker et Velocity . La question de savoir laquelle utiliser dans chaque groupe ne fait pas partie de cette discussion, il y a suffisamment de questions et de discussions à ce sujet.

C'est une lecture intéressante , mais je ne peux pas vraiment me convaincre d'utiliser des carreaux.

Ma question est la suivante: que donnent ces cadres qui ne peuvent pas être correctement réalisés avec <@ include file=".."> et JSTL. Points principaux (certains tirés de l'article):

1. Y compris des parties de pages, comme l'en-tête et le pied de page - il n'y a pas de différence entre:

   <%@ include file="header.jsp" %>

   et

   <tiles:insert page="header.jsp" />

2. Définir des paramètres dans l'en-tête - comme le titre, les balises meta, etc. Ceci est très important, en particulier du point de vue SEO. Avec les options de création de modèles, vous pouvez simplement définir un espace réservé que chaque page doit définir. Mais vous pouvez donc en jsp avec JSTL , en utilisant <c:set>(dans la page incluse) et <c:out>(dans la page incluse)

3. Réorganisation de la mise en page - si vous souhaitez déplacer le fil d'Ariane au-dessus du menu ou la zone de connexion au-dessus d'un autre panneau latéral. Si les inclusions de page (avec jsp) ne sont pas bien organisées, vous devrez peut-être changer chaque page dans de tels cas. Mais si votre mise en page n'est pas trop complexe et que vous mettez les éléments communs dans l'en-tête / le pied de page, il n'y a rien à craindre.

4. Couplage entre les composants communs et le contenu spécifique - je ne trouve pas de problème avec cela. Si vous souhaitez réutiliser un fragment, déplacez-le vers une page qui n'inclut aucun en-tête / pied de page et incluez-le là où c'est nécessaire.

5. Efficacité - <%@ include file="file.jsp" %>est plus efficace que toute autre chose, car il est compilé une fois. Toutes les autres options sont analysées / exécutées plusieurs fois.

6. Complexité - toutes les solutions non-jsp nécessitent des fichiers xml supplémentaires, des inclusions supplémentaires, des configurations de pré-processeur, etc. Il s'agit à la fois d'une courbe d'apprentissage et d'introduire davantage de points de défaillance potentiels. En outre, cela rend le support et le changement plus fastidieux - vous devez vérifier un certain nombre de fichiers / configurations afin de comprendre ce qui se passe.

7. Placeholders - Est-ce que Velocity / Freemarker donne quelque chose de plus que JSTL? Dans JSTL, vous mettez un espace réservé et utilisez le modèle (placé dans la portée de la requête ou de la session, par les contrôleurs) pour remplir ces espaces réservés.

Alors, convainquez-moi que je devrais utiliser l'un des frameworks ci-dessus au lieu de / en plus de JSP ordinaire.

Quelques arguments pour Velocity (je n'ai pas utilisé Freemarker):

• Possibilité de réutiliser des modèles en dehors d'un contexte Web, par exemple lors de l'envoi d'e-mails
• La syntaxe du langage de modèle de Velocity est beaucoup plus simple que JSP EL ou les bibliothèques de balises
• Séparation stricte de la logique de vue de tout autre type de logique - aucune option possible pour passer à l'utilisation de balises de scriptlet et faire des choses désagréables dans vos modèles.

Placeholders - Velocity / Freemaker donne-t-il autre chose que JSTL? Dans JSTL, vous mettez un espace réservé et utilisez le modèle (placé dans la portée de la requête ou de la session, par les contrôleurs) pour remplir ces espaces réservés.

Oui, les références sont vraiment au cœur de VTL:

<b>Hello $username!</b>

ou

#if($listFromModel.size() > 1)
    You have many entries!
#end

Efficacité - <%@ include file="file.jsp" %>est plus efficace que toute autre chose, car il est compilé une fois. Toutes les autres options sont analysées / exécutées plusieurs fois.

Pas si sûr que je suis d'accord ou que je comprends ce point. Velocity a une option pour mettre en cache les modèles, ce qui signifie que l'arbre syntaxique abstrait dans lequel ils sont analysés sera mis en cache plutôt que lu à partir du disque à chaque fois. Quoi qu'il en soit (et je n'ai pas de chiffres solides pour cela), Velocity s'est toujours senti rapide pour moi.

Réorganisation de la mise en page - si vous souhaitez déplacer le fil d'Ariane au-dessus du menu ou la zone de connexion au-dessus d'un autre panneau latéral. Si les inclusions de page (avec jsp) ne sont pas bien organisées, vous devrez peut-être changer chaque page dans de tels cas. Mais si votre mise en page n'est pas trop complexe et que vous mettez les éléments communs dans l'en-tête / le pied de page, il n'y a rien à craindre.

La différence est qu'avec une approche JSP, ne réorganiseriez-vous pas cette mise en page dans chaque fichier JSP qui utilise le même en-tête / pied de page? Tiles et SiteMesh vous permettent de spécifier une page de mise en page de base (JSP, modèle Velocity, etc. - les deux sont des frameworks JSP en leur cœur) où vous pouvez spécifier ce que vous voulez, puis déléguer simplement à un fragment / modèle de «contenu» pour le contenu principal . Cela signifie qu'il n'y aurait qu'un seul fichier dans lequel déplacer l'en-tête.

Le choix entre jsp:includeet Tiles / Sitemesh / etc est le choix entre la simplicité et la puissance que les développeurs doivent constamment affronter. Bien sûr, si vous n'avez que quelques fichiers ou si vous ne vous attendez pas à ce que votre mise en page change très souvent, utilisez simplement jstlet jsp:include.

Mais les applications ont un moyen de se développer de manière incrémentielle, et il peut être difficile de justifier "l'arrêt de nouvelles tuiles de développement et de modernisation (ou une autre solution) afin que nous puissions résoudre les problèmes futurs plus facilement" , ce qui est nécessaire si vous n'utilisez pas un solution complexe au début.

Si vous êtes sûr que votre application restera toujours simple, ou si vous pouvez définir un point de repère de la complexité de l'application, après quoi vous intégrerez l'une des solutions les plus complexes, alors je vous recommande de ne pas utiliser de tuiles / etc. Sinon, utilisez-le dès le départ.

Je ne vais pas vous convaincre d'utiliser d'autres technologies. Pour tout ce que je sais, tout le monde devrait s'en tenir à JSP si cela fonctionne pour eux.

Je travaille principalement avec Spring MVC et je trouve que JSP 2+ en combinaison avec SiteMesh correspond parfaitement.

SiteMesh 2/3

Fournissez des décorateurs à appliquer aux vues, principalement comme des travaux d'héritage dans d'autres moteurs de création de modèles. Une telle fonctionnalité est impensable de fonctionner sans de nos jours.

JSP 2+

Les gens qui prétendent que JSP rendra difficile d'éviter le code Java dans les modèles sont faux. Vous ne devriez tout simplement pas le faire et avec cette version, il n'est pas nécessaire de le faire. La version 2 prend en charge les méthodes d'appel utilisant EL, ce qui est un gros avantage par rapport aux versions précédentes.

Avec les balises JSTL, votre code ressemblera toujours à du HTML, donc c'est moins gênant. Spring offre beaucoup de support pour JSP via des taglibs, ce qui est très puissant.

Les taglibs sont également faciles à étendre, donc personnaliser votre propre environnement est un jeu d'enfant.

L'un des meilleurs arguments pour les facelets (pas dans votre liste, mais je vais juste le mentionner) opposé à l'utilisation de JSP est que la compilation est intégrée à l'interpréteur au lieu d'être déléguée au compilateur JSP. Cela signifie que l'une des choses les plus ennuyeuses que j'ai eues avec JSF 1.1 - devoir changer l'attribut id sur une balise JSF environnante lors de l'enregistrement d'un changement pour que le moteur d'exécution découvre le changement - a disparu, donnant la sauvegarde- dans l'éditeur, le cycle de rechargement dans le navigateur revient, ainsi que de bien meilleurs messages d'erreur.

Une bonne technologie de visualisation élimine la plupart et les plus ennuyeuses instructions if / switch / conditionnelles, le simple include ne le fait pas. L'utilisation d'une technologie d'affichage «complexe» aboutit à une application «simple».

Vous n'avez pas fourni d'informations sur certaines de vos applications. Par exemple, je n'utilise pas JSP uniquement pour quelques raisons:

Il est difficile d'éviter d'utiliser du code Java dans les modèles JSP, donc votre concept de rupture de vue pure, et par conséquent, vous aurez des difficultés à maintenir le code à plusieurs endroits en tant que vue et contrôleur.

JSP crée automatiquement un contexte JSP qui établit une session. Je veux peut-être l'éviter, mais si vos applications utilisent toujours la session, cela ne peut pas être un problème pour vous

JSP nécessite une compilation et si le système cible n'a pas de compilateur Java, toute modification mineure nécessitera l'utilisation d'un autre système, puis le redéploiement

Le moteur JSP minimal est d'environ 500k de bytecode plus JSTL, il peut donc ne pas convenir aux systèmes embarqués

Le moteur de modèle peut générer différents types de contenu du même modèle, par exemple la charge utile JSON, la page Web, le corps de l'e-mail, le CSV, etc.

Les programmeurs non Java peuvent avoir des difficultés à travailler avec les modèles JSP, lorsque les personnes non techniques n'ont jamais eu de difficultés à modifier les modèles réguliers.

Je posais la même question il y a longtemps et j'ai fini par écrire mon framework (sûrement basé sur un moteur de modèle) qui était exempt de tous les inconvénients que je voyais dans d'autres solutions. Inutile de dire qu'il s'agit d'environ 100 ko de code d'octet.

Je me rends compte que cela se présente comme une réponse intelligente, mais la vérité est que si vous ne voyez aucun avantage à utiliser le modèle par rapport au code dans votre projet actuel, c'est probablement parce que dans votre projet actuel, il n'y en a pas .

Une partie de cela est une question d'échelle. Vous pourriez penser que les inclusions sont tout aussi puissantes que disons sitemesh, et c'est certainement vrai, au moins pour un petit nombre de pages (je dirais probablement environ 100), mais si vous en avez plusieurs milliers, cela commence à devenir ingérable. (Donc pour eBay, ce n'est pas nécessaire, pour Salesforce c'est probablement le cas)

De plus, comme cela a été mentionné précédemment, le freemarker et la vitesse ne sont pas spécifiques aux servlets. vous pouvez les utiliser pour n'importe quoi (modèles de courrier, documentation hors ligne, etc.). Vous n'avez pas besoin d'un conteneur Servlet pour utiliser Freemarker ou Velocity.

Enfin, votre point 5 n'est que partiellement vrai. Il est compilé à chaque fois qu'il est accédé si ce n'est pas déjà le cas. Cela signifie que chaque fois que vous changez quelque chose, vous devez vous rappeler de supprimer le répertoire "work" de vos conteneurs de servlet, afin qu'il recompile la JSP. Cela n'est pas nécessaire avec un moteur de création de modèles.

TL; Les moteurs DR Templaing ont été écrits pour remédier à certaines lacunes (perçues ou réelles) de JSP + JSTL. Que vous deviez les utiliser ou non dépend entièrement de vos exigences et de l'ampleur de votre projet.