¿Por qué debería usar un motor de plantillas? jsp include y jstl vs tiles, freemarker, velocity, sitemesh

Estoy a punto de elegir la forma de organizar mi vista (con spring-mvc, pero eso no debería importar mucho)

Por lo que veo, hay 6 opciones (aunque no son mutuamente excluyentes):

• Losas
• Sitemesh
• Freemarker
• Velocidad
• <jsp:include>
• <%@ include file="..">

Los mosaicos y Sitemesh se pueden agrupar; también Freemarker y Velocity . Cuál dentro de cada grupo usar no es un tema de esta discusión, hay suficientes preguntas y discusiones al respecto.

Esta es una lectura interesante , pero no puedo convencerme de usar mosaicos.

Mi pregunta es: ¿qué dan estos marcos que no se pueden hacer correctamente con <@ include file=".."> y JSTL? Puntos principales (algunos extraídos del artículo):

1. Incluyendo partes de las páginas, como el encabezado y el pie de página , no hay diferencia entre:

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

   y

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

2. Definir parámetros en el encabezado , como título, metaetiquetas, etc. Esto es muy importante, especialmente desde el punto de vista del SEO. Con las opciones de plantillas, simplemente puede definir un marcador de posición que debe definir cada página. Pero para que pueda en jsp con JSTL , usando <c:set>(en la página incluida) y <c:out>(en la página incluida)

3. Reorganización del diseño : si desea mover la ruta de navegación sobre el menú o el cuadro de inicio de sesión sobre otro panel lateral. Si las inclusiones de páginas (con jsp) no están bien organizadas, es posible que deba cambiar todas las páginas en tales casos. Pero si su diseño no es demasiado complejo y coloca las cosas comunes en el encabezado / pie de página, no hay nada de qué preocuparse.

4. Acoplamiento entre los componentes comunes y el contenido específico : no encuentro ningún problema con esto. Si desea reutilizar algún fragmento, muévalo a una página que no incluya ningún encabezado / pie de página e inclúyalo donde sea necesario.

5. Eficiencia : <%@ include file="file.jsp" %>es más eficiente que cualquier otra cosa, porque se compila una vez. Todas las demás opciones se analizan / ejecutan muchas veces.

6. Complejidad : todas las soluciones que no son jsp requieren archivos xml adicionales, inclusiones adicionales, configuraciones de preprocesador, etc. Esto es tanto una curva de aprendizaje como la introducción de más puntos potenciales de falla. Además, hace que el soporte y los cambios sean más tediosos: debe verificar una serie de archivos / configuraciones para comprender qué está sucediendo.

7. Marcadores de posición : ¿la velocidad / marcador libre dan algo más que JSTL? En JSTL, coloca un marcador de posición y usa el modelo (colocado en el alcance de la solicitud o de la sesión, por los controladores) para llenar estos marcadores de posición.

Entonces, convénceme de que debería usar cualquiera de los marcos anteriores en lugar de / además de JSP simple.

Algunos argumentos a favor de Velocity (no he usado Freemarker):

• Posibilidad de reutilizar plantillas fuera de un contexto web, como al enviar correos electrónicos.
• La sintaxis del lenguaje de plantillas de Velocity es mucho más simple que JSP EL o las bibliotecas de etiquetas
• Separación estricta de la lógica de vista de cualquier otro tipo de lógica: no hay opción posible para utilizar etiquetas scriptlet y hacer cosas desagradables en sus plantillas.

Marcadores de posición: ¿la velocidad / freemaker ofrece algo más que JSTL? En JSTL, coloca un marcador de posición y usa el modelo (colocado en el alcance de la solicitud o de la sesión, por los controladores) para llenar estos marcadores de posición.

Sí, las referencias son realmente el núcleo de VTL:

<b>Hello $username!</b>

o

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

Eficiencia: <%@ include file="file.jsp" %>es más eficiente que cualquier otra cosa, porque se compila una vez. Todas las demás opciones se analizan / ejecutan muchas veces.

No estoy tan seguro de estar de acuerdo o de entender este punto. Velocity tiene una opción para almacenar en caché las plantillas, lo que significa que el árbol de sintaxis abstracta en el que se analizan se almacenará en caché en lugar de leerse desde el disco cada vez. De cualquier manera (y no tengo números sólidos para esto), Velocity siempre se ha sentido rápido para mí.

Reorganización del diseño: si desea mover la ruta de navegación sobre el menú o el cuadro de inicio de sesión sobre otro panel lateral. Si las inclusiones de páginas (con jsp) no están bien organizadas, es posible que deba cambiar todas las páginas en tales casos. Pero si su diseño no es demasiado complejo y coloca las cosas comunes en el encabezado / pie de página, no hay nada de qué preocuparse.

La diferencia es que, con un enfoque JSP, ¿no reorganizaría este diseño en cada archivo JSP que use el mismo encabezado / pie de página? Tiles y SiteMesh le permiten especificar una página de diseño base (JSP, plantilla Velocity, etc., ambos son marcos JSP en su corazón) donde puede especificar lo que quiera y luego simplemente delegar en un fragmento / plantilla de "contenido" para el contenido principal . Esto significa que solo habría un archivo para mover el encabezado.

La elección entre jsp:includey Tiles / Sitemesh / etc es la elección entre la simplicidad y el poder que los desarrolladores enfrentan todo el tiempo. Claro, si solo tiene unos pocos archivos o no espera que su diseño cambie con mucha frecuencia, simplemente use jstly jsp:include.

Pero las aplicaciones tienen una forma de crecer de forma incremental, y puede ser difícil justificar "detener el nuevo desarrollo y modernizar los mosaicos (o alguna otra solución) para que podamos solucionar problemas futuros con mayor facilidad" , lo cual es necesario si no usa un solución compleja al principio.

Si está seguro de que su aplicación siempre será simple, o puede establecer algún punto de referencia de la complejidad de la aplicación, después de lo cual integrará una de las soluciones más complejas, le recomiendo no usar mosaicos / etc. De lo contrario, utilícelo desde el principio.

No te voy a convencer de que uses otras tecnologías. Por lo que sé, todo el mundo debería ceñirse a JSP si les funciona.

Trabajo principalmente con Spring MVC y encuentro que JSP 2+ en combinación con SiteMesh es la combinación perfecta.

SiteMesh 2/3

Proporcione decoradores para que se apliquen a las vistas, principalmente como obras de herencia en otros motores de plantillas. Es impensable trabajar sin esta característica hoy en día.

JSP 2+

Las personas que afirman que JSP harán que sea difícil evitar el código Java en las plantillas son falsas. No deberías hacerlo y con esta versión no es necesario hacerlo. La versión 2 admite métodos de llamada que usan EL, lo cual es una gran ventaja en comparación con las versiones anteriores.

Con las etiquetas JSTL, su código aún se verá como HTML, por lo que es menos incómodo. Spring incluye mucho soporte para JSP a través de taglibs, que es muy poderoso.

Los taglibs también son fáciles de ampliar, por lo que personalizar su propio entorno es muy sencillo.

Uno de los mejores argumentos para facelets (no en su lista, pero solo lo mencionaré) opuesto al uso de JSP es que la compilación está integrada con el intérprete en lugar de delegarse al compilador JSP. Esto significa que una de las cosas más molestas que tuve con JSF 1.1 - tener que cambiar el atributo id en una etiqueta JSF circundante al guardar un cambio para que el motor de tiempo de ejecución descubra el cambio - desapareció, dando el save- en el editor, vuelve a cargar en el navegador, junto con mensajes de error mucho mejores.

Una tecnología de buena vista elimina la mayoría y la mayoría de las declaraciones condicionales / switch / molestas, la inclusión simple no lo hace. El uso de una tecnología de vista 'compleja' da como resultado una aplicación 'simple'.

No proporcionó información sobre sus aplicaciones específicas. Por ejemplo, no uso JSP solo por algunas razones:

Es difícil evitar el uso de código Java en plantillas JSP por lo que su concepto de ruptura de vista pura y, como resultado, tendrá dificultades para mantener el código en varios lugares como vista y controlador

JSP crea automáticamente un contexto JSP que establece una sesión. Es posible que desee evitarlo, sin embargo, si sus aplicaciones siempre usan sesión, puede que no sea un problema para usted.

JSP requiere compilación y si el sistema de destino no tiene compilador de Java, cualquier ajuste menor requerirá usar otro sistema y luego volver a implementar

El motor JSP mínimo tiene aproximadamente 500k de código de bytes más JSTL, por lo que puede no ser adecuado para sistemas integrados

El motor de plantilla puede generar diferentes tipos de contenido del mismo modelo, digamos carga útil JSON, página web, cuerpo de correo electrónico, CSV, etc.

Los programadores que no son de Java pueden tener dificultades para trabajar con plantillas JSP, cuando las personas sin conocimientos técnicos nunca tuvieron dificultades para modificar las plantillas normales.

Estaba haciendo la misma pregunta hace mucho tiempo y terminé escribiendo mi marco (seguramente basado en un motor de plantillas) que estaba libre de todas las desventajas que vi en otras soluciones. No hace falta decir que se trata de unos 100 k de código de bytes.

Me doy cuenta de que esto parece una respuesta inteligente, pero la verdad es que si no ve ninguna ventaja en usar plantillas sobre el código en su proyecto actual, probablemente sea porque en su proyecto actual, no hay una .

Parte de esto tiene que ver con la escala. Podría pensar que las inclusiones son tan poderosas como, digamos, sitemesh, y eso es cierto, al menos para una pequeña cantidad de páginas (yo diría que probablemente unas 100), pero si tiene varios miles, comienza a volverse inmanejable. (Entonces para eBay no es necesario, para Salesforce probablemente lo sea)

Además, como se ha mencionado anteriormente, el marcador libre y la velocidad no son específicos de un servlet. puede usarlos para cualquier cosa (plantillas de correo, documentación fuera de línea, etc.). No necesitas un contenedor Servlet para usar freemarker o velocity.

Por último, su punto 5 es solo parcialmente cierto. Se compila cada vez que se accede a él si aún no lo ha sido. Esto significa que cada vez que cambie algo, debe recordar eliminar el directorio "work" de los contenedores de servlets, para que recompile el JSP. Esto es innecesario con un motor de plantillas.

Los motores de plantillas TL; DR se escribieron para abordar algunas deficiencias (percibidas o reales) de JSP + JSTL. Si debe usarlos o no depende completamente de sus requisitos y la escala de su proyecto.