Pourquoi devrais-je utiliser un moteur de modèles? jsp include et jstl vs tuiles, freemarker, velocity, sitemesh
Je suis sur le point de choisir la façon d'organiser ma vue (avec Spring-MVC, mais cela ne devrait pas beaucoup d'importance)
Il y a 6 options à ma connaissance (bien qu'elles ne s'excluent pas mutuellement):
- Tuiles
- Sitemesh
- Freemarker
- Velocity
<jsp:include><%@ include file="..">
Tuiles et Sitemesh peuvent être regroupés; ainsi Freemarker et Velocity. Lequel de chaque groupe utiliser n'est pas une question de cette discussion, il y a suffisamment de questions et de discussions à ce sujet.
Ceci est une lecture intéressante , mais ne peut pas vraiment me convaincre d'utiliser des tuiles.
Ma question est - que donnent ces frameworks qui ne peuvent pas être correctement utilisés<@ include file=".."> et JSTL. Points principaux (certains tirés de l'article):
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" />Définir des paramètres dans l'en-tête - comme le titre, les balises META, etc. Ceci est très important, surtout du point de vue SEO. Avec les options de modèle, 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)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 page (avec jsp) ne sont pas bien organisées, vous devrez peut-être modifier 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/pied de page, il n'y a rien à craindre.
Couplage entre les composants communs et le contenu spécifique - Je ne trouve aucun problème avec cela. Si vous souhaitez réutiliser un fragment, déplacez-le vers une page qui ne comprend aucun en-tête/pied de page et incluez-le là où vous en avez besoin.
Efficacité -
<%@ include file="file.jsp" %>est plus efficace qu'autre chose, car il est compilé une fois. Toutes les autres options sont analysées/exécutées plusieurs fois.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'un potentiel accru points d'échec. 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.
Espaces réservés - est-ce que velocity/freemarker donne autre chose que JSTL? Dans JSTL, vous placez un espace réservé et utilisez le modèle (placé dans la portée de la demande ou de la session par les contrôleurs) pour remplir ces espaces réservés.
Donc, convainquez-moi que je devrais utiliser l'un des cadres ci-dessus au lieu de/en plus de la simple JSP.
Quelques arguments pour Velocity (je n'ai pas utilisé Freemarker):
- Possibilité de réutiliser des modèles en dehors d'un contexte Web, comme dans l'envoi d'e-mails
- La syntaxe du langage de modèle de Velocity est loin plus simple que JSP EL ou les bibliothèques de balises
- Séparation stricte de la logique de vue de toute autre sorte de logique - aucune option possible pour utiliser des balises de scriptlet et faire des choses désagréables dans vos modèles.
Espaces réservés - Velocity/Freemaker donne-t-il autre chose que JSTL? Dans JSTL, vous placez un espace réservé et utilisez le modèle (placé dans la portée de la demande ou de la session par les contrôleurs) pour remplir ces espaces réservés.
Oui, références sont vraiment le 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 qu'autre chose, car il est compilé une 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 de syntaxe abstraite dans lequel ils sont analysés sera mis en cache plutôt que lu sur le disque à chaque fois. Quoi qu'il en soit (et je n'ai pas de chiffres solides pour cela), Velocity a toujours juste ressenti 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 page (avec jsp) ne sont pas bien organisées, vous devrez peut-être modifier 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/pied de page, il n'y a rien à craindre.
La différence est qu'avec une approche JSP, ne réorganiseriez-vous pas cette disposition 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 cadres JSP en leur cœur) où vous pouvez spécifier ce que vous voulez et ensuite simplement déléguer à 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:include et Tiles/Sitemesh/etc est le choix entre simplicité et puissance auquel les développeurs sont confrontés tout le temps. 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 jstl et jsp:include.
Mais les applications ont un moyen de croître progressivement, et il peut être difficile de justifier le "arrêter de nouveaux développements et moderniser les tuiles (ou une autre solution) afin que nous puissions résoudre plus facilement les problèmes futurs", ce qui est requis si vous n'utilisez pas une solution complexe au début.
Si vous êtes sûr que votre application restera toujours simple, ou si vous pouvez définir une référence de complexité d'application après laquelle vous intégrerez l'une des solutions les plus complexes, je vous déconseille d'utiliser des 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 simplement s'en tenir à JSP si cela fonctionne pour eux.
Je travaille principalement avec Spring MVC et je trouve JSP 2+ en combinaison avec SiteMesh le match parfait.
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 pour fonctionner sans de nos jours.
JSP 2+
Les gens prétendant que JSP rendra difficile d'éviter Java dans les modèles est faux. Vous ne devriez pas le faire et avec cette version ce n'est pas nécessaire de le faire. La version 2 prend en charge les méthodes d'appel en 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 contient beaucoup de support pour JSP via des balises taglibs qui sont très puissantes.
Les balises sont également faciles à étendre, donc la personnalisation de votre propre environnement est un jeu d'enfant.
L'un des meilleurs arguments pour des facettes (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'une modification afin que le moteur d'exécution découvre la modification - est partie, donnant la sauvegarde - dans l'éditeur, recharger dans le navigateur, revenir en arrière, avec de bien meilleurs messages d'erreur.
Une bonne technologie de vue élimine les instructions if/switch/conditionnelles les plus et les plus ennuyeuses, ce qui n'est pas le cas avec le simple include. L'utilisation d'une technologie de vue "complexe" se traduit par une application "simple".
Vous n'avez pas fourni d'informations sur des applications spécifiques. Par exemple, je n'utilise pas JSP juste pour quelques raisons:
Il est difficile d'éviter d'utiliser 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 le contexte JSP qui établit une session. Je veux peut-être l'éviter, mais si vos applications utilisent toujours la session, cela ne peut pas vous poser de problème
JSP nécessite une compilation et si le système cible n'a pas Java, tout ajustement mineur nécessitera d'utiliser un autre système, puis de le redéployer
Le moteur JSP minimal est d'environ 500 Ko 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.
Non Java peut avoir des difficultés à travailler avec des modèles JSP, lorsque des personnes non techniques n'ont jamais eu de difficultés à modifier des modèles standard.
Je posais la même question il y a longtemps et j'ai terminé en écrivant mon framework (basé sur un moteur de modèle) qui était exempt de tous les inconvénients que j'ai vus 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 sur du code dans votre projet actuel, c'est probablement parce que dans votre projet actuel, il n'y en a pas .
Il s'agit en partie 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)
En outre, comme cela a été mentionné précédemment, le freemarker et la vélocité ne sont pas spécifiques au servlet. vous pouvez les utiliser pour n'importe quoi (modèles de courrier, documentation hors ligne, etc.). Vous n'avez pas besoin d'un conteneur de servlets pour utiliser la marque libre ou la vélocité.
Enfin, votre point 5 n'est que partiellement vrai. Il est compilé à chaque fois qu'il est consulté s'il ne l'a pas déjà été. Cela signifie que chaque fois que vous changez quelque chose, vous devez vous rappeler de supprimer le répertoire "work" de vos conteneurs de servlets, afin qu'il recompile le JSP. Cela n'est pas nécessaire avec un moteur de modèles.
TL; DR Les moteurs de création de modèles ont été écrits pour corriger certaines lacunes (perçues ou réelles) de JSP + JSTL. Que vous les utilisiez ou non dépend entièrement de vos besoins et de l'échelle de votre projet.