Capítulo 1. ¿Por qué Cocoon?

1.1. Motivación

Hoy en día, la presencia en el Web es cada vez más relevante e importante para las empresas. Día a día se demandan más servicios en Internet. Por esto, son requeridos sistemas con gran capacidad de transformación y asimilación de las nuevas tendencias, de las nuevas tecnologías y del constante cambio del propio mercado.

Una característica importante de este tema es lo que atañe a la presentación de la información en múltiples formas y dispositivos. Si tenemos en cuenta el manejo de la información como hasta actualmente se está haciendo y analizamos lo que significa para una empresa tener toda su presentación en páginas HTML, podemos notar que imponer un cambio de imagen en las propias páginas es una labor dispendiosa y debido a que se trata de "remendar" algo ya hecho, se torna en una tarea poco agradable.

Peor aún, si se trata de presentar la información de la empresa en un formato distinto al HTML, ya que además de crear la presentación se debe recolectar la información de la presentación en el formato que está manejando, es decir, el HTML.

Como usted ya se habrá dado cuenta, el tener la información en la misma capa en la que se presenta, genera inconvenientes grandes y desencadena una cantidad de factores negativos para las organizaciones tales como gastos en mantenimiento, mayor tiempo en los desarrollos, pérdida de tiempo y dinero en la capacitación de personas para que conozcan la estructura de presentación, etc.

Para las empresas en las cuáles los datos de presentación se generan de forma dinámica, el problema pasa del diseñador al programador. En estos casos el programador tiene que ir al código y cambiar la presentación, pero pensemos que en realidad ésto no es el trabajo de un programador, es precisamente la presentación, trabajo del diseñador. Es claro que el diseñador no puede hacerlo (y tampoco debe, por que no es su oficio) ya que su línea de trabajo no está pensada para esto. Ésto se da mucho en generación dinámica de aplicaciones que utilizan tecnologías del estilo de Servlets. Sin embargo nótese que el programador, al tener que modificar en su código fuente aspectos de presentación corre un riesgo alto de alterar el funcionamiento de la aplicación, lo cual cae en una solución peor e improductiva.

Una solución mejorada de los Servlets salió con la tecnología J2EE. En los J2EE Beans (que son la forma de presentar la información) se debería tener el mínimo código, es decir, el necesario para las clases que contienen toda la lógica del negocio. Por otro lado, con los taglibs (etiquetas XML para definir código) se posibilita crear páginas que no tienen una sola línea de código.

Bien, ésto mejora las cosas; sin embargo se siguen teniendo básicamente tres problemas:

  1. Si se quieren obtener distintas presentaciones, es necesario modificar el código Java que se encarga de dar formato a los datos

  2. El mantenimiento puede no ser tan transparente ya que un diseñador puede alterar el código embebido en el HTML.

  3. En ocasiones puede ocurrir que se incluya código Java mas allá del necesario para que puedan funcionar correctamente los beans.

Sería óptimo poder tener productos de información que fueran independientes de las distintas formas de presentación y que si ese contenido se generara dinámicamente, ese dinamismo también fuera totalmente independiente. En pocas palabras se quiere separar Contenido, Lógica y Presentación.

Si se tuviera en un repositorio toda la información sin ninguna característica que la atara a algún tipo de presentación, se podrían implantar cada una de las vistas que se desearan sin que se debiera tener en cuenta alguna de las otras. Luego, el cambio o el mantenimiento de una de las vistas no le afectaría, sino a ella misma.