Introduccrión a los motores de plantillas
sábado, junio 1, 2002 at 2:00AM Motores de plantillas (Templates engines)
¿Que son las plantillas?.
Si hay algo "de moda" en Java, en la programación en general, y en la programación para la web en particular, es el famoso patrón MVC (Model View Controller). Este patrón trata de separar los datos de su presentación, por decirlo en terminos web, de separar el código del programador del código del diseñador web. Las plantillas son una aproximación más para resolver este problema, como lo puede ser XMLC (http://xmlc.enhydra.org/).
Las plantillas, o más exactamente los motores de plantillas (templates engines) leen un fichero de texto, que contiene la presentación ya preparada en HTML (o meta información, por ejemplo XML, o lo que sea, siempre que sea texto), e inserta en él la información dinámica que le ordena el "controlador" (la C de MVC), la parte que une la vista con la información.
Veamos un par de ejemplos para ver las posibilidades de las plantillas, que no acaban, ni mucho menos, en la web. La sintaxis a utilizar depende del motor de plantillas utilizado, pero todos son muy similares, e incluso hay herramientas de conversión entre ellos. Los motores de plantillas suelen tener un pequeño lenguaje de script que permite generar código dinámico, como listas o cierto comportamiento condicional. Este lenguaje de script es absolutamente mínimo, lo justo para posibilitar ese comportamiento dinámico.
<html>
<body>
Hola ${nombre}
</body>
</html>
Esta claro que este ejemplo, una pequeña variación del famoso "Hola Mundo", es "vergonzosamente" simple, pero tampoco es plan de asustar con el primero. Bién, al procesar este fichero, el motor de plantillas lo recorrerá, parseará (si es que existe esa palabra en castellano) y sustituirá esa "etiqueta clave" ${nombre} por el texto que le hallamos indicado, el nombre del visitante, por ejemplo, de forma que tengamos una presentación personalizada.
Como hemos dicho, las plantillas se pueden utilizar para mucho más que para generar HTML, así pues en este ejemplo más complicado veremos como generar XML.
<?xml version="1.0"?>
<link>
<titulo>${link.titulo}</titulo>
<descripcion>${link.descripcion}</descripcion>
<url>${link.url}</url>
</link>
Como vemos, las plantillas no se refieren sólo a elementos simples de datos, si no que también pueden procesar objetos para mostrar sus miembros, de la forma ${objeto.campo}, aunque como hemos dicho, la sintaxis exacta depende del motor de plantillas empleado.
Este tercer ejemplo, y último de esta pequeña introducción a las posibilidades que nos ofrecen las plantillas, es un poco más complicado. Por medio de plantillas podríamos generar un informe sobre el pedido de un cliente, para enviarselo al mismo cliente por email o para enviarselo a nuestro sección de envios.
Nombre: ${cliente.nombre} Fecha: {fecha}
Número de cliente: ${cliente.codigo}
Dirección: ${cliente.direccion}
<list pedido as elemento>
${elemento.cantidad} ${elemento.descripcion} ${elemento.precio}
</list>
Total a pagar: ${total}
Como podeis observar, la sintaxis de este pequeño lenguaje de script es muy sencilla, en ocasiones "de aspecto xml", por lo que no es difícil de aprender.
También os podeis imaginar lo sencillo que es hacer cambios en el resultado generado por nuestra aplicación sin tener que tocar el código Java de nuestra aplicación, y aún más, sin tener que hacerlo nosotros. Si nuestro jefe quiere que aparezca una cabecera extra en el listado del tercer ejemplos, o una firma, lo puede hacer el solito, editando la plantilla.
Plantillas vs JSP.
Si has leido lo anterior, y crees que las plantillas pueden ser interesantes para ti, en la programación web, pero aún no estas del todo seguro en que puede mejorar esto tu desarrollo con JSP, en esta sección intentaremos describir los ventajas/desventajas de uno u otro estilo.
El patrón MVC se empeña en separar el código HTML del código Java. Como habreis visto en los ejemplos anteriores, la separación entre ambos es "absoluta" en las plantillas, mientras que en las JSP se puede incorporar toda la cantidad de código Java que quieras.
Es cierto que con buenos hábitos de programación, y usando herramientas como Java Beans y taglibs la cosa puede resultar más sencilla, pero en todo caso tienes un problemas
- o bien haces que los programadores Java tengan que manipular el código HTML.
- o bien haces que los programadores HTML tengan que aprender, como poco, los conceptos básicos de las JSP.
Ninguna de las dos variantes es factible, o recomendable, creo yo. Los programadores Java no son, por lo general, demasiado amigos del HTML, y es posible que les falten conocimientos, y que la página tan perfecta que les han entregado los programadores HTML para que introduzcan la lógica dinámica acabe, por decirlo de una forma sencilla, "no tan perfecta". Por el otro lado, si obligas a los programadores HTML a aprender los conceptos de las JSP y taglib, aunque no son complicados, no es del todo seguro que los usen eficientemente, o al menos pasará un tiempo antes de que lo hagan. Esto llevará a la típica situación en las que un equipo se queja del otro porque estan "destrozando" su trabajo.
El lenguaje de script que incorporan las plantillas es muy reducido y simple, y en algunos motores de plantillas, como Freemarker, este lenguaje tiene aspecto de XML, con etiquetas de inicio y final, por lo que los programadores HTML lo pueden aprender en media hora de estudio. Puedes comprobar su sencillez mostrando los ejemplos anteriores a un programador HTML y preguntándole que cree él que hace ese código, o incluso tú mismo puedes darte cuenta de la sencillez de este código, puesto que estoy seguro de que has entendido a simple vista lo que hacen los ejemplos aún siendo la primera vez que oyes algo sobre las plantillas.
Por último, esta clara separación entre HTML y Java hace que sea posible el trabajo en paralelo de ambos equipos, siempre que se haya definido al principio ciertos aspectos, como cual será la información a mostrar y bajo que nombres.
Antes hemos mencionado la posibilidad de usar taglibs o librerías de etiquetas. Las librerías de etiquetas se introdujeron con la especificación 1.1 de JSP para intentar "sacar" un poco de código Java del HTML, ya que esto violaba la "ley de separación" del MVC. Este intento no fue muy acertado, aunque algo mejoró la situación. Estas librerias de etiquetas encapsulan datos y cierta lógica (en ocasiones incluso aún cierto código HTML, una aberración) para ofrecérsela a la JSP por medio de una interface que define la especificación. El mayor problema de esta aproximación, a parte de la dificultad intrinseca de crear una libreria (programación, configuración y despliegue, si no podeis mirar la cantidad de proyectos al respecto que hay, bastante escasos), esta en que todo esta idea se basa en la "reflexión" (reflection), que debido a su forma de trabajo (buscar dentro de una clase los métodos con la signatura dada) no es el modo más eficiente de trabajar. Y por supuesto, ni hablar de la posibilidad de que alguién meta código HTML en la libreria, solo con que alguién cambie (o quiera cambiar) la apariencia de la página se presenta la necesidad de recompilar la libreria.
Sin embargo las JSP tienen la ventaja de contar con una gran industria detrás de ellas. Esto no las hace mejores, pero por motivos de marketing, un programador java que se acerca a la web empezará con JSPs, y tardará en enterarse de sus problemas, o en oir hablar de otras posibilidades (plantillas, XMLC), si es que algún día llega a hacerlo. Por supuestoque a esto se une la "decisión" de los jefes, que en muchas ocasiones se deciden por tecnologías que no conocen, sin preguntarse si son buenas o hay alternativas posibles, solo porque lo ha leido/oido en algún sitio.
Diferentes motores de plantillas.
Principalmente existen tres motores de plantillas disponibles en internet, todos open source. Webmacro (http://www.webmacro.org), Velocity (http://jakarta.apache.org/velocity), y Freemarker (http://freemarker.sourceforge.net). Webmacro y Velocity son muy similares (Velocity empezó basándose en Webmacro), por lo que esta especie de comparación se basará en Velocity y Freemarker,
- La primera gran diferencia esta en el modo de trabajar de ambos motores. Velocity lo hace a través de reflection, mientras que Freemarker lo hace a través de una serie de interfaces definidas. Esto es bueno y es malo para las dos. Es malo para Velocity, porque si hemos dicho que la reflexión aplicada a las taglibs es ineficiente, es de suponer que aplicada a las plantillas no será la mejor solución del mundo, aunque sea la más sencilla para el programador usuario del motor de plantillas. Pero en el caso de Freemarker, aunque el trabajo en base a interfaces sea más eficiente, el hecho de tener que tener que implementar unas interfaces determinadas (principalmente tres, para listas, mapas y valores simples), nos obliga a implemtar esas interfaces en los objetos de nuestro modelo de negocio, o a desarrollar clases envoltorio (wrappers) para envolverlos. Freemarker nos ofrece ya algunas soluciones "listas para su uso", y se esta desarrollando un concepto para soportar la reflexión de forma más óptima (en realidad ya tienen una aproximación a ello funcionando, pero trabajan en su mejora), por lo que este trabajo en base a interfaces no deberia ser problema, más bien pasa a ser, por decirlo de alguna manera, opcional.
- Velocity esta más documentado, o al menos hay más documentación al respecto. Aunque el soporte de ambas comunidades es igual de bueno, Velocity como subprojecto de jakarta tiene más colaboradores en todos los sentidos. Freemarker trata de hacerse camino, aunque aún se esta regenerando de cierta dejadez anterior.
- Fremarker tiene un lenguaje de script "de formato XML", por lo que puede hacer que sea más apatecible para diseñadores web que Velocity, con un formato mucho más del estilo del programador. En Freemarker un bucle se hará con:
<list lista as elemento>
...
</list>
y en Velocity:
#foreach( $elemento in $lista )
...
#end - El futuro de ambos se podría considerar "incierto" por diversos motivos. La comunidad de Velocity es mucho mayor, lo que puede hacer presuponer que su futuro es más halagüeño, pero al mismo tiempo tiene aspecto de ser más monolítico, y sigue arrastrando aspectos (arrastrados desde el comienzo del proyecto) que la limitan a avanzar para no romper la compatibilidad. Sin embargo, la más limitada comunidad de Freemarker hace que sea más ágil y factible su renovaciópn/adaptación a los nuevos tiempo, como la reciente reescritura de la versión 2.0 (que aún asi es casi totalmetne compatible con la versión 1.x).
Otros aspectos, además de los referentes a sus diferencias con las JSP ya comentados, los hacen similares, como son la existencia de frameworks para su utilización desde Servlets, el soporte para XML (aunque este es un poco desigual en favor de Freemarker), soporte numérico en las plantillas (Velocity soporta enteros, Freemarker reales y enteros), y su "lucha" contra las JSP y otras tecnologías similares por hacerse un hueco en el desarrollo web.
Conclusión.
Los motores de plantillas tienen el handicap de ser algo "desconocido". Existe el problema de que mucha gente usa JSP "porque no conoce otra cosa", y porque creen que es lo mejor porque hay más libros sobre el tema. Quién sabe, quizás para alguna aplicación sean adecuadas. En este artículo he intentado mostraros lo que las plantillas pueden hacer, espero haberlo conseguido, y espero que les deis "una oportunidad", aunque tengais que esperar al siguiente artículo para aprender como usarlas (al menos si no sois curiosos y empezais vosotros mismos).
Cerraré contando, como anécdota, que en mi vida profesional ya he "convertido" dos equipos de trabajo basados en JSP a hacerlo en las plantillas, y ya estoy deseando que llegue el siguiente. Algo tendrán las plantillas si convencen cuando se las conoce, ¿no?.
|
Reader Comments