Apache Cocoon 2

Motivaci�n, Introducci�n y Explicaci�n

Sa�l Z�rrate C�rdenas

Este documento se cede al dominio p�blico.

Tabla de contenidos
1. �Por qu� Cocoon?
1.1. Motivaci�n
1.2. Entornos de publicaci�n web (Web Publishing Framework)
2. Cocoon
2.1. �Qu� es Cocoon?
2.1.1. Funcionamiento a nivel de usuario
2.2. Cocoon 1 Vs Cocoon 2
3. Estructura y arquitectura de Cocoon
3.1. Conceptos claves
3.1.1. Estructura
3.1.2. Arquitectura
4. Cocoon y las XSPs
4.1. Introducci�n
4.2. Tipos de p�ginas XSP
4.2.1. XSP con la l�gica embebida en la presentaci�n
4.2.2. XSP con hojas de estilos
4.2.3. XSP con bibliotecas de etiquetas
4.3. Conectividad a bases de datos
5. Paralelismo con Cocoon
6. Instalaci�n de Cocoon 2
6.1. Requisitos para la instalaci�n
6.1.1. Instalaci�n de Tomcat
6.1.2. Ambiente Java
6.2. Instalando Cocoon
6.2.1. Instalaci�n R�pida De Cocoon
6.2.2. Instalaci�n a partir de los fuentes
7. Configuraci�n y personalizaci�n en Cocoon
7.1. El sitemap
7.1.1. Selecci�n y match en Cocoon
7.1.2. Funcionalidad del sitemap
7.1.3. Estructura b�sica del sitemap
8. Desarrollo en Cocoon
8.1. Contenido est�tico
8.2. Contenido Din�mico
8.2.1. Dando l�gica con programaci�n en Java
8.2.2. Acceso a bases de datos
8.3. Deployment en Cocoon
8.3.1. Condiciones m�nimas
8.3.2. Inclusi�n de un subsitemap en el sitemap de Cocoon
8.3.3. C�digo del subsitemap
A. Formato de reuni�n semanal
A.1. Introducci�n
A.2. Descripci�n formato de reuni�n semanal
A.2.1. Elementos del formato de reuni�n semanal
A.3. XML
A.3.1. �Qu� es?
A.3.2. Ejemplo XML con el formato de reuni�n semanal de Ingenier�a de Software
A.4. XSL
A.4.1. Algunos aspectos de XSL
A.5. Usando el formato de reuni�n semanal en Cocoon
Tabla de figuras
3-1. Cocoon desde un punto de vista estructural
3-2. Arquitectura de Cocoon
4-1. Flujo en XSP
5-1. WorkFlow en Cocoon
6-1. Ventana de bienvenida de Tomcat
6-2. Ventana de bienvenida de Cocoon
A-1. Formato de reuni�n semanal en Cocoon
Tabla de ejemplos
7-1. Ejemplo de un sitemap b�sico
8-1. C�digo para funcionamiento de un solicitud de un fichero XML presentado como un HTML
8-2. C�digo para definir un Data Source para acceso a una base de datos
8-3. C�digo para cargar clases para acceso a bases de datos.
8-4. Ejemplo de C�digo de Base de Datos necesario a incluir con la Base de Datos hsql
8-5. Pipeline necesario para una XSP con etiquetas SQL y acceso a una Base de Datos
8-6. C�digo de una XSP con conexi�n a Base de datos con etiqueta SQL
8-7. Pipeline necesario para una XSP con etiquetas ESQL y acceso a una Base de Datos
8-8. C�digo de una XSP con conexi�n a Base de datos con etiqueta ESQL
8-9. C�digo para incluir un subsitemap
8-10. C�digo b�sico de un subsitemap
A-1. Ejemplo de una DTD para el formato de reuni�n semanal
A-2. Ejemplo de un documento XML para el formato de reuni�n semanal
A-3. Ejemplo de una XSL para el formato de reuni�n semanal
A-4. C�digo para a�adir un pipeline que cargue el formato de reuni�n semanal

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.

1.2. Entornos de publicaci�n web (Web Publishing Framework)

Es aqu�, donde surgen los Entornos de Publicaci�n Web Basados en XML y XSL. En este tipo de aplicaci�n se tienen las ventajas de la tecnolog�a XML, tales como ser un est�ndar, ser una meta com�n para las empresas de tecnolog�a, facilidad en la transformaci�n con el apoyo de la tecnolog�a XSL, separaci�n total entre datos y presentaci�n de los mismos, separaci�n entre el rol del programador y el rol del dise�ador (y por lo tanto m�s productividad, menos costos y m�s paralelismo de trabajo), mejor y m�s f�cil tratamiento al mantenimiento y ser compatible con el resto de tecnolog�as.

Hasta este punto un entorno de publicaci�n web en xml resuelve el problema contenido-presentaci�n. �Pero y la l�gica de la aplicaci�n?

Bien, para esta parte existen varias propuestas, pero la m�s interesante es un proyecto del grupo Apache que denominan XSP (eXtensible Server Pages). Para conocer un poco m�s de XSP vea el Cap�tulo 4

Como vemos, ya se explic� a grandes rasgos que el entorno de publicaci�n web basado en XML es la mejor soluci�n al problema planteado: Separar Contenido, L�gica y Presentaci�n. Es aqu� en donde entra el proyecto del grupo Apache llamado por ellos Apache Cocoon.

Importante

Es importante resaltar que esta soluci�n tiene un problema: Es muy poco madura y aun anda en proceso de prueba lo cual genera expectativas de todo tipo. Cocoon es hasta el momento entre este tipo de soluciones, la m�s desarrollada y cuenta con gran credibilidad en este momento.

Cap�tulo 2. Cocoon

2.1. �Qu� es Cocoon?

Cocoon es un sistema de publicaci�n Web, basado en XML/XSL. Cuenta con desarrollo total en Java por lo cual se puede ejecutar desde cualquier servidor que pueda contener Servlets; y al ser un Servlet cuenta con las ventajas de �stos, es decir, se ejecutan como threads de forma simult�nea en el mismo contexto y no tienen que llamar a m�todos auxiliares como lo hacen tecnolog�as del estilo CGI.

Cocoon es Open Source. Es bastante configurable y personalizable. Adem�s adopta caracter�sticas para escribir p�ginas de servidor en XML (XSPs). Permite diferenciar el procesamiento del documento para tenerlo en distintos formatos, dependiendo del tipo de software que hace la petici�n y cuenta con un sistema de cach� para tener un mejor rendimiento. Un elemento adicional y clave para tener en cuenta es que es un producto gratuito y por lo tanto no tendr� que gastar dinero para su adquisici�n.

Su usted desea separar contenido, presentaci�n y l�gica en su aplicaci�n, una buena alternativa es adoptar Cocoon.

2.1.1. Funcionamiento a nivel de usuario

Cuando un usuario hace una solicitud, en Cocoon ocurren una serie de fases que consisten en:

  1. El usuario solicita un documento de cualquier tipo al servidor.

  2. La solicitud se analiza para concluir si se puede atender o no. Si no se puede atender se produce un mensaje de error.

  3. Si se puede atender se analiza a qu� productor XML corresponde. Se genera un documento XML con el cual se trabajar�.

  4. Se extraen las instrucciones del XML generado en el paso anterior y �stas se le pasan al procesador apropiado para que se le apliquen al XML. Al procesar el XML podr�a salir un XML con m�s instrucciones que ser�n tratadas en alg�n otro ciclo.

  5. El XML procesado se le pasa al elemento que aplica el formato. Si el documento es un documento final,XML aplica el formato y le env�a el documento formateado al cliente. En el caso que el documento XML procesado, sea c�digo que deba ejecutarse (como en el caso de una XSP ya compilada), �ste se pasa como productor de XML y se vuelve a procesar hasta que se llega a un documento XML final.

2.2. Cocoon 1 Vs Cocoon 2

Cocoon est� siendo desarrollado por una parte del equipo Apache XML. Cocoon 2 tiene cambios tan significativos con respecto a Cocoon 1, que se podr�a decir casi que fue escrito de nuevo.

Los desarrolladores de Cocoon 2 dicen que lo que han hecho es aprender de lo que vivieron durante el desarrollo de Cocoon 1, y lo implementaron para mejorar la eficiencia y la escalabilidad del proyecto.

Cocoon 1 trabajaba sobre DOM (Document Object Model) para poder pasar los documentos XML entre componentes. El problema es que el trabajo con �rboles DOM se torna ineficiente ya que el procesamiento de un �rbol consume mucha m�s memoria que el documento XML original.

Cocoon 2 est� construido sobre el API SAX que es mucho m�s eficaz cuando se trata de manipular documentos XML.

Por otro lado, el manejo de la aplicaci�n cambia bastante de Cocoon 1 a Cocoon 2. Mientras que en Cocoon 1, en los documentos XML se deb�an incluir las instrucciones para hacer el procesamiento del documento (atando el documento XML a Cocoon), en Cocoon 2 se puede configurar para determinado fichero XML que transformaci�n debe aplic�rsele, fuera del mismo fichero. Note que �sto es una gran ventaja con respecto a la flexibilidad del sistema, ya que en la versi�n 1 de Cocoon la reutilizaci�n de c�digo se disminuye considerablemente y la capa que separa el contenido de la l�gica y la presentaci�n se vuelve casi imperceptible.

Cap�tulo 3. Estructura y arquitectura de Cocoon

En este apartado me dedicar� a hablar un poco de la estructura interna y arquitectura en la que se basa Cocoon.

3.1. Conceptos claves

Antes de entrar en detalles es recomendable mostrar tres conceptos claves de la estructura de Cocoon. �stos son:

Pipeline(o tuber�a)

La idea es dividir el procesamiento de un documento XML en varios pasos m�s elementales. Un pipeline consiste en una entrada seguida de un conjunto de procesos de tratado de la entrada y una salida. Realmente es un concepto muy sencillo pero a la vez muy potente y hace que la programaci�n sea m�s f�cil y m�s escalable.

Componentes del Pipeline

Son los que se encargan de llevar a cabo una tarea en particular en el pipeline como generar un documento XML, aplicar una transformaci�n o producir una salida, entre otros. Estos componentes se pueden personalizar y pueden ser creados por el propio desarrollador.

Existen cuatro grupos generales de componentes. �stos son:

Entradas del Pipeline

Son los generadores y los lectores (Ver Secci�n 3.1.1) .

Procesadores

Son los que llevan a cabo las transformaciones y las acciones (Ver Secci�n 3.1.1).

Salidas del Pipeline

Son los serializadores (Ver Secci�n 3.1.1).

Procesamiento Condicional

Es la parte encargada de hacer las selecciones y el proceso de match (Secci�n 7.1.1)

Atender una solicitud

Esto incluye una serie de pasos, como identificar de forma selectiva el pipeline correcto que debe atender la solicitud pedida, cerciorarse de que el pipeline se lleve a cabo y producir el resultado al cliente que hizo la solicitud.

3.1.1. Estructura

Estructuralmente hablando Cocoon est� compuesto de:

Productores

Son los ficheros fuentes de donde proviene el XML. Estos pueden ser est�ticos o din�micos (es decir creados mediante XSP). La operaci�n de un productor se basa en transformar los datos del fichero en eventos SAX.

Procesadores

Atrapan el XML de los productores para aplicarle diversos procesos, como por ejemplo hacer conectividad a una base de datos, aplicar transformaciones XSL a los documentos XML, convertir los XSP en clases Java, etc. Son el proceso principal del Pipeline. El m�s com�n es el transformador XSLT

Cuando de contenido din�mico se habla, entran las acciones, es decir, procesos que s�lo se pueden llevar a cabo y de los que s�lo se puede saber el resultado en tiempo de producci�n, tales como interacci�n con bases de datos, validaciones, env�o de correo electr�nico, etc.

Reactor

Es la central estructural. Extrae del XML del productor, las instrucciones para determinar qu� procesadores actuar�n en el documento.

Formateadores

Son el punto final en un Pipeline. Recogen la representaci�n interna del XML resultante (que est� dada en eventos SAX) y la preparan para enviar como respuesta al cliente en el formato adecuado.

El formateador o serializador m�s com�n es el serializador XML que simplemente obtiene los eventos SAX y los lleva a un documento XML.

La anterior informaci�n se puede apreciar con el siguiente gr�fico.

Figura 3-1. Cocoon desde un punto de vista estructural

3.1.2. Arquitectura

Figura 3-2. Arquitectura de Cocoon

Core Cocoon

Es el coraz�n de Cocoon. Encontramos un entorno para el control de sesiones, ficheros para configuraci�n de Cocoon, para hacer manejo de contextos, aplicar mecanismos de cach�, Pipeline, generaci�n, compilaci�n, carga y ejecuci�n de programas.

Cocoon Components

En esta capa encontramos los generadores de XML, transformadores de XML, matchers de ficheros y serializadores para formatear los ficheros.

Built-in Logicsheets

Son hojas l�gicas que necesita Cocoon para ficheros como sitemap, xsp, esql, request, response.

Site specific configuration, components, logicsheets and content

Es el nivel m�s externo en el cual un desarrollador puede hacer configuraci�n, creaci�n de componentes, creaci�n de hojas l�gicas y contenido definido por el usuario de Cocoon para su aplicaci�n

Cap�tulo 4. Cocoon y las XSPs

4.1. Introducci�n

Las XSPs manejan la misma idea de las JSPs, es decir, p�ginas de servidor, con lo cual se tiene dinamismo con posibilidad de conectividad a bases de datos y con las ventajas del XML.

Una XSP es simplemente un documento XML en donde se puede incluir contenido tanto est�tico como din�mico para generar XML de forma din�mica. Cabe anotar que el uso de taglibs se puede implementar sin problemas (es m�s, de manera m�s intuitiva que en JSP, ya que los taglibs son etiquetas XML) en las XSP, una evidencia adicional de las ventajas de esta nueva tecnolog�a.

La siguiente gr�fica muestra el flujo de operaci�n en una solicitud XSP.

Figura 4-1. Flujo en XSP

4.2. Tipos de p�ginas XSP

De acuerdo a la forma como se programan, las XSPs se pueden dividir en tres grupos:

  1. Con la l�gica embebida en la presentaci�n

  2. Con hojas de estilos

  3. Con bibliotecas etiquetas

4.2.1. XSP con la l�gica embebida en la presentaci�n

En este tipo de p�ginas se escribe el c�digo en la propia p�gina XML. �sta es la pr�ctica de programaci�n menos recomendada y no deber�a utilizarla nunca, ya que aunque puede funcionar, el mantenimiento se torna muy complicado y la reutilizaci�n se minimiza brutalmente.

Para hacer el tratamiento de este tipo de XSP, el procesador XSP analiza el XML y convierte la p�gina en un Servlet compilado. Esto lo hace llevando el XML a Java mediante un �rbol DOM. Una vez llevado a c�digo Java, se procesa y al resultado final se le aplica una transformaci�n XSLT para llevar el resultado final a una p�gina HTML.

Como podemos ver esta forma de programaci�n, degrada el c�digo XML ya que lo combina con el Java, por lo tanto la separaci�n entre contenido y presentaci�n de la cual hemos hablando no se hace presente. Este tipo de forma de programar no deber�a ser utilizada en ning�n caso a menos que sea estrictamente necesario (aunque a decir verdad nunca deber�a ser estrictamente necesaria).

4.2.2. XSP con hojas de estilos

Esta forma de programar las XSP es mucho m�s recomendable que la anterior. En �sta, la p�gina XSP original ser�a vista como un documento XML que se vale de hojas de estilos para aplicar la l�gica de la programaci�n, es decir el c�digo Java. Cuando el documento XML original es procesado, se le aplica la transformaci�n y como resultado se tiene una p�gina XSP con el c�digo embebido.

Note que en este caso el mantenimiento de la p�gina mejora bastante con respecto al modelo que se expuso anteriormente, sin embargo la reutilizaci�n es muy pobre ya que el c�digo fuente Java que se necesite para otra p�gina XSP se debe incluir en otra XSL distinta.

4.2.3. XSP con bibliotecas de etiquetas

La idea de esta forma de implementar XSP es tener en bibliotecas especializadas, etiquetas que se encarguen de ejecutar cierto proceso, cierta funci�n o procedimiento escrito en un lenguaje de programaci�n (como por ejemplo Java) para que dichas bibliotecas puedan ser incluidas mediante espacios de nombres en los ficheros XML que las necesitan y as� mismo se puedan utilizar las funciones que proveen dichas bibliotecas.

Estas bibliotecas deber�an agruparse por roles o por tipos de funciones o servicios que proveen.

Como vemos en este caso el problema que aun ten�amos, reutilizaci�n de c�digo se vuelve imperceptible y no existe, ya que las bibliotecas y los servicios que proveen son independientes del fichero XML que las utiliza.

4.3. Conectividad a bases de datos

Con las XSP y Cocoon se puede tener acceso a una bases de datos de cualquier tipo, con lo cual usted puede tener la persistencia de su aplicaci�n en un sistema manejador de bases de datos y aprovechar las ventajas tanto del manejador como de las XSP.

Para poder utilizar una XSP para conectarse a una base de datos, usted tiene que cargar el driver de su base de datos, definir las variables t�picas de conexi�n a base de datos, tales como url, nombre de usuario, contrase�a, etc.

Con XSP en Cocoon usted puede tener prepared statements, manejo de m�ltiples resultsets y pool de conexiones.

Nota

Para m�s informaci�n de XSP y acceso a Bases de Datos vaya a la Secci�n 8.2.2.

Cap�tulo 5. Paralelismo con Cocoon

Figura 5-1. WorkFlow en Cocoon

Como ya nos hemos podido dar cuenta el paralelismo con Cocoon se incrementa de forma enorme. Esto mejora tanto la calidad de los productos (ya que las personas se especializan en un �rea en particular) como los tiempos de desarrollo de trabajo y de respuesta de los mismos. Aqu� se explica como se puede hacer Workflow con Cocoon. En �ste se deben tener en cuenta estos 5 perfiles.

Gestores de Contenido

Estudian el tipo de contenido al cual se quieren o deben referir. Una vez que identifican los contenidos, notifican a los programadores para la construcci�n de taglibs. La especificaci�n de contenidos la reciben tambi�n los desarrolladores XSP y los dise�adores.

Programadores

Proporcionan taglibs que al ejecutarse generan el contenido acordado con los gestores.

Desarrolladores XML

Estructuran los contenidos en los XMLs que crean seg�n lo acordado con los gestores. Introducen contenido est�tico en las p�ginas y las etiquetas taglibs donde corresponda para el contenido din�mico.

Dise�adores

Se encargan de construir el esquema de la interfaz. Generan entonces la forma de presentaci�n de los datos de cada vista, de cada formato y cada uno de los elementos est�ticos.

Desarrolladores XSL

Se dedican a elaborar documentos XSL para obtener las vistas hechas por los dise�adores a partir de los XMLs hechos por los desarrolladores XML.

Cap�tulo 6. Instalaci�n de Cocoon 2

En este apartado nos adentramos en un campo un poco m�s denso, explicando c�mo hacer la instalaci�n de Cocoon.

6.1. Requisitos para la instalaci�n

Ya que Cocoon es una aplicaci�n Web hecha en Java, debe ejecutarse sobre un motor de Servlets. Como estamos hablando de Java, Cocoon puede ser ejecutado sobre cualquier motor de Servlets. Para este caso en particular se ha utilizado Tomcat 4.0.3

6.1.1. Instalaci�n de Tomcat

La instalaci�n de Tomcat es realmente muy sencilla.

Lo primero que debe hacer es descargar el instalador. �sto lo puede hacer desde este enlace en el cu�l encontrar� la �ltima versi�n de este producto de licencia libre. Para el momento en el que este documento estaba siendo elaborado la versi�n m�s reciente de Jakarta Tomcat era la 4.0.3 y ya exist�a una alfa para la versi�n 4.1.0

Una vez descargado el instalador, ejec�telo. Los pasos a seguir son bastante intuitivos y no presentan problema alguno.

En el directorio donde instal� Tomcat, es decir, donde est� la ra�z de la aplicaci�n, lo llamaremos CATALINA_HOME (CATALINA es el nombre del contenedor de Servlets de Tomcat, el cu�l tiene una implementaci�n totalmente distinta desde la versi�n 4).

Para subir y bajar Tomcat vaya al directorio CATALINA_HOME/bin. Ah� encontrar� dos scripts para llevar a cabo esta operaci�n (startup y shutdown respectivamente).

Tomcat se ejecuta por omisi�n en el puerto 8080, as� que una vez que haya arrancado Tomcat puede probar la instalaci�n abriendo en el navegador la direcci�n http://localhost:8080. Si la instalaci�n no tuvo problemas se le mostrar� una p�gina de bienvenida semejante a �sta:

Figura 6-1. Ventana de bienvenida de Tomcat

6.1.2. Ambiente Java

Para poder ejecutar tanto Tomcat como Cocoon usted necesita tener instalado el kit de desarrollo de Java el cual se encuentra actualmente en la versi�n 1.4.0 y puede ser descargado de forma gratuita desde este enlace.

6.2. Instalando Cocoon

6.2.1. Instalaci�n R�pida De Cocoon

De Cocoon se pueden obtener dos distribuciones. La que trataremos en esta parte es la distribuci�n en binario que puede ser descargada de este enlace. Con esta distribuci�n lo �nico que usted debe hacer es descargarla y descomprimirla en cualquier directorio. En el directorio que usted eligi� deber� haber quedado el fichero cocoon.war. Este fichero es el de la aplicaci�n Cocoon.

Para que Tomcat y Cocoon se puedan comunicar, usted debe copiar el cocoon.war en el directorio CATALINA_HOME/webapps e iniciar Tomcat.

Cuando usted inicia Tomcat puede darse cuenta que el fichero es descomprimido autom�ticamente en el directorio CATALINA_HOME/webapps/cocoon/, el cual llamaremos de ahora en adelante COCOON_HOME. Para probar si cocoon est� funcionando puede abrir la direcci�n http://localhost:8080/cocoon/ en el browser, en la cual debe mostr�rsele una p�gina de bienvenida de este estilo.

Figura 6-2. Ventana de bienvenida de Cocoon

6.2.2. Instalaci�n a partir de los fuentes

En ocasiones es recomendable tener una copia local del c�digo de Cocoon y compilar la aplicaci�n de forma local. Para �sto, lo que usted debe hacer es descargar el c�digo fuente de Cocoon. Esto lo puede realizar a trav�s del servidor de CVS (Current Versioning System) de Apache.

Primero det todo, usted debe tener instalado CVS. Si usted no lo ha instalado a�n en su m�quina, puede consultar el sitio web de CVS para m�s informaci�n.

En el momento que tenga instalado el CVS, ingrese al servidor de CVS de Apache de la siguiente forma:

$ cvs -d:pserver:anoncvs@cvs.apache.org:/home/cvspublic login

Cuando se le pregunte por una contrase�a escriba anoncvs. Luego escriba lo siguiente:

$ cvs -d:pserver:anoncvs@cvs.apache.org:/home/cvspublic -z3 checkout -r cocoon_20_branch xml-cocoon2

Una vez hecho esto se inicia la descarga de todo el c�digo necesario para la compilaci�n de Cocoon.

Cuando tenga los fuentes de Cocoon descargados, debe compilarlos para crear el fichero cocoon.war. Para empezar a ejecutar el proceso de compilaci�n utilice la siguiente instrucci�n: 

$ ./build.sh -Dinclude.webapp.libs=yes webapp

�sto crear� un directorio con el c�digo compilado, las bibliotecas y el fichero cocoon.war. Una vez termine el proceso copie el cocoon.war en el directorio CATALINA_HOME/webapps y reinicie Tomcat. De esta forma Cocoon estar� ejecut�ndose en http://localhost:8080/cocoon/.

Sugerencia

Si usted est� interesado en hacer pruebas con Cocoon es �til crear una aplicaci�n aparte para este fin. �sto lo puede hacer creando un directorio nuevo bajo CATALINA_HOME/webapps. Supongamos que a dicho directorio se le pone como nombre pruebasCocoon. Lo que usted debe hacer es copiar el fichero COCOON_HOME/cocoon.xconf y la carpeta COCOON_HOME/WEB-INF en CATALINA_HOME/webapps/pruebasCocoon/. �sto ya es suficiente para empezar a hacer sus pruebas y sus desarrollos ya que en WEB-INF est�n todas las clases necesarias para hacer que Cocoon pueda funcionar correctamente. Cree tambi�n su propio sitemap en CATALINA_HOME/webapps/pruebasCocoon(con lo cual no corre el riesgo de alterar los ejemplos y la documentaci�n que ya existan) y cargue su aplicaci�n en http://localhost:8080/pruebasCocoon/

Cap�tulo 7. Configuraci�n y personalizaci�n en Cocoon

Cocoon cuenta con varios ficheros para hacer la configuraci�n y personalizaci�n del mismo. Entre �stos, el m�s importante a nivel de usuario es el sitemap.xml. En este fichero se lleva a cabo el proceso de selecci�n y match.

7.1. El sitemap

7.1.1. Selecci�n y match en Cocoon

Casi todo Pipeline tiene secciones condicionales. Una secci�n condicional sirve para decirle a Cocoon qu� tipo de solicitudes puede atender y c�mo debe atenderlas.

Los matcher y los selectores desempe�an la misma funci�n en Cocoon, condicionar un requerimiento como lo har�a una instrucci�n if y analizar si la condici�n se cumple o no para poder llevar a cabo una tarea en particular. La diferencia entre un selector y un matcher radica que mientras el primero enumera todos los posibles valores, el segundo trabaja con expresiones regulares para evaluar la condici�n

7.1.2. Funcionalidad del sitemap

En el sitemap es en donde se lleva a cabo la parte Web de Cocoon. �stee tiene dos funciones b�sicas:

7.1.3. Estructura b�sica del sitemap

El sitemap puede encontrase en el directorio de la aplicaci�n Web Cocoon, es decir es COCOON_HOME/sitemap.xml

El sitemap tiene tres partes b�sicas. La primera es la declaraci�n del espacio de nombres, la segunda la declaraci�n de los componentes y la tercera es la declaraci�n de los pipelines. Un fichero sitemap.xml es entonces de este estilo:

Ejemplo 7-1. Ejemplo de un sitemap b�sico

   
<map:sitemap
  xmlns:map="http://apache.org/cocoon/sitemap/1.0">

  <map:components>
    <map:generators/>
    <map:readers/>
    <map:transformers/>
    <map:actions/>
    <map:serializers/>
    <map:matchers/>
    <map:selectors/>
  </map:components>

  <map:pipelines>
  </map:pipelines>

</map:sitemap>

Cap�tulo 8. Desarrollo en Cocoon

8.1. Contenido est�tico

Para poder implantar sus aplicaciones de contenido est�tico en Cocoon usted debe seguir varios pasos:

Vamos a suponer que usted tiene un fichero para presentar informaci�n acerca de su empresa y es la p�gina inicial de la misma. En este caso ese fichero, por ser el inicial lo llamaremos index.

Esto quiere decir que deber� tener un fichero llamado index.xml (con su respectiva DTD, supongamos su nombre como index.dtd) en el cual tendr� la informaci�n necesaria para mostrar la p�gina principal de la empresa y adem�s deber� tener un fichero index.xsl con el cual se aplicar� formato HTML al documento XML.

Sugerencia

Es de anotar que no tiene porque crear un fichero XSL por cada fichero XML que tenga en su aplicaci�n, s�lo que para efectos de un ejemplo de muestra basta con hacerlo de esta forma.

El fichero sitemap.xmap de Cocoon nos servir� para decirle a Cocoon d�nde encontrar los fuentes, como procesarlos y c�mo presentarlos. Este fichero lo puede encontrar en COCOON_HOME/.

Lo que tiene que hacer es editar este fichero para a�adirle un pipeline con el cual se pueda atender una solicitud que muestre el fichero que desea presentar.

Para nuestro ejemplo vamos a suponer que el fichero index.xml se encuentra en la ruta $MiAplicacion/XML/, que el fichero index.dtd se encuentra en la ruta $MiAplicacion/DTD y el fichero index.xsl que transforma el XML en un HTML se encuentra en la ruta $MiAplicacion/XSL/HTML/

Atenci�n

Tenga en cuenta la ruta en la que guarda su DTD para que el fichero XML la pueda reconocer.

Sugerencia

Es recomendable manejar rutas relativas en la declaraci�n de la DTD para mejorar la portabilidad de la aplicaci�n.

Sugerencia

Cuando este construyendo aplicaciones en Cocoon es bastante �til definir directorios para guardar sus ficheros XML, XSL, sus DTD, sus fuentes, sus clases, etc.

Bien, el pipeline que usted debe a�adir es de este estilo:

Ejemplo 8-1. C�digo para funcionamiento de un solicitud de un fichero XML presentado como un HTML

    
   <map:match pattern="MiAplicacion/index.html">
    <map:generate type="file" src="$MiAplicacion/XML/index.xml"/>
    <map:transform src="$MiAplicacion/XSL/HTML/index.xsl"/>
   </map:match>

Analicemos un poco m�s detalladamente esto. La l�nea match pattern="MiAplicacion/index.html" le indica a Cocoon que cuando llegue una solicitud del tipo http://localhost:8080/cocoon/MiAplicacion/index.html la atienda obteniendo los datos del fichero XML $MiAplicacion/XML/index.xml (esto se le indica mediante la l�nea generate type="file" src="$MiAplicacion/XML/index.xml") y aplic�ndole la transformaci�n dada por el fichero XSL ubicado en $MiAplicacion/XSL/HTML/index.xsl (lo cual se le dice mediante la l�nea transform src="$MiAplicacion/XSL/HTML/index.xsl").

Nota

Para un ejemplo un poco m�s detallado consulte el Ap�ndice A.

8.2. Contenido Din�mico

8.2.1. Dando l�gica con programaci�n en Java

Atenci�n

En Construcci�n

8.2.2. Acceso a bases de datos

Para acceder una base de datos usted debe tener en cuenta tres pasos:

  1. Configurar el Data Source para acceder la base datos.

    �sto lo debe hacer en al fichero cocoon.xconf a�adiendo las siguientes l�neas en la etiqueta datasources

    Ejemplo 8-2. C�digo para definir un Data Source para acceso a una base de datos

        
    <jdbc name="nombreBD">
      <pool-controller min="0" max="10"/>
      <dburl>urlParaConexionABaseDeDatos</dburl>
      <user>NombreUsuario</user>
      <password>contrase�aUsuario</password>
    </jdbc>

    Donde nombreBD es el nombre que se le dar� al Data Source, NombreUsuario es el nombre de un usuario registrado en la Base de Datos con el cual se llevar� a cabo la conexi�n y contrase�aUsuario es la contrase�a del usuario NombreUsuario con la cual se validar� dicho usuario

  2. Configurar el fichero web.xml

    Para que cargue el driver e incluir el driver de tal forma que Cocoon tenga un lugar desde donde cargarlo.

    Para configurar el web.xml con ayuda de la etiqueta init-param y la etiqueta hija de �sta, param-name con valor load-class enunciando dentro de esta �ltima el nombre del driver y separando el nombre de los distintos drivers por coma o espacio. Por ejemplo, para incluir un driver para Oracle y otro para IBM WebSphere las l�neas de c�digo que deber�an verse en el fichero web.xml ser�an:

    Ejemplo 8-3. C�digo para cargar clases para acceso a bases de datos.

        
    <init-param>
      <param-name>load-class</param-name>
      <param-value>

        <!-- Para Oracle: -->
        oracle.jdbc.driver.OracleDriver 

        <!-- Para IBM WebSphere: -->
        com.ibm.servlet.classloader.Handler 

	<!-- For parent ComponentManager sample:
        org.apache.cocoon.samples.parentcm.Configurator
        -->
      </param-value>
    </init-param>

    Nota

    Si usted est� utilizando la Base de Datos que viene con Cocoon (hsql)este paso no es necesario

  3. Si va a utilizar hsql debe a�adir las instrucciones de base de datos que necesite su aplicaci�n, tales como sentencias de autenticaci�n, de creaci�n de tablas, de inserciones de datos, etc. Esto lo debe hacer en el fichero cocoondb.script ubicado en la ruta COCOON_HOME/WEB-INF/db/

    Para nuestro caso se a�adieron las siguientes l�neas:

    Ejemplo 8-4. Ejemplo de C�digo de Base de Datos necesario a incluir con la Base de Datos hsql

    CREATE USER usuario PASSWORD "contrasena" ADMIN
CONNECT USER usuario PASSWORD "contrasena"
CREATE TABLE PRUEBAS(ID INTEGER,NAME VARCHAR,UNIQUE(ID))
INSERT INTO PRUEBAS VALUES(1,'Prueba 1')
INSERT INTO PRUEBAS VALUES(1,'Prueba 2')

    con lo cual se est� dando la posibilidad al usuario usuario con contrase�a contrasena hacer operaciones sobre la tabla Pruebas, la cu�l tiene 2 registros.

8.2.2.1. Etiquetas SQL y ESQL

Para la construcci�n de p�ginas XSP, contamos con dos tipos de etiquetas, SQL y ESQL.

La diferencia radica en que ESQL siendo m�s nuevo, presta mayores funcionalidades como combinar distintos tipos de hojas de estilos, soporte para prepared statements y manejo de varios resultsets en una sola sentencia, entre otras cosas. De ah� su nombre, Extended SQL.

A continuaci�n presentar� dos ejemplos con estas tecnolog�as para analizar y tener en cuenta c�mo funciona cada una.

8.2.2.1.1. Ejemplo con uso de etiqueta SQL

  1. A�ada un pipeline en el sitemap que sea de la forma:

    Ejemplo 8-5. Pipeline necesario para una XSP con etiquetas SQL y acceso a una Base de Datos

        
   <map:match pattern="MiXSP/MiEjemploXspSql">
    <map:generate src="$MiAplicacion/MiEjemploXspSql"/>
    <map:transform type="sql">
      <map:parameter name="use-connection" value="MiConexion"/>
    </map:transform>
    <map:transform src="stylesheets/simple-sql2html.xsl"/>
    <map:serialize/>
   </map:match>

    Nota

    Para este caso, estamos indicando que el transformador es de tipo sql y que se debe usar una conexi�n llamada MiConexion. Es decir, estamos indicando desde el sitemap el nombre de la conexi�n

Teniendo en cuenta todo lo anteriormente expuesto, se pueden escribir p�ginas con etiquetas sql.

Ejemplo 8-6. C�digo de una XSP con conexi�n a Base de datos con etiqueta SQL

    
	<?xml version="1.0"?>

	<page xmlns:sql="http://apache.org/cocoon/SQL/2.0">

	 <title>Una Prueba con SQL</title>
	 <content>
	  <para>Una p�gina con SQL</para>

	  <execute-query xmlns="http://apache.org/cocoon/SQL/2.0"> 
	   <query>
		select id, name from PRUEBAS
	   </query>
	   <execute-query>
	    <query>
		select id, name from PRUEBAS
	    </query>
	   </execute-query>
	  </execute-query>

	 </content>
	</page>
8.2.2.1.2. Ejemplo con uso de etiqueta ESQL

  1. A�ada un pipeline en el sitemap que sea de la forma:

    Ejemplo 8-7. Pipeline necesario para una XSP con etiquetas ESQL y acceso a una Base de Datos

        
   <map:match pattern="MiXSP/MiEjemploXspEsql">
    <map:generate type="serverpages" src="$MiAplicacion/MiEjemploXspEsql.xsp"/>
    <map:transform src="stylesheets/dynamic-page2html.xsl">
    </map:transform>
    <map:serialize/>
   </map:match>

    Nota

    Para este caso, estamos indicando que el generador es de tipo serverpages.

Teniendo en cuenta todo lo anteriormente expuesto, se pueden escribir p�ginas con etiquetas sql.

Ejemplo 8-8. C�digo de una XSP con conexi�n a Base de datos con etiqueta ESQL

    
	<?xml version="1.0" encoding="ISO-8859-1"?>

	<xsp:page
		  language="java"
		  xmlns:xsp="http://apache.org/xsp"
		  xmlns:esql="http://apache.org/cocoon/SQL/v2"
	>

	  <page>

	   <title>Una prueba con ESQL</title>

	   <content>

	   <esql:connection>
	     <esql:pool>MiConexion</esql:pool>
	     <esql:execute-query>
	       <esql:query>select * from PRUEBAS</esql:query>
	       <esql:results>
		 <esql:row-results>
		   <para><esql:get-string column="name"/></para>
		 </esql:row-results>
	       </esql:results>
	     </esql:execute-query>
	   </esql:connection>

	   </content>
	  </page>
	</xsp:page>

Nota

Note que en este caso, es en la p�gina XSP en donde se define el nombre de la conexi�n.

Como usted ya se habr� podido dar cuenta, la diferencia en implementaci�n entre ambas tecnolog�as es m�nima. Dependiendo de las necesidades de su aplicaci�n puede escojer entre ambas, teniendo en cuenta las potencialidades de ESQL y el desconocimiento que existe a�n por su poco tiempo de vida en el mundo del software.

8.3. Deployment en Cocoon

8.3.1. Condiciones m�nimas

Es muy com�n tener varias aplicaciones bajo Cocoon, en cuyo caso es recomendable tener ficheros de configuraci�n aparte para el momento en el que se debe hacer deployment a cada aplicaci�n. Esto mejora la portabilidad y la escalabilidad de los productos.

Para poder lograr esto Cocoon provee una herramienta poderosa, el concepto de SubSitemap.

Un subsitemap no es m�s que un fichero sitemap para una parte en particular de una aplicaci�n de Cocoon.

Para poder utilizar esta t�cnica s�lo se deben tener en cuenta dos cosas:

Para esta parte voy a trabajar con el ejemplo de la secci�n referente a contenido est�tico desarrollada al inicio de este cap�tulo (ver ).

Para esta aplicaci�n vamos a construir entonces un subsitemap en el directorio $MiAplicacion/, es decir, el fichero quedar� en la ruta $MiAplicacion/sitemap.xmap.

8.3.2. Inclusi�n de un subsitemap en el sitemap de Cocoon

En el fichero sitemap.xmap de Cocoon se deben a�adir las siguientes l�neas:

Ejemplo 8-9. C�digo para incluir un subsitemap

    
   <map:match pattern="MiAplicacion/*"> 
    <map:mount uri-prefix="MiAplicacion" check-reload="yes" src="$MiAplicacion/sitemap.xmap" 
	reload-method="synchron"/> 
   </map:match>

Bien, miremos un poco este c�digo para comprenderlo mejor:

Sugerencia

En ambientes de desarrollo es bastante �til tener la opci�n de que cada vez que se haga un cambio, �ste se pueda reflejar de forma inmediata. Sin embargo en ambientes de producci�n es mejor tener configurado que los cambios se reflejen una vez el servicio se baje y se vuelva a restaurar; �sto es para no perjudicar a los usuarios de la aplicaci�n quienes podr�an tener la impresi�n de una aplicaci�n lenta.

Mejor a�n si crea una copia de la aplicaci�n, para tener una en producci�n y otra en desarrollo para hacer las pruebas. Para conocer como crear una aplicaci�n en Cocoon consulte la sugerencia que est� al final de la secci�n Secci�n 6.2.2

8.3.3. C�digo del subsitemap

El subsitemap, el cual debe estar ubicado como ya se dijo en la ruta $MiAplicacion/ debe seguir el siguiente estilo:

Ejemplo 8-10. C�digo b�sico de un subsitemap

    
<?xml version="1.0"?>
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
	<!-- =========================== Components ================================ -->
	<map:components>
		<map:generators default="file"/>
		<map:transformers default="xslt"/>
		<map:readers default="resource"/>
		<map:serializers default="html"/>
		<map:selectors default="browser"/>
		<map:matchers default="wildcard"/>

	</map:components>
	<!-- =========================== Pipelines ================================= -->
	<map:pipelines>
		<map:pipeline>

                        <map:match pattern="index.html">
                               <map:generate type="file" src="$MiAplicacion/XML/index.xml"/>
                               <map:transform type="xslt" src="$MiAplicacion/XSL/HTML/index.xsl"/>
                        </map:match>

			<map:handle-errors>
				<map:transform src="../stylesheets/system/error2html.xsl"/>
				<map:serialize status-code="500"/>
			</map:handle-errors>
		</map:pipeline>
	</map:pipelines>
</map:sitemap>

Miremos un poco este subsitemap:

Ap�ndice A. Formato de reuni�n semanal

A.1. Introducci�n

En el presente documento se introducir�n algunos de los t�rminos comunes en la terminolog�a XML y para ello se utilizar� como ejemplo, unos formatos de reuniones semanales de Ingenier�a de Software.

El formato de reuni�n semanal naci� como una necesidad de registrar informaci�n necesaria para llevar un registro y un historial de reuniones de forma estructurada y con unos par�metros y lineamientos identificados ya de antemano.

Este formato se implement� como un documento XML para poder tenerlo de forma estructurada, aprovechar las ventajas propias del XML y conocer un poco esta tecnolog�a.

Para las personas que no est�n familiarizadas con la tecnolog�a XML, en este documento se da una breve descripci�n de lo que es una DTD (Secci�n A.3.2.1), de lo que es un documento XML (Secci�n A.3) y de lo que es una XSL (Secci�n A.4) junto con un ejemplo de cada una de estas definiciones aplicadas al formato que tenemos como tema principal.

Importante

Este documento s�lo pretende ser un peque�o "abrebocas" de lo que son estas tecnolog�as punta. Es muy b�sico y la explicaci�n est� pensada para personas con muy pocos conocimientos.

A.2. Descripci�n formato de reuni�n semanal

En el formato de reuni�n semanal se pueden identificar tres componentes: informaci�n general de la reuni�n, agenda de la reuni�n e informes por rol.

Cabe anotar que mientras la informaci�n general es de car�cter obligatorio, la agenda y los informes por rol pueden o no aparecer en el documento, pero si aparecen ser� s�lo una vez.

A continuaci�n se describen estos tres elementos

A.2.1. Elementos del formato de reuni�n semanal

A.2.1.1. Informaci�n General

La informaci�n general en el formato es de car�cter obligatorio. En �ste se registra el sitio o lugar en donde se hizo la reuni�n, la fecha, la hora en la cual empez� la reuni�n en cuesti�n, la hora en que finaliz� la misma, el secretario de la reuni�n quien es el que se encarga de registrar la informaci�n en el momento de la reuni�n y los asistentes de la reuni�n.

A excepci�n del asistente, los dem�s items descritos son obligatorios y van de forma �nica. Los asistentes aunque es un dato obligatorio, tienen la particularidad de que pueden ser uno o varios.

A.2.1.2. Agenda

Como ya se dijo la agenda en el formato es de car�cter opcional, pero s�lo puede aparecer una vez. En �sta se registran los aspectos tratados contando por cada uno su respectiva descripci�n y sus propuestas. En cada reuni�n se deben tratar uno o m�s aspectos y por cada uno se pueden o no hacer varias propuestas. Una propuesta puede ser aprobada y puede tener una decisi�n.

A.2.1.3. Informes Por Rol

Esta parte es de car�cter opcional y en el caso de que aparezca s�lo puede hacerlo una vez. Aqu� se almacenan las anotaciones que puede hacer el l�der del proyecto o el personal de calidad, el de planificaci�n, soporte o desarrollo. Tambi�n se registra el rol de esa persona.

A.3. XML

A.3.1. �Qu� es?

No es m�s que un conjunto de reglas para definir etiquetas sem�nticas para organizar un documento.

La tecnolog�a XML es realmente sencilla y tiene alrededor otras tecnolog�as que la complementan y la hacen m�s grande y con posibilidades mayores. Entre estas se encuentran XSL y XSP.

A.3.2. Ejemplo XML con el formato de reuni�n semanal de Ingenier�a de Software

A.3.2.1. DTD del formato de reuni�n semanal

A.3.2.1.1. �Que es una DTD?

DTD es la sigla de Document Type Definition (Definici�n de Tipo de Documento).

Es un fichero l�gico que contiene la definici�n formal de un tipo de documento en particular

En este se describen los nombres de los elementos, donde pueden aparecer y la interrelaci�n entre ellos. Con �ste se puede validar el documento XML.

A.3.2.1.2. DTD del formato de reuni�n semanal

El fuente de esta DTD la puede descargar desde este enlace.

Ejemplo A-1. Ejemplo de una DTD para el formato de reuni�n semanal

 
<!ELEMENT reunionSemanal (informacionGeneral, agenda?, informesPorRol?)>

<!ELEMENT informacionGeneral (sitio, fecha, horaInicio, horaFin, secretario, asistente+)>
<!ELEMENT sitio (#PCDATA)>
<!ELEMENT fecha (#PCDATA)>
<!ELEMENT horaInicio (#PCDATA)>
<!ELEMENT horaFin (#PCDATA)>
<!ELEMENT secretario (#PCDATA)>
<!ELEMENT asistente (#PCDATA)>

<!ELEMENT agenda (aspectos)>
<!ELEMENT aspectos (aspecto+)>
<!ELEMENT aspecto (descripcion, propuestas?)>
<!ELEMENT descripcion (#PCDATA)>
<!ELEMENT propuestas (propuesta+)>
<!ELEMENT propuesta (textoPropuesta, decision?)>
<!ATTLIST propuesta aprobado (Si | No) "No">
<!ELEMENT textoPropuesta (#PCDATA)>
<!ELEMENT decision (#PCDATA)>

<!ELEMENT informesPorRol (informePorRol+)>
<!ELEMENT informePorRol (#PCDATA)>
<!ATTLIST informePorRol rol (lider | calidad | planeacion | soporte | desarrollo) #REQUIRED>

A.3.2.2. XML del formato de reuni�n semanal

Aqu� podemos apreciar un ejemplo de un posible documento XML del formato de reuni�n semanal.

Puede obtener el fuente de este ejemplo haciendo click aqu�.

Ejemplo A-2. Ejemplo de un documento XML para el formato de reuni�n semanal

<?xml version="1.0" standalone="no"?>
<!DOCTYPE reunionSemanal SYSTEM "reunionSemanal.dtd">
<reunionSemanal> 
  <informacionGeneral> 
	 <sitio> Oficina W302 </sitio> 
	 <fecha> 27 de Febrero de 2002 </fecha> 
	 <horaInicio> 4:00 pm </horaInicio> 
	 <horaFin> 5:32 pm </horaFin> 
	 <secretario> Juan Torres </secretario> 
	 <asistente> Sa�l Zarrate Cardenas </asistente> 
	 <asistente> Juan Pablo Quiroga </asistente> 
	 <asistente> Jaime Irving D�vila </asistente> 
  </informacionGeneral> 
  <agenda> <aspectos> 
	 <aspecto> 
		<descripcion> Practicar DTD, XML </descripcion> 
		<propuestas> 
		  <propuesta aprobado="No"> 

			 <textoPropuesta> Desarrollar un ejemplo con el Formato de Lanzamiento
				de Ingenieria de Software </textoPropuesta> 
			 <decision> Como ya se present� el Formato de
     de Lanzamiento de Ingenieria de Software, 
					no hay que documentarlo </decision> 
		  </propuesta> 
		  <propuesta aprobado="Si"> 
			 <textoPropuesta> Desarrollar un ejemplo con el Formato de Reuni�n
				Semanal de Ingenieria de Software </textoPropuesta> 
		  </propuesta> 
		</propuestas> 
	 </aspecto> 
	 <aspecto> 
		<descripcion> Practicar XSL </descripcion> 
		<propuestas> 
		  <propuesta aprobado="Si"> 
			 <textoPropuesta> Desarrollar un ejemplo con el XML del Formato de
				Reuni�n Semanal de Ingenieria de
     Software para presentaci�n en html
			</textoPropuesta> 
		  </propuesta> 
		</propuestas> 
	 </aspecto> 
	 <aspecto> 
		<descripcion> Practicar DocBook </descripcion> 
		<propuestas> 
		  <propuesta aprobado="Si"> 
			 <textoPropuesta> Documentar el desarrollo del XML y el XSL del
				Formato de Reuni�n de Ingenieria de
     Software </textoPropuesta>
		  </propuesta> 
		</propuestas> 
	 </aspecto> </aspectos> 
  </agenda> 
  <informesPorRol> 

	 <informePorRol rol="planeacion"> 
		Se cumpli� con las expectativas de las metas planeadas
	 </informePorRol> 
	 <informePorRol rol="soporte"> 
		Se dieron vinculos de Internet para poder tener ayudas en el desarrollo
		de los temas
	 </informePorRol> 
	 <informePorRol rol="desarrollo"> 
		El trabajo acordado es interesante y cumple con lo buscado
	 </informePorRol> 

  </informesPorRol> 

</reunionSemanal>

A.4. XSL

XSL es el acr�nimo de eXtensible Style Language (Lenguaje de Estilo eXtensible).

A.4.1. Algunos aspectos de XSL

A.4.1.1. �Qu� es XSL?

Es una Tecnolog�a XML de hojas de estilos que sirve para mostrar documentos XML, es decir, darles formato de presentaci�n.

A.4.1.2. �Para qu� sirve?

La tecnolog�a XSL sirve para transformar documentos XML en otros XML. �ste, permite la manipulaci�n de la informaci�n XML. XSLT XSL Transformation.

Tambi�n sirve para definir c�mo acceder cierto punto de la estructura de un documento. XPath.

Por otro lado, tiene la capacidad de definir el formato que deben tomar los objetos dentro de un documento XML. XSLFXSL Format.

A.4.1.3. �De qu� se trata?

En un documento XSL se describe un conjunto de reglas para aplicarse en documentos XML, reglas encaminadas a la presentaci�n del documento XML.

A.4.1.4. Ejemplo de XSL con el formato de reuni�n semanal de Ingenier�a de Software para salida en HTML

Para obtener el fuente XSL puede hacer click en este enlace.

Ejemplo A-3. Ejemplo de una XSL para el formato de reuni�n semanal

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

	<xsl:template match="/reunionSemanal">
		<HTML>
			<HEAD>
				<TITLE>
					Acta <xsl:apply-templates
					select="informacionGeneral/fecha"/>
				</TITLE>
			</HEAD>
			<BODY text="#000000" vLink="#840084"
			aLink="#0000ff" link="#0000ff"
			bgColor="#ffffff">
				<B>
					<font size="6">
						Acta
						<xsl:apply-templates
						select="informacionGeneral/fecha"/>
					</font>
					<BR></BR>
					<BR></BR>
					<font size="4">
						<xsl:apply-templates
						select="informacionGeneral/secretario"/>
					</font>
					<BR></BR>
					<BR></BR>
					<HR></HR>
					<BR></BR>
					<BR></BR>
					Tabla de Contenido
				</B>
				<BR></BR>
				<UL>
					<A href="#items">Items a discutir</A>
					<BR></BR>
					<A href="#decisionesTomadas">Decisiones tomadas</A>
					<BR></BR>
					<A href="#reportesDeRol">Reportes de rol</A>
				</UL>
				<HR></HR>
				<BR></BR>
				<B>
					<FONT SIZE="6">
						<A name="#items">Items a discutir</A>
					</FONT>
				</B>

				<BR></BR>
				<xsl:apply-templates select="agenda/aspectos"/>

				<HR></HR>
				<B>
					<FONT SIZE="6">
						<BR></BR>
						<A
						name="#decisionesTomadas">Decisiones
						Tomadas</A>
					</FONT>
				</B>

				<BR></BR>

				<xsl:apply-templates
				select="agenda/aspectos/aspecto/propuestas/propuesta"/>


				<HR></HR>
				<B>
					<FONT SIZE="6">
						<BR></BR>
						<A name="#reportesDeRol">Reportes de rol</A>
					</FONT>
				</B>

				<xsl:apply-templates select="informesPorRol"/>

			</BODY>
		</HTML>
	</xsl:template>

	<xsl:template match="fecha">
		<xsl:value-of select='.'/>
	</xsl:template>

	<xsl:template match="secretario">
		<xsl:value-of select='.'/> 
	</xsl:template>

	<xsl:template match="aspectos">
		<xsl:apply-templates select="aspecto"/>
	</xsl:template>

	<xsl:template match="aspecto">
		<UL>
			<LI>
				<xsl:value-of select="descripcion"/>
			</LI>
		</UL>
	</xsl:template>

	<xsl:template match="propuesta">
		<xsl:choose>
			<xsl:when test='decision!=""'>
				<UL>
					<LI>
						<xsl:value-of select="decision"/>
					</LI>
				</UL>
			</xsl:when>
		</xsl:choose>
	</xsl:template>

	<xsl:template match="informesPorRol">
		<xsl:apply-templates select="informePorRol"/>
		<BR>
		</BR>
	</xsl:template>

	<xsl:template match="informePorRol">
		<UL>
			<LI>
				Reporte de 
					<xsl:value-of select="@rol"/>:  
					<xsl:value-of select='.'/>
			</LI>
		</UL>
	</xsl:template>

</xsl:stylesheet>

A.5. Usando el formato de reuni�n semanal en Cocoon

Para usar el formato de reuni�n semanal en Cocoon, usted b�sicamente tiene que seguir los siguiente pasos:

  1. Guardar el fichero XML y su DTD en el directorio que usted escoja. Para nuestro ejemplo lo haremos en la ruta $ReunionSemanalHome/XML.

  2. Guardar el fichero XSL para la transformaci�n del documento XML en uno HTML en cualquier carpeta. Para nuestro ejemplo lo haremos en la ruta $ReunionSemanalHome/XSL/HTML.

  3. En el fichero sitemap.xml de Cocoon a�ada un Pipeline de este estilo:

    Ejemplo A-4. C�digo para a�adir un pipeline que cargue el formato de reuni�n semanal

        
   <map:match pattern="MiAplicacion/FormatoDeReunionSemanal.html">
     <map:generate src="$ReunionSemanalHome/XML"/>
     <map:serialize type="xml"/>
   </map:match>

  4. Por �ltimo inicie su servidor de Servlets y cargue el documento. Para el caso de Apache Tomcat puede cargar el documento en http://localhost:8080/cocoon/MiAplicacion/FormatoDeReunionSemanal.html.

    Deber�a cargarle algo como:

    Figura A-1. Formato de reuni�n semanal en Cocoon

Atenci�n

Tenga en cuenta la ruta en la que guarda su DTD para que el fichero XML la pueda reconocer.

Sugerencia

Es recomendable manejar rutas relativas en la declaraci�n de la DTD para mejorar portabilidad de la aplicaci�n.

Sugerencia

Cuando est� construyendo aplicaciones en Cocoon es bastante �til definir directorios para guardar sus ficheros XML, XSL, sus DTD, sus fuentes, sus clases, etc.