Pourquoi utiliser un moteur de templating ? jsp include et jstl vs tiles, freemarker, velocity, sitemesh

Question

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

D'après ce que je vois, il y a 6 options (bien qu'elles ne soient pas mutuellement exclusives) :

• tuiles
• sitemesh
• freemarker
• vélocité
• <jsp:include>
• <%@ include file="..">

Les tuiles et sitemesh peuvent être regroupées, tout comme freemarker et velocity. Le choix du groupe à utiliser n'est pas le sujet de cette discussion, il y a suffisamment de questions et de discussions à ce sujet.

C'est une lecture intéressante mais je n'arrive pas à me convaincre d'utiliser des carreaux.

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

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

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

   y

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

2. Définition de paramètres dans l'en-tête - comme le titre, les balises méta, etc. C'est très important, surtout du point de vue du référencement. Avec les options de templating, vous pouvez simplement définir un placeholder que chaque page doit définir. Mais vous pouvez aussi le faire en jsp avec JSTL, en utilisant <c:set> (dans la page d'inclusion) 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 boîte de connexion au-dessus d'un autre panneau latéral. Si les inclusions de pages (avec jsp) ne sont pas bien organisées, vous devrez peut-être modifier chaque page dans ce cas. Mais si votre mise en page n'est pas trop complexe et que vous placez les éléments les plus courants dans l'en-tête et le pied de page, il n'y a pas lieu de s'inquiéter.

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

5. Efficacité - <%@ include file="file.jsp" %> est plus efficace que tout le reste, car il est compilé une seule 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 includes supplémentaires, des configurations de pré-processeurs, etc. Cela représente à la fois une courbe d'apprentissage et l'introduction de plus de points de défaillance potentiels. En outre, cela rend le support et les modifications plus fastidieux - vous devez vérifier un certain nombre de fichiers/configurations afin de comprendre ce qui se passe.

7. Placeholders - la vélocité/freemarker donnent-ils quelque chose de plus que JSTL ? Dans JSTL, vous mettez des caractères de remplissage et vous utilisez le modèle (placé dans la portée de la requête ou de la session, par les contrôleurs) pour remplir ces caractères de remplissage.

Alors, convainquez-moi que je devrais utiliser l'un des frameworks ci-dessus à la place ou en plus du simple JSP.

Answer 1

Quelques arguments en faveur de Velocity (je n'ai pas utilisé Freemarker) :

• Possibilité de réutiliser les modèles en dehors d'un contexte web, par exemple pour l'envoi de courriels
• La syntaxe du langage de template de Velocity est la suivante loin plus simple que les bibliothèques JSP EL ou de balises
• Séparation stricte de la logique d'affichage 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 donnent-ils quelque chose de plus que JSTL ? Dans JSTL, vous mettez des caractères de remplissage et vous utilisez le modèle (placé dans la portée de la demande ou de la session, par les contrôleurs) pour remplir ces caractères de remplissage.

Oui, références sont vraiment le cœur du VTL :

<b>Hello $username!</b>

ou

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

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

Je ne suis pas sûr d'être d'accord ou de comprendre 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 sur le disque à chaque fois. D'une manière ou d'une autre (et je n'ai pas de chiffres solides à ce sujet), Velocity a toujours donné l'impression que 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 boîte de connexion au-dessus d'un autre panneau latéral. Si les inclusions de pages (avec jsp) ne sont pas bien organisées, vous devrez peut-être modifier chaque page dans ce cas. Mais si votre mise en page n'est pas trop complexe et que vous placez les éléments les plus courants dans l'en-tête et le pied de page, il n'y a pas lieu de s'inquiéter.

La différence est qu'avec une approche JSP, n'auriez-vous pas à réorganiser 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, template Velocity, etc - les deux sont des frameworks JSP à la base) où vous pouvez spécifier ce que vous voulez et ensuite juste déléguer à un fragment/template "content" pour le contenu principal. Cela signifie qu'il n'y aurait qu'un seul fichier pour déplacer l'en-tête.

Answer 2

Le choix entre jsp:include et tiles/sitemesh/etc est le choix entre simplicité et puissance auquel les développeurs sont confrontés en permanence. 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, alors utilisez simplement jstl et jsp:include.

Mais les applications ont tendance à se développer de manière incrémentielle, et il peut être difficile de justifier l'arrêt des nouveaux développements et la mise en place de tuiles (ou d'une autre solution) afin de pouvoir résoudre plus facilement les problèmes futurs si vous ne mettez pas en place une solution plus complexe dès le départ.

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

Answer 3

Jetez un coup d'œil à cet article : Des astuces JSP pour faciliter le templating ? . Il est donc très facile de faire du templating sans avoir recours à d'autres frameworks.

Answer 4

Je ne vais pas vous convaincre d'utiliser d'autres technologies. Pour autant que je sache, 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 le match parfait.

SiteMesh 2/3

Fournir des décorateurs à appliquer aux vues, de la même manière que l'héritage fonctionne dans d'autres moteurs de création de modèles. Il est impensable de travailler sans une telle fonctionnalité de nos jours.

JSP 2+.

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

Avec JSTL votre code ressemblera toujours à du HTML, ce qui est moins gênant. Spring offre un support important pour les JSP à travers les taglibs, ce qui est très puissant.

Les taglibs sont également faciles à étendre, de sorte que la personnalisation de votre propre environnement est un jeu d'enfant.

Answer 5

L'un des meilleurs arguments en faveur des facelets (qui ne figure pas dans votre liste, mais je vais le mentionner) par rapport à 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'avais avec JSF 1.1 - devoir changer l'attribut id d'une balise JSF environnante lors de la sauvegarde d'un changement pour que le moteur d'exécution découvre le changement - a disparu, ce qui a rendu le cycle de sauvegarde dans l'éditeur et de rechargement dans le navigateur, avec des messages d'erreur bien meilleurs.