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

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

Hay 6 opciones por lo que veo (aunque no son mutuamente excluyentes):

• Losas
• Malla del sitio
• marcador libre
• Velocidad
• <jsp:include>
• <%@ include file="..">

Losas y Malla del sitio se pueden agrupar; por lo que puede marcador libre y Velocidad. Cuál usar dentro de cada grupo no es un tema de esta discusión, hay suficientes preguntas y discusiones al respecto.

Esta es una lectura interesantepero no puedo convencerme de usar mosaicos.

Mi pregunta es – ¿Qué dan estos marcos que no se puede hacer correctamente con <@ include file=".."> y JSTL. Puntos principales (algunos tomados del artículo):

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

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

   y

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

2. Definición de parámetros en el encabezado – como título, metaetiquetas, etc. Esto es muy importante, especialmente desde el punto de vista de SEO. Con las opciones de plantilla, simplemente puede definir un marcador de posición que debe definir cada página. Pero entonces puedes en jsp con JSTLusando <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ágina (con jsp) no están bien organizadas, es posible que deba cambiar cada página 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 un 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 lo que está sucediendo.

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

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

Algunos argumentos para Velocity (no he usado Freemarker):

• Potencial para reutilizar plantillas fuera de un contexto web, como en el envío de correos electrónicos
• La sintaxis del lenguaje de plantilla de Velocity es lejos más simple que JSP EL o 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 usar etiquetas de scriptlet y hacer cosas desagradables en sus plantillas.

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

Sí, 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 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 del disco cada vez. De cualquier manera (y no tengo números sólidos para esto), Velocity siempre se ha sentido rápido para mi.

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ágina (con jsp) no están bien organizadas, es posible que deba cambiar cada página 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 estaría reorganizando este diseño en cada archivo JSP que usa 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 el fondo) donde puede especificar lo que quiera y luego simplemente delegar a 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:include y Azulejos/sitemesh/etc. es la elección entre sencillez y poder que los desarrolladores enfrentan todo el tiempo. Claro, si solo tiene unos pocos archivos o no espera que su diseño cambie muy a menudo, simplemente use jstl y jsp:include.

Pero las aplicaciones tienen una forma de crecer gradualmente, y puede ser difícil justificar la “detener el nuevo desarrollo y modernizar mosaicos (o alguna otra solución) para que podamos solucionar problemas futuros más fácilmente”que es necesario si no utiliza una 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 que no use mosaicos/etc. De lo contrario, úsalo desde el primer momento.

No te voy a convencer de usar otras tecnologías. Por lo que sé, todos deberían apegarse a JSP si les funciona.

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

Malla del sitio 2/3

Proporcione decoradores que se aplicarán a las vistas principalmente como trabajos de herencia en otros motores de plantillas. Hoy en día es impensable trabajar sin esta característica.

JSP 2+

Las personas que afirman que JSP dificultará evitar el código Java en las plantillas son falsas. Simplemente 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 JSTL etiquetas, 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.

Las librerías de etiquetas también son fáciles de ampliar, por lo que personalizar su propio entorno es pan comido.

Uno de los mejores argumentos a favor de las facetas (no en su lista, pero solo lo mencionaré) opuesto al uso de JSP es que la compilación se integra 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 de identificación en una etiqueta JSF circundante al guardar un cambio para que el motor de tiempo de ejecución descubriera el cambio, desapareció, dando el guardar- en el editor, vuelva a cargar en el navegador, junto con mensajes de error mucho mejores.

Una buena tecnología de visualización elimina la mayoría y las más molestas sentencias if/switch/conditional, el simple include no lo hace. El uso de una tecnología de vista ‘compleja’ da como resultado una aplicación ‘simple’.

No proporcionó información sobre 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 romperá el concepto 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 un 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 plantillas puede generar diferentes tipos de contenido del mismo modelo, por ejemplo, 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 han tenido dificultades para modificar plantillas regulares.

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 100k 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 el uso de plantillas sobre el código en su proyecto actual, probablemente sea porque en su proyecto actual, no hay uno .

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

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

Por último, su punto 5 es solo parcialmente cierto. Se compila cada vez que se accede si no se ha hecho ya. Esto significa que cada vez que cambie algo, debe recordar eliminar el directorio de “trabajo” de los contenedores de servlet, para que vuelva a compilar el JSP. Esto es innecesario con un motor de plantillas.

TL;DR Los motores de plantillas 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.