decoración de aplicaciones web java / incluye problemas

Question

Antecedentes: tenemos un sistema que se escribió en un CMS anterior basado en Java durante los días 2002-2003. Queremos seguir avanzando con nuestras nuevas cosas, usando tomcat, stripes y sitemesh. Tenemos navegación, diseños, & "; Pods &"; Js, css, etc., que hemos sacado del antiguo CMS y en algunas de nuestras nuevas aplicaciones para que tengamos una apariencia y sensación consistentes.

Ahora necesitamos algún tipo de solución para deshacernos de toda la duplicación de código. Nuestras aplicaciones se ejecutan en la misma máquina virtual en este momento, pero eso podría cambiar. Necesitamos una forma para que todas nuestras instancias de tomcat accedan a algunos elementos comunes (y esos elementos pueden / no necesitar hacer algunas cosas del lado del servidor).

Lo mejor que hemos encontrado hasta ahora es hacer un decorador de malla de sitio bastante estándar, que use c: import para obtener lo que necesita, y lo conecta directamente. Esta solución tiene un poco de sobrecarga de red que podría empantanarlo y Introducir un punto de falla. Hemos examinado & Lt;% @ include file = & Quot; /something.jsp & Quot; % > también, pero eso parece ser solo relativo al contexto. Podríamos usar c: import y apuntarlo a localhost, que parece ser la mejor solución hasta ahora.

¿Existen otros marcos de plantillas / decoraciones (Tiles?) que podrían simplificar esto? ¿Qué nos estamos perdiendo?

Answer 1

No estoy muy seguro de lo que estás tratando de hacer aquí. Mi interpretación es la siguiente: tiene una cantidad de recursos que desea reutilizar en varias aplicaciones. No desea duplicar estos archivos en todas las aplicaciones, ya que dificultaría mantener la coherencia entre las aplicaciones.

Si esta es su pregunta, le sugiero que mantenga sus recursos comunes en archivos jar. Esto le brinda varias ventajas:

1. Sus recursos son locales, sin sobrecarga de red
2. Usted tiene control sobre las actualizaciones de los recursos.

Un ejemplo de nr 2: mantiene sus diseños de página comunes en page-layouts-1.x.jar. Continúa haciendo lanzamientos menores de los diseños de página que no afectan a las aplicaciones que lo usan, son reemplazos directos. Un día, decide rediseñar sus aplicaciones por completo y lanzar page-layouts-2.0.jar. Esto requiere algunas reescrituras en las aplicaciones que lo usan. Ahora, si las aplicaciones agrupan los diseños de página, en lugar de mantenerlos en un cargador de clases compartido en el servidor, la migración al diseño 2.0 no es un asunto de todo o nada. Puede migrar una aplicación a la vez para usar el diseño 2.0, mientras que las otras aún usan el diseño 1.x.

Estamos haciendo esto con mucho éxito, utilizando JSF y Facelets.

Es posible que desee echar un vistazo a Weblets . No tengo idea de si SiteMesh o Tiles obtuvieron soporte directo para servir recursos desde la ruta de clase, pero supongo que puede modificarlos para hacer esto.

Espero que ayude

Answer 2

Hemos usado Sitemesh durante años y tengo sentimientos encontrados al respecto.

Prefiero escribir archivos de etiquetas JSP estándar (.tag o .tagx) al uso de applydecorator. Creo que la etiqueta applydecorator quedó obsoleta con el advenimiento de los archivos de etiquetas, pero muchos usuarios de Sitemesh no se dieron cuenta.

Casi todo nuestro uso de Sitemesh fue de este tipo. Tendríamos algunas plantillas de página comunes, a las que nuestras páginas JSP se referirían explícitamente como un diseño. " Use el diseño estándar, aquí está el menú de navegación y aquí está el cuerpo de la página. " Los archivos de etiquetas son un duplicado exacto de esta funcionalidad, pero están estandarizados, son compatibles con cualquier herramienta web J2EE y están integrados en el contenedor en lugar de otra dependencia.

Para decorar verdaderamente una página, donde la página JSP en sí misma no hace referencia alguna a Sitemesh, creo que tiene sentido a un alto nivel, pero todavía no me gusta que toda la página se analice de nuevo.

Este segundo problema no es realmente culpa de Sitemesh; dada la API de Servlet con la que tiene que trabajar, no sé qué más podría hacer. Pero me hace preguntarme si una alternativa basada en DOM a la API de Servlet basada en secuencias podría ser valiosa. En otras palabras, en lugar de que los servlets escriban su salida en una secuencia, ¿qué pasa si agregan nodos a un árbol? Esto exigiría resultados bien formados y haría más barato realizar transformaciones estructurales como lo hace Sitemesh, o codificar resultados a diferentes formatos como XHTML, HTML o JSON sobre la marcha.