java web app décorer / inclut des problèmes

Question

Contexte: nous avons un système écrit dans un ancien CMS basé sur Java au cours de la période 2002-2003. Nous voulons continuer à aller de l'avant avec nos nouveaux fichiers, en utilisant tomcat, stripes et sitemesh. La navigation, les mises en page, les & "; Pods &", Les js, les css, etc., ont été retirés de l'ancien système de gestion de contenu et introduits dans quelques-unes de nos nouvelles applications.

Nous avons maintenant besoin d'une sorte de solution pour nous débarrasser de toute la duplication de code en cours. Nos applications fonctionnent actuellement sur la même machine virtuelle, mais cela pourrait changer. Nous avons besoin d'un moyen pour toutes nos instances de tomcat d'accéder à certains éléments communs (et ces éléments peuvent ne pas avoir besoin d'effectuer certaines tâches côté serveur).

Le mieux que nous ayons trouvé jusqu’à présent est de créer un décorateur de sitemesh assez standard, qui utilise c: import pour obtenir ce dont il a besoin, et le branche directement. Cette solution a une surcharge de réseau qui pourrait le ralentir et introduire un point d'échec. Nous avons examiné & Lt;% @ include file = & "; /Something.jsp &"; % > aussi, mais cela ne semble être que le contexte relatif. Nous pourrions utiliser c: import et le diriger vers localhost, ce qui semble être la meilleure solution à ce jour.

Existe-t-il d'autres cadres de gabarit / décoration (carreaux?) qui pourraient simplifier les choses? Que manque-t-il?

Answer 1

Je ne sais pas trop ce que vous essayez de faire ici. Mon interprétation est la suivante: vous souhaitez réutiliser un certain nombre de ressources dans plusieurs applications. Vous ne souhaitez pas que ces fichiers soient dupliqués dans toutes les applications, car il serait difficile de maintenir la cohérence entre les applications.

Si telle est votre question, je vous conseillerais de conserver vos ressources communes dans des fichiers jar. Cela vous donne plusieurs avantages:

1. Vos ressources sont locales - pas de surcharge du réseau
2. Vous avez le contrôle sur les mises à jour des ressources.

Un exemple de n ° 2: Vous conservez vos mises en page communes dans page-layouts-1.x.jar. Vous continuez à créer des versions mineures de la mise en page qui n'affectent pas les applications qui l'utilisent - ce sont des remplacements instantanés. Un jour, vous décidez de repenser complètement vos applications et de publier page-layouts-2.0.jar. Cela nécessite quelques réécritures dans les applications qui l'utilisent. Désormais, si les applications regroupent les présentations de page, au lieu de les conserver dans un chargeur de classes partagé sur le serveur, la migration vers la présentation 2.0 n’est pas une affaire de tout ou rien. Vous pouvez migrer une application à la fois pour utiliser la présentation 2.0, tandis que les autres utilisent toujours la présentation 1.x.

Nous y parvenons avec succès en utilisant JSF et Facelets.

Vous pouvez consulter les Weblets . Je ne sais pas du tout si SiteMesh ou Tiles ont reçu un quelconque soutien direct pour servir des ressources à partir du chemin de classe, mais je suppose que vous pouvez les modifier pour ce faire.

J'espère que ça aide

Answer 2

Nous utilisons Sitemesh depuis des années et mes sentiments sont partagés.

Je préfère de loin écrire des fichiers de balises JSP standard (.tag ou .tagx) pour utiliser applydecorator. Je pense que la balise applydecorator est effectivement obsolète avec l’avènement des fichiers de balises, mais trop d’utilisateurs de Sitemesh ne l’ont pas remarqué.

Presque toute notre utilisation de Sitemesh était de ce type. Nous aurions quelques modèles de page courants, que nos pages JSP qualifieraient explicitement de mise en page. & "Utilisez la mise en page standard, voici le menu de navigation et voici le corps de la page. &"; Les fichiers de balises sont une copie exacte de cette fonctionnalité, mais ils sont normalisés, pris en charge par tout outil Web J2EE et intégrés au conteneur plutôt qu’à une autre dépendance.

Pour vraiment décorer une page, où la page JSP elle-même ne fait aucune référence à Sitemesh, je pense que cela a du sens à un niveau élevé, mais je n'aime toujours pas que la page entière soit à nouveau analysée.

Ce deuxième problème n’est pas la faute de Sitemesh; étant donné l'API Servlet avec laquelle il doit fonctionner, je ne sais pas ce qu'il pourrait faire d'autre. Mais je me demande vraiment si une alternative basée sur le DOM à l'API Servlet basée sur le flux pourrait être utile. En d'autres termes, plutôt que de laisser les servlets écrire leur sortie dans un flux, que se passe-t-il s'ils ajoutent des nœuds à une arborescence? Cela permettrait d’imposer des sorties bien formées et rendrait moins onéreuse d’effectuer des transformations structurelles comme le fait Sitemesh ou d’encoder les sorties dans différents formats tels que XHTML, HTML ou JSON à la volée.