template example engine java jsp velocity tiles freemarker

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



java template engine (7)

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):

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

Tiles y Sitemesh se pueden agrupar; también lo pueden Freemarker y Velocity . Cuál de cada grupo usar no es una cuestión de esta discusión, hay suficientes preguntas y discusiones al respecto.

Esta es una lectura interesante , pero no puede convencerme de usar fichas.

Mi pregunta es: ¿qué ofrecen 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. Definir 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 plantillas puede simplemente definir un marcador de posición que cada página debe definir. Pero puede hacerlo 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 el rastro 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 esos 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 otras opciones se analizan / ejecutan muchas veces.

  6. Complejidad : todas las soluciones que no son jsp requieren archivos xml adicionales, incluye configuraciones de preprocesador, etc. Esta es una curva de aprendizaje e introduce más puntos potenciales de falla. Además, hace que el soporte y el cambio sean más tediosos: debe verificar una cantidad 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, coloque un marcador de posición y utilice el modelo (colocado en el alcance de la solicitud o sesión, por los controladores) para llenar estos marcadores de posición.

Entonces, convencedme de que debería usar cualquiera de los frameworks 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 plantillas de Velocity es mucho más simple que JSP EL o las bibliotecas de etiquetas
  • Estricta separación de lógica de vista de cualquier otro tipo de lógica: no hay una opción posible para usar etiquetas scriptlet y hacer cosas desagradables en sus plantillas.

Placeholders - do velocidad / freemaker dan algo más que JSTL? En JSTL, coloque un marcador de posición y utilice el modelo (colocado en el alcance de la solicitud o sesión, por los controladores) para llenar estos marcadores de posición.

Sí, las references 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 otras 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 abstracto 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 el rastro 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 esos 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ías reorganizando este diseño en cada archivo JSP que utiliza el mismo encabezado / pie de página? Tiles y SiteMesh le permiten especificar una página de diseño base (JSP, plantilla de Velocity, etc., ambos son marcos JSP en su corazón) donde puede especificar lo que desee y luego simplemente delegar en un fragmento / plantilla de "contenido" para el contenido principal . Esto significa que habría solo un archivo para mover el encabezado.

La elección entre jsp:include y Tiles / Sitemesh / etc es la elección entre la simplicidad y la potencia que los desarrolladores enfrentan todo el tiempo. Claro, si solo tiene algunos 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 incrementalmente, y puede ser difícil justificar la "detención de nuevos bloques de desarrollo y actualización (o alguna otra solución) para que podamos solucionar problemas futuros con mayor facilidad" , lo cual es necesario si no utiliza un solución compleja en el comienzo.

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 tiles / etc. De lo contrario, úselo desde el principio.

Me doy cuenta de que esto viene como una respuesta inteligente, pero la verdad es que si no ves ninguna ventaja al usar plantillas sobre el código en tu proyecto actual, es probable que sea porque en tu proyecto actual, no hay uno .

Parte de esto es sobre escala. Podrías pensar que incluir es tan poderoso como digamos sitemesh, y eso es cierto, al menos para un pequeño número de páginas (diría probablemente alrededor de 100), pero si tienes varios miles, comienza a volverse inmanejable. (Entonces, para eBay no es necesario, para Salesforce probablemente lo sea)

Además, como se ha mencionado anteriormente, freemarker y 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 velocidad.

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

Los motores de templado 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.

No proporcionó información acerca de 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 para que su concepto de ruptura de la Vista pura, y como resultado tendrá dificultades para mantener el código en varios lugares como la vista y el 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 no ser un problema para usted

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

El motor JSP mínimo tiene aproximadamente 500k de bytecode 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, digamos carga útil JSON, página web, cuerpo de correo electrónico, CSV, etc.

El programador no Java puede tener dificultades para trabajar con plantillas JSP, cuando las personas no técnicas nunca tuvieron dificultades para modificar las plantillas regulares.

Estuve 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. Huelga decir que se trata de 100k de código de bytes.

No voy a convencerte de que uses otras tecnologías. Por lo que sé, todos deberían apegarse 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, en su mayoría como obras de herencia en otros motores de plantillas. Tal característica es impensable para trabajar sin hoy en día.

JSP 2+

La gente que afirma que JSP dificultará evitar el código de Java en las plantillas es falsa. Simplemente no deberías hacerlo y con esta versión no es necesario hacerlo. La versión 2 es compatible con los métodos de llamada que utilizan EL, que es una gran ventaja en comparación con las versiones anteriores.

Con las etiquetas JSTL su código se verá como HTML, por lo que es menos incómodo. Spring ofrece 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 tu propio entorno es muy sencillo.

Una buena tecnología de visualización elimina la mayoría y la mayoría de las declaraciones if / switch / conditional, simple include does not. El uso de una tecnología de visualización ''compleja'' da como resultado una aplicación ''simple''.

Uno de los mejores argumentos para facelets (no en su lista, pero lo mencionaré) opuesto al uso de JSP es que la compilación está integrada con el intérprete en lugar de ser delegada 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 descubriera el cambio - se fue, dando el salvamento en el editor, ciclo de recarga en el navegador, junto con mensajes de error mucho mejores.