Web Publishing Frameworks
En nuestros días, cada vez está tomando mayor relevancia la presencia en la WEB. Cada
día se demandan más servicios a través de Internet y aumenta el número de competidores.
Todo este dinamismo requiere sistemas potentes en cuanto a servicios y contenidos, y a la vez
con una gran capacidad de transformación para adaptarse continuamente a las nuevas
necesidades impuestas por las estrategias de mercado.
Otra necesidad actual que complica aún más el problema es la de presentar información
en diversos dispositivos y formatos. Seguramente a una empresa le gustaría que los datos de
su producto estrella en su catálogo pudiesen ser visualizados desde un navegador web, desde
un móvil con tecnología WAP o que se pudiesen imprimir con alta calidad para un catálogo en
papel.
Imaginemos una web formada por decenas o cientos de páginas HTML que necesite ser
renovada para reflejar la nueva imagen de la compañía. ¡Puede ser una auténtica pesadilla!.
Técnicas como el uso de Hojas de Estilo en Cascada (CSS) ayudan pero no deja de ser todo un
desafío que puede durar demasiado tiempo. Si además se pretende hacer versiones para
distintos formatos se debería multiplicar el número de páginas.
Si el contenido se genera dinámicamente, por ejemplo mediante la consolidada
tecnología de los Java Servlets,
el problema pasa del diseñador web al desarrollador. Este debe
retocar el código fuente de sus programas para cambiar la estética del resultado, con el riesgo
de alterar todo el funcionamiento del sistema y esto podría llevar aún más tiempo hasta
conseguir el cambio deseado. Para conseguir distintos formatos de presentación se debería
aumentar el número de servlets o complicar la lógica interna de cada uno para que, en función
de algún parámetro, se pueda cambiar la presentación.
La aparición de las Java Server Pages (JSP) de la mano de Sun Microsystems supuso
una mejora muy importante con respecto a los servlets en este sentido. Dos de las principales
características de las JSP van orientadas a convertirlas prácticamente en vistas para datos que
se generan con código fuera de la página:
- El uso de JSP Beans: Un buen diseño de JSP no debería contener apenas código, sólo el
necesario para invocar otras clases que contienen toda la lógica y para formatear dentro
de la página los datos obtenidos desde estas clases.
- El uso de librerías de etiquetas o taglibs: (A partir de la especificación JSP 1.1.) Permiten
definir etiquetas XML que se corresponden con un fragmento de código. De esta forma
se pueden construir páginas sin código que contienen esta clase de etiquetas.
A pesar de que la situación mejora, siguen existiendo algunos inconvenientes:
- Existe el riesgo de que un diseñador o un desarrollador de HTML pueda alterar el código
embebido en la página, con lo que el mantenimiento se puede complicar.
- Para obtener distintos formatos hay modificar el código Java que formatea los datos, con
lo que se requiere un programador para hacer el trabajo típico de un desarrollador de
HTML / diseñador. Este es uno de los problemas que plantea el solapamiento de perfiles
profesionales que conlleva el desarrollo de JSPs.
- Resulta muy tentador incluir demasiado código en la página sin utilizar en su lugar beans
o taglibs.
Desde el principio se está hablando de la misma cosa, y no es otra que la separación
entre contenido y presentación. Por un lado estaría bien tener productores de información que
generen la información adecuada en un formato estándar y por otro lado poder definir distintas
vistas de esos datos. Así un cambio de imagen sólo afectaría a ciertas vistas pero la lógica para
generar la información no se ve alterada. Del mismo modo, la necesidad de tener disponibles
los datos en un nuevo formato sólo implica la creación de una nueva vista.
Con esta idea surgen principalmente dos soluciones:
- Motores de plantillas: La idea es que si las JSP solo se usan para crear vistas de los datos
generados por los JSPBeans, ¿para qué usar una sintaxis tan compleja?. Los motores de
plantillas proponen diseñar vistas a modo de plantillas con unas sintaxis muy sencillas
que permitan especificar cómo se obtienen los datos y cómo se colocan para obtener el
resultado final. El objetivo es que el diseño de estas plantillas pueda ser llevado a cabo
por diseñadores o desarrolladores de HTML con escasos conocimientos de programación
de forma sencilla. Esta solución también tiene problemas:
- No hay ninguna especificación ni ningún estándar, cada producto tiene su
propia sintaxis.
- A pesar de que las sintaxis para el control de datos son sencillas no deja de ser
programación, y es difícil convencer a un diseñador para que trabaje con ella.
- Los productos de este tipo no suelen ser demasiado eficientes comparados con
otras soluciones.
Los productos de este tipo más populares a la fecha de este documento son
WebMacro de Semiotek,
Apache Velocity y
FreeMarker.
- XML/XSL Publishing Frameworks: En la actualidad se están convirtiendo en la mejor
alternativa.
- Si se busca un formato con el que enviar los datos a las vistas, qué mejor que usar un
estándar con las ventajas de XML.
Entre estas ventajas podemos destacar, en este
contexto, sus capacidades de transformación mediante XSL,
sobre todo XSL-T. Así, podemos hablar de un publishing framework basado en XML/XSL como un sistema que:
- Admite peticiones de documentos en diversos formatos.
- Obtiene la información adecuada de diversas posibles fuentes de datos XML.
- Obtiene la información sobre las transformaciones XSL necesarias y se las
aplica a los datos.
- Formatea el resultado final y lo sirve como respuesta a la petición inicial.
Las ventajas de un sistema de publicación basado en XML/XSL son, entre otras:
- Separación limpia entre contenido y presentación.
- Permite separar claramente los papeles del programador y el diseñador.
- Proporciona una mejora muy notable del mantenimiento: Se puede realizar un
cambio radical de imagen de todo un site web con tan solo modificar las hojas
XSL y sin tocar ni una sola línea de código.
- A partir de un solo documento XML con el contenido, se pueden obtener páginas
HTML para su presentación web, páginas WML para dispositivos WAP, documentos PDF para imprimir...
- Aunque no hay ningún estándar que regule como debe ser un sistema de
publicación si que está basado en estándares con mucha fuerza en el mercado,
por lo que es más sencillo pasar de usar uno a usar otro.
- Es compatible con el resto de tecnologías web como servlets, JSPs...
La desventaja principal es la poca madurez de la mayoría de los proyectos de este tipo y
que aún no están del todo asentados.
Actualmente ya hay un amplio abanico de soluciones, que pasan desde complementos
para Apache escritos en Perl como AxKit a JSPs productoras de XML manejadas por
servlets que aplican a su resultado diversas transformaciones. Por esta última línea han
surgido varias alternativas, casi siempre basadas en taglibs para manejar xml, pero no
dejan de ser poco naturales. Al respecto hay una propuesta muy interesante que forma
parte del proyecto Apache Cocoon, que son las XSP (parecidas a las JSP pero con total
integración con el manejo de XML).
Este campo de aplicación se está moviendo deprisa, y continuamente aparecen nuevas
propuestas. Una lista de ellas se puede encontrar en
http://www.xmlsoftware.com/publishing/.
El proyecto open source
Apache Cocoon
es la solución más madura y más adecuada de
las que se estudiaron al inicio del proyecto y a la que vamos a dedicar especial atención
en el resto del curso.