El sistema de publicación en web Cocoon

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.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

SIGUIENTE ARTÍCULO

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.