Tutorial sobre Cocoon
Versión: 1.3, Marzo, 2003

Versión 1.0: Juan Julián Merelo Guervós
Web: http://geneura.ugr.es/~jmerelo, Mail: jmerelo@geneura.ugr.es
Versión 1.3: Víctor Manuel Rivas Santos
Web: http://wwwdi.ujaen.es/~vrivas, Mail: vrivas@ujaen.es
inicioGeNeuracursos

(C) GeNeura Team
Web: http://www.geneura.org, Mail: todos@geneura.ugr.es

Introducción

Cocoon es un entorno de publicación y transformación de documentos XML basado en Java. Cocoon funciona como un servlet, o sea, que en principio, se podrá ejecutar desde cualquier servidor que pueda contener servlets, tales como el Apache, que es el mejor con diferencia, el Internet Information Server, o, incluso, si me apuráis, el Roxen, aunque no he oido a nadie que haya conseguido hacer funcionar Cocoon con Roxen.

Los servlets son hebras en Java, que se ejecutan en el mismo contexto que el servidor; por lo tanto, es más rápido de ejecutar que otros métodos tales como los CGIs; y además, son persistentes, o sea que no hace falta cargarlos. Para más información, se puede mirar la FAQ de los servlets.

El nombre de Cocoon viene de la película y se le ocurrió al autor inicial de Cocoon, Stefano Mazocchi, porque precisamente después de ver dicha película decidió hacer un entorno de publicación basado en XML, cuando casi nadie tenía todavía claro qué era eso del XML. Por eso ha tenido tanto éxito y hoy en día es uno de los más completos.

La versión actual más estable, y la que usaremos es la 1.8.2. Ya hay betas de la siguiente versión, la 2.0, que permitirá transformaciones más completas a partir de los URL, e incorporará los últimos estándares. Aún es difícil trabajar con ella y se debe usar más para experimentar que para entornos profesionales.

La principal diferencia, según los propios autores, es que la versión 1.x se ha realizado para demostrar que es un proyecto viable y para mostrar sus aplicaciones más directas.No obstante hay multitud de sitios que utilizan Cocoon para servir sus páginas. Por su parte, la versión 2.x está pensada para dar soluciones profesionales y para ser realmente funcional, incorporando mejor manejo de memoria, posibilidad de gestionar sitios complejos bajo una nueva filosofía que divide totalmente las fases de gestión, creación de software, creación de contenidos y creación de apariencias de un sitio proveedor de información. Como se ha dicho, aún está en fase beta.

La distribución de Cocoon permite hacer lo siguiente:

El trabajo que se lleva a cabo con un documento escrito en XML se realiza a lo largo de tres fases:

  1. Creación de contenidos XML. Esta parte la lleva a cabo el usuario bien usando un editor de texto o mediante algún otro mecanismo más sofisticado..
  2. Servicio del fichero XML. Lo realiza Cocoon, e incluye la ejecución de los programas incrustados (si se trata de un XSP) en dicho fichero.
  3. Creación el documento aplicando las hojas de estilo. Lo hacen terceros programas invocados por Cocoon. Dichos programas formatean el documento al tipo de salida requerido: HTML, XHTML, WML, PDF, o XML.

Entrando un poco más en detalle, la tarea que realiza Cocoon consiste básicamente en:

  1. Recuperar el URI solicitado.
  2. Detectar qué tipo de fichero es (HTML, texto, XML sin procesamiento, XML con procesamiento, etc.)
  3. Realizar el procesamiento indicado, ya sea mediante la ejecución de instrucciones XSL insertadas en el documento, bien mediante la invocación a terceros programas que parsean y generan nuevos documentos a partir del documento XML inicial.
  4. Devolver al cliente que ha hecho la petición el/los documento/s resultante/s que se han aplicado al fichero.

Instalando el Tomcat

Se ha dicho en el punto anterior que Cocoon funciona como un servlet. Para poder utilizar un servlet en un ordenador es necesario que se le haga una invocación y se le pasen ciertos parámetros. Esto no es posible si no tenemos, en el ordenador que alberga un servlet, un programa servidor de servlets, el cual permita llamarlos, ejecutarlos y recuperar la salida que proporcionan.

El contenedor o servidor de servlets que hemos elegido es Tomcat, que es parte del proyecto Jakarta de la compañía Apache y está considerado como el mejor de los que existen. Además, es gratis.

Quede claro pues que antes de instalar Cocoon hemos de instalar Tomcat.

Para empezar, hay que bajárselo. Esto se puede hacer desde dos sitios, principalmente:

Hay varias versiones en danza de Tomcat, pero nosotros usaremos la 3.2.3 que es la más estable hasta el momento (te la puedes bajar desde mi propia cuenta), aunque la 3.3 está muy avanzada e incluso la 4.0 ya superó la fase alfa hace tiempo..

A partir de ahora, todas las instrucciones de instalación serán para una máquina con el sistema operativo Linux, en concreto, la distro RedHat 7.0. Debería funcionar en todos los Linux, e incluso en todos los Unices. Si tienes la desgracia de tener alguna versión de Windows, mira en la página de instalación original.

En realidad, instalar el Tomcat no puede ser más fácil. Simplemente se descomprime (o se instala el RPM), se cambia uno al directorio de Tomcat donde lo has descomprimido, por ejemplo, /home/TU_LOGIN/jakarta-tomcat-3.2.3, y simplemente hay que indicarle dónde hemos metido la máquina virtual java. Para ello, se edita el fichero tomcat.sh y se insertan dos líneas tales como las siguientes:

export TOMCAT_HOME=/home/TU_LOGIN/jakarta-tomcat-3.2.3/
export JAVA_HOME=/usr/local/jdk1.2.2

Como se ve, la primera línea define una variable de entorno que indican dónde se puede encontrar el directorio raíz del Tomcat; la segunda hace lo propio con la máquina virtual de Java. A partir de ese momento, ya se puede ejecutar el fichero startup.sh para arrancar el servidor en el puerto 8080 y shutdown.sh para pararlo. Ambos ficheros se encuentran en el directorio bin del Tomcat.

Al ejecutar startup.sh, saldrá algo así:

maquina:/usr/local/jakarta-tomcat/bin# startup.sh
Using classpath: /usr/local/jakarta-tomcat/[mogollón de .jar aquí]...
2001-02-02 02:48:18 - ContextManager: Adding context Ctx( /examples )
2001-02-02 02:48:18 - ContextManager: Adding context Ctx( /admin )
2001-02-02 02:48:18 - ContextManager: Adding context Ctx( /cocoon )
Starting tomcat. Check logs/tomcat.log for error messages
2001-02-02 02:48:18 - ContextManager: Adding context Ctx( )
2001-02-02 02:48:18 - ContextManager: Adding context Ctx( /test )
2001-02-02 02:48:19 - PoolTcpConnector: Starting HttpConnectionHandler on 8080
2001-02-02 02:48:19 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007
2001-02-02 02:50:26 - Ctx( ): 404 R( + /Cocoon.xml + null) null

Para comprobar si efectivamente se está ejecutando, podemos usar el siguiente url http://localhost:8080 en nuestro navegador, con lo cual saldría una página de presentación de Tomcat.

Algo que sí puede convenir tocar en tomcat.properties, sobre todo si no hay mucha memoria disponible, es el número de hebras disponibles para conexión. Por defecto, se lanzan hasta 50, lo cual puede chupar del orden de 600 megas de memoria (aunque usa memoria virtual). Para cambiarlo, hay que cambiar la configuración de todos los Connector, cambiando el número de hebras que pueden usar: <Parameter name="max_threads" value="5"/>. Hay tres conectores; se puede cambiar el número de hebras de cualquiera de ellos, aunque yo no he conseguido bajar de 180 megas el consumo de memoria.

La configuración de Tomcat está en los ficheros que cuelgan del directorio $TOMCAT_HOME/conf; el principal es el server.xml, que, casualmente, está escrito en XML. Este fichero contiene toda la configuración del servidor, define los conectores, y contextos y, en general, todo lo que necesita un servidor. En principio, no hay que tocarla para nada, pero sí más adelante cuando decidamos instalar el Cocoon.

Un detalle de configuración a tener en cuenta es que se pueden cambiar los puertos que se van a usar, sobre todo si hay problemas de colisión con otros usuarios, o simplemente se quiere usar el puerto por defecto, que es el 80. Para realizar ésto, habrá que modificar las líneas siguientes del fichero server.xml:

<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
<Parameter name="port"
value="8080"/>
</Connector>

y cambiar el valor por defecto elegido por los programadores de Tomcat por defecto, que es 8080, por el valor que se desee, tal como 18335 (máximo 65535). Igualmente se pueden cambiar los valores de los puertos de los otros tres conectores: el 8043, que es el que se usa en las conexiones SSL, y el del conector AJP12 (el 8007), que además se usa para cerrar Tomcat.

Tal cual lo hemos instalado, ya podemos servir directamente páginas JSP, servlets y, por supuesto, páginas HTML; el problema es que si queremos hacer algo fuera de eso, por ejemplo CGIs, o incluso si queremos tener un servidor "serio", gestionando varios dominios virtuales, con PHP, CGI y lo que se nos ocurra, necesitamos usar eso precisamente, un servidor serio, tal como el Apache, dentro del cual Tomcat se usará como contenedor de servlets. En ese caso, tenemos que instalar el módulo mod_jk de Apache, para manejar la interacción entre Apache y Tomcat.

Teóricamente, la instalación de mod_jk es simple. Consiste en bajarse el mod_jk.so (por ejemplo, para Linux se haría desde http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.3/bin/linux/i386/) desde el sitio web, copiarlo a /directorio/de/apache/libexec/mod_jk.so, y hacer lo siguiente:

donde habrá que sustituir /usr/local/apache por el directorio adecuado. Si todo va bien, el URL http://localhost:9000/examples debería dar el directorio de ejemplos de Tomcat; y metiéndose en él, tendrían que salir los ejemplos de servlets y JSPs de Tomcat.

En realidad, lo de instalar el mod_jk.so a veces no es tan simple.
Así si el binario que aparece en el sitio de Tomcat sólo sirve si tienes un Apache con SSL, que use el API llamado EAPI para conectarse con los módulos. Si usas STDAPI, que es el normal y que es el que viene en la distribución por defecto, tendrás que compilar el módulo tú mismo. Bájate los fuentes de tomcat, te cambias al directorio: src/native/apache1.3 y haz un make -f Makefile.linux. Como es posible que eso no funcione, porque no te compila al final el .so, tendrás que añadir un gcc -shared -o mod_jk.so *.o.
No obstante, en el enlace que antes he puesto para bajarte el mod_jk.so puedes encontrar dos versiones: una para EAPI y otra sin EAPI. Otra cosa es saber si tu Apache está usando EAPI o no.
En fin, si todavía estás más perdido que el barco del arroz, consulta en alguno de los grupos de noticias al efecto.

Como se suele decir, hay otros contenedores de servlets, pero no son Tomcat. Se puede encontrar un listado completo en servlets.com. Entre ellos, destaca Enhydra, otro servidor Open Source, y Jetty. Los demás suelen ser de pago y, además, bastante caros. Por su popularidad, destacan Bea Weblogic y el IBM Trancoding Publisher. Con todos ellos se puede instalar Cocoon, siguiendo las instrucciones de la página web, o bien instalándolo como cualquier otro servlet.

Ejercicios
1. Instalar Tomcat (lo puedes bajar más rápidamente desde mi propia cuenta) .
2. Descomprimirlo en el directorio propio /home/TU_LOGIN/
3. Lanzar el servidor de servlets, usando un puerto distinto al que viene por defecto (poe ejemplo, 8090).
4. Parar el servidor, modificarlo para que el número máximo de hebras permitidas por conector sea 2 y volver a arrancarlo

Instalación de Cocoon

El siguiente paso una vez tenemos el servidor de servlets instalado, es instalar Cocoon junto a dicho servidor. Ya hemos comentado que, en realidad, no hace falta tener Apache instalado, porque Cocoon es simplemente un servlet que tendrá con su propio contexto dentro de Tomcat.

Vamos utilizar la versión 1.8.2, que es la actualmente estable (accesible también desde mi propia cuenta). Por supuesto nos bajaremos la distribución binaria. Luego lo descomprimimos en un directorio, por ejemplo, el /usr/local o incluso en /home/TU_LOGIN.

Para que funcione con Tomcat, hay que añadir los .jar a los que coge Tomcat cuando arranca. Se hace lo siguiente ($TOMCAT_HOME es el directorio donde está Tomcat y $COCOON_HOME donde está Cocoon):

mkdir $TOMCAT_HOME/webapps/cocoon
mkdir $TOMCAT_HOME/webapps/cocoon/WEB-INF
cp $COCOON_HOME/bin/cocoon.jar $TOMCAT_HOME/lib
cp $COCOON_HOME/lib/*.jar $TOMCAT_HOME/lib
cp $COCOON_HOME/src/WEB-INF/web.xml $TOMCAT_HOME/webapps/cocoon/WEB-INF
cp $COCOON_HOME/conf/cocoon.properties $TOMCAT_HOME/webapps/cocoon/WEB-INF
cp -R $COCOON_HOME/samples $TOMCAT_HOME/webapps/cocoon/samples

Lo que hemos hecho en resumidas cuentas es:

A continuación, hay que cambiar unos cuantos ficheros:

Lo más probable es que a la primera no funcione. La fuente más probable de conflictos es el parser XML que lleva el propio Tomcat, que entra en conflictos con el parser XML que incluye cocoon. Para evitarlo, se debe cambiar de nombre parser.jar a z_parser.jar. La idea es que, alfabéticamente, z_parser.jar estará al final por lo que ya habrá cogido antes el parser de Tomcat.

Si Tomcat está arrancado, se para; si no lo está, se vuelve a arrancar otra vez. El URL http://localhost:8080/cocoon/Cocoon.xml debería devolver una página de estado del Cocoon. Si no es así y dice fichero no encontrado, o algún problema similar, es que no has seguido las instrucciones tal y como se muestran. En este caso, lo mejor es empezar de nuevo (con la ventaja de que ya tendrás descargados los ficheros).

Por supuesto, ya que tienes instalado el Apache con Tomcat, igual también te da porque funcione el Cocoon+Apache+Tomcat. En ese caso, tendrás que agarrar el fichero mod_jk.conf-auto y copiarlo, por ejemplo, a mod_jk.mio.conf, porque ese fichero se genera cada vez que se ejecuta el Tomcat, y modificarlo de la forma siguiente:

JkMount /cocoon/*.xml ajp12
AddType text/xml .xml
#JkMount /cocoon/servlet/* ajp12
#JkMount /cocoon/*.jsp ajp12

es decir, comentar las dos líneas que se indican y añadir las otras dos. Con esas dos líneas se indica que todos los ficheros que tengan xml como extensión serán manejados por el "trabajador" ajp12, y que además, Apache tendrá que servir los ficheros XML como XML, para que se enteren los navegadores que manejen XML. Al final de todo esto, podremos llamar al URL de cocoon en htp://localhost:9000/cocoon/Cocoon.xml.

Si no te gusta el protocolo ajp12, puedes usar el ajp13, que se supone que es más rápido, y usa SSL, y más guay y todo. Pero hay que cambiar más cosas en la configuración, asín que mejor nos estamos quietecitos.

Usando Cocoon

Una muestra de cómo se puede usar Cocoon se puede ver directamente tras la instalación en http://localhost:8080/cocoon/samples/index.xml .Cocoon puede servir directamente páginas web, o aplicarles simples hojas de estilo.

Pero en general lo que querremos es servir nuestras propias páginas. Por ejemplo, copiemos el siguiente fragmento de XML en un fichero al que llamaremos hola.xml:

<?xml version="1.0" encoding='ISO-8859-1'?> <?xml-stylesheet href="hola.xsl" type="text/xsl"?> <?cocoon-process type="xslt"?> <pagina> <titulo>Hola</titulo> <contenido> <parrafo>Mi primera página Cocoon</parrafo> </contenido> </pagina>

Cómo se puede observar, el fichero anterior, a pesar de ser un fichero XML, lleva al inicio una serie de líneas que comienzan con <? y acaban con ?>. Dichas líneas indican algún tipo de procesamiento que ha de hacer Cocon con el fichero. Por ejemplo, las líneas:

<?xml-stylesheet href="hola.xsl" type="text/xsl"?>
<?cocoon-process type="xslt"?>

Indican, por un lado. que debe usarse el fichero hola.xsl para procesar el fichero XML y generar una salida .HTML. La segunda línea indica qué procesador debe debe encargarse de aplicar las transformaciones al fichero XML. EN este caso, le decimos que use el xslt, es decir, el procesador de XSL.

El fichero XSL que vamos a utilizar para poder dar formato al fichero XML y convertirlo en una página web es el siguiente: <?xml version="1.0" encoding='ISO-8859-1'?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="pagina"> <xsl:processing-instruction name="cocoon-format"> type="text/html" </xsl:processing-instruction> <html> <head> <title> <xsl:value-of select="titulo"/> </title> </head> <body bgcolor="#ffffff"> <xsl:apply-templates/> </body> </html> </xsl:template> <xsl:template match="titulo"> <h1 align="center"> <xsl:apply-templates/> </h1> </xsl:template> <xsl:template match="parrafo"> <p align="center"> <i> <xsl:apply-templates/> </i> </p> </xsl:template> </xsl:stylesheet>

el cual, por supuesto, hemos de llamar hola.xml, dado que así le hemos dicho a Cocoon que lo va a encontrar. Cabe decir que tanto hola.xml como hola.xsl deben estar en un directorio que cuelgue del directorio $TOMCAT_HOME/webapss/cocoon/ o bien en otro apuntado por un enlace; enlace que sí debe estar colgando de este directorio indicado. Si lo hacemos así, al poner en el navegador la llamada: http://servidor:8080/cocoon/hola.xml, obtendremos una salida similar a esta (o si prefieres, puedes ver cómo la sirve Cocoon directamente en nuestro servidor).

El lector atento (;-) habrá notado como he destacado en rojo tres líneas del anterior fichero. Dichas líneas indican qué tipo de fichero se va a servir, en este caso html. Podríamos haber querido servir un fichero WAP, en cuyo caso habríamos puesto text/wml, o incluso un fichero PDF (procesado por el Formatting Objects... aunque eso es otra historia), etc, etc. Si no hubiésemos puesto nada.. habría servido directamente html; es decir, que en este caso NO habría sido necesario poner nada.

Detectando el cliente

Sin duda, una de las principales características de un entorno de publicación como es Cocoon es la posibilidad de exportar a distintos formatos un mismo fichero XML en función del cliente que requiere el fichero. Por ejemplo, si en el documento final que vamos a mandar usamos Javascript, podemos querer diferenciar si el fichero va a parar al Netscape o al Internet Explorer. Mucho más importante es si la petición se produce desde un teléfono WAP, en cuyo caso nada de lo que enviemos en HTML servirá, sino que el formato deberá ser WML válido.

Pues bien, Cocoon es capaz de detectar qué cliente le está haciendo la petición. Para ver qué clientes detecta, hemos de mirar en el fichero $TOMCAT_HOME/webapps/cocoon/WEB-INF/cocoon.properties, donde encontraremos algo como esto:

browser.0 = explorer=MSIE browser.1 = pocketexplorer=MSPIE browser.2 = handweb=HandHTTP browser.3 = avantgo=AvantGo browser.4 = imode=DoCoMo browser.5 = opera=Opera browser.6 = lynx=Lynx browser.7 = java=Java browser.8 = wap=Nokia browser.9 = wap=UP browser.10 = wap=Wapalizer browser.11 = mozilla5=Mozilla/5 browser.12 = mozilla5=Netscape6/ browser.13 = netscape=Mozilla

Los distintos nombres que se dan después del primer símbolo de = servirán para que podamos decir en el fichero XML qué fichero debemos usar en función del cliente que haga la petición. Así, nuestro fichero hola.xml lo vamos a modificar dejándolo de la siguiente forma:

<?xml version="1.0" encoding='ISO-8859-1'?> <?xml-stylesheet href="hola.xsl" type="text/xsl"?> <?xml-stylesheet href="hola-netscape.xsl" type="text/xsl" media="netscape" ?> <?xml-stylesheet href="hola-explorer.xsl" type="text/xsl" media="explorer" ?> <?xml-stylesheet href="hola-wap.xsl" type="text/xsl" media="wap" ?> <?cocoon-process type="xslt"?> <pagina> <titulo>Hola</titulo> <contenido> <parrafo>Mi primera página Cocoon</parrafo> </contenido> </pagina>

El significado de las líneas superiores es claro: si el cliente es Netscape, utiliza el fichero hola-netscape.xsl para procesar el fichero, si es el Explorer utiliza el fichero hola-explorer.xsl y si es un cliente WAP debe usar el hola-wap.xsl.

Pongo aquí los ficheros hola-netscape.xsl y hola-explorer.xsl como ejemplo:

hola-netscape.xsl ======================= <?xml version="1.0" encoding='ISO-8859-1'?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="pagina"> <xsl:processing-instruction name="cocoon-format"> type="text/html" </xsl:processing-instruction> <html> <head> <title> <xsl:value-of select="titulo"/> </title> </head> <body bgcolor="#ffffff"> <xsl:apply-templates/> </body> </html> </xsl:template> <xsl:template match="titulo"> <h1 align="center"> <xsl:apply-templates/> </h1> <p align="center"> <em>(Versión NETSCAPE)</em> </p> </xsl:template> <xsl:template match="parrafo"> <p align="center"> <i> <xsl:apply-templates/> </i> </p> </xsl:template> </xsl:stylesheet> ------------------------------------------------------------- hola-explorer.xsl ========================== <?xml version="1.0" encoding='ISO-8859-1'?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="pagina"> <xsl:processing-instruction name="cocoon-format"> type="text/html" </xsl:processing-instruction> <html> <head> <title> <xsl:value-of select="titulo"/> </title> </head> <body bgcolor="#ffffff"> <xsl:apply-templates/> </body> </html> </xsl:template> <xsl:template match="titulo"> <h1 align="center"> <xsl:apply-templates/> </h1> <p align="center"> <em>(Versión EXPLORER)</em> </p> </xsl:template> <xsl:template match="parrafo"> <p align="center"> <i> <xsl:apply-templates/> </i> </p> </xsl:template> </xsl:stylesheet>

Si lo que queremos es transformar ficheros XML en tros ficheros XML o HTML o WML, etc., deberemos usar el procesador XSLT. No obstante, hay otros procesos posibles, que por tanto se pueden (y deben usar :-) como opción en cocoon-process . Algunos de ellos son:

El siguiente es un pequelño ejemplo de cómo se puede utilizar xinclude.

Fichero incluye.xml ======================== <?xml version="1.0" encoding='ISO-8859-1'?> <?xml-stylesheet href="hola.xsl" type="text/xsl"?> <?cocoon-process type="xinclude"?> <?cocoon-process type="xslt"?> <pagina xmlns:xinclude="http://www.w3.org/1999/XML/xinclude"> <titulo>Hola</titulo> <contenido> <parrafo>Mi primera página HECHA PARA Cocoon</parrafo> <xinclude:include xinclude:href="incluido.xml" xinclude:parse="xml"/> <xinclude:include xinclude:href="incluido.txt" xinclude:parse="text"/> </contenido> </pagina> ------------------------------------------------------------------------- Fichero incluido.xml ======================== <?xml version="1.0" encoding="ISO-8859-1"?> <parrafo> Este párrafo pertenece al fichero incluido.xml </parrafo> ------------------------------------------------------------------------- Fichero incluido.txt ======================== Esta parte es, simplemente, texto

Etiquetas de Procesamiento en Cocoon

Cocoon incluye una serie de etiquetas, con sus espacios de nombres correspondientes, que están en realidad implementados como programas en Java. Estas etiquetas se pueden usar tanto en los ficheros XML como en los XSL; en estos ejemplos los usaremos simplemente dentro de los ficheros XML. Las etiquetas están divididas en espacios de nombres, cada una con un fin específico.

REQUEST

La etiquetas request permiten acceder al contexto de la petición del fichero XML, es decir, a lo que en un CGI correspondería a las variables de entorno y a lo que se introduce en la línea de comandos. Por ejemplo, el fichero siguiente request.xml

<?xml version="1.0" encoding='ISO-8859-1' ?> <?cocoon-process type="xsp"?> <xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core" xmlns:request="http://www.apache.org/1999/XSP/Request" > <html> <head><title>Prueba del tag request</title></head> <body> <p>La petición se ha hecho con los siguientes parámetros:<ul> <li>Nombre de los parámetros: <request:get-parameter-names /></li> <li>La petición se ha hecho desde: <request:get-remote-addr /> con nombre <request:get-remote-addr /> </li> <li>La petición completa es: <request:get-query-string /></li> </ul></p> </body> </html> </xsp:page>

Este fichero se trata está escrito en XML estándar, aunque en él se usan espacios de nombres.

Lo primero de todo es indicarle a Cocoon que se van a usar los XSP, lo cual como puede verse se hace en la línea 2. En principio, XSP nos permitiría incluir código Java y que fuera ejecutado; sin embargo, en este ejemplo no estamos incluyendo código java, sino tags de request, los cuales se procesan como XSPs. Por este motivo es por lo que hay que incluir la etiqueta xsp:page rodeando a todo el código. En esa etiqueta se declaran también los espacios de nombres que se usan y los prefijos correspondientes: xsp, y request.

Los tags request se usan propiamente dentro de la página XML. En nuestro ejemplo, se ha utilizado directamete una página HTML "bien formada" (o XHTML) todo ello para no tener que usar hojas de estilo. Las etiquetas acceden al contexto del servlet, lo cual corresponde, grosso modo, a la clase request del mismo; todos los métodos de la clase están disponibles como diferentes etiquetas. Si todo va bien, el resultado de una llamada al fichero anterior, añadiendo algunos parámetros al URL como:http://mercurio.ugr.es:8080/cocoon/ejemplos/request.xml?param1=PEPE¶m2=JUAN, debe devolver algo como lo sisguiente:

La petición se ha hecho con los siguientes parámetros: Nombre de los parámetros: param2param1 La petición se ha hecho desde: 10.10.103.98 con nombre 10.10.103.98 La petición completa es: param1=PEPE¶m2=PEPE

Por supuesto, podemos usar XSP y XSL al mismo tiempo. Para ello, en la página XML debemos decirle a Cocoon que haga ambos procesamientos. Por ejemplo, el fichero hola-request.xml, que a continuación reproducimos, incluye llamadas request así como procesamiento con hojas de estilo

<?xml version="1.0" encoding='ISO-8859-1'?> <?xml-stylesheet href="hola.xsl" type="text/xsl"?> <?cocoon-process type="xsp"?> <?cocoon-process type="xslt"?> <xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core" xmlns:request="http://www.apache.org/1999/XSP/Request" > <pagina> <titulo>Hola</titulo> <contenido> <parrafo>Mi primera página HECHA PARA Cocoon</parrafo> <datos>Llamada realizada desde: <request:get-remote-addr /></datos> </contenido> </pagina> </xsp:page>

Cómo puede verse, en primer lugar se pide a Cocoon que haga el procesamiento XSP y posteriormente el XSLT. Además, se observa cómo aunque el código de la página XML sea distinto al de nuestro primer ejemplo hola.xml, sin embargo ambos se procesan con la misma hoja de estilo hola.xsl.

Algunos otros tag request que podemos utilizar se muestran en la siguiente lista (al lado de algunos se muestran lo que devuelven al hacer una llamada al URL de ejemplo http://mercurio.ugr.es:8080/cocoon/ejemplos/pruebas- request.xml?x=20&dato1=Victor&y=90&dato2=Pepe).

get-attribute-names get-auth-type get-character-encoding get-content-length retorna -1 get-content-type get-context-path retorna /cocoon get-cookies get-header-names User-AgentAcceptPragmaAccept-EncodingHostAccept-LanguageAccept-CharsetConnection get-locales retorna en get-method retorna GET get-parameter-names retorna xdato2dato1y get-parameter name="dato1" retorna Victor get-path-info get-path-translated get-protocol retorna HTTP/1.0 get-query-string retorna x=20&dato1=Victor&y=90&dato2=Pepe get-remote-addr retorna 10.10.103.71 get-remote-host retorna geneura.ugr.es get-remote-user get-requested-session-id get-request-uri retorna /cocoon/ejemplos/pruebas-request.xml get-scheme retorna http get-server-name retorna mercurio.ugr.es get-server-port retorna 8080 get-servlet-path retorna /ejemplos/pruebas-request.xml get-user-principal is-requested-session-id-from-cookie retorna false is-requested-session-id-from-url retorna false is-requested-session-id-valid retorna false is-secure retorna false

para una lista y una descripción más amplia, lo mejor es visitar la página http://xml.apache.org/cocoon2/logicsheet-request.html que aunque pertenece a Cocoon 2 (y por tanto es algo distinto) puede servir perfectamente de referencia.

UTIL

De la misma forma que anteriormente hemos usado los tag request, se puede hacer uso de los tags util, que como el anterior, está poco documentado, sino que hay que mirar cómo se usa en los ejemplos y en los fuentes para ver qué es lo que hace.

Por ejemplo, el fichero siguiente: util.xml

<?xml-stylesheet href="hola.xsl" type="text/xsl"?> <?cocoon-process type="xsp"?> <?cocoon-process type="xslt"?> <xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core" xmlns:util="http://www.apache.org/1999/XSP/Util" > <pagina> <titulo>Uso del tag UTIL</titulo> <contenido> <parrafo>Fecha: <util:time format="dd/MM/yyyy"/></parrafo> <parrafo> Fichero incluido: <util:include-file name="inc.xml"/> </parrafo> <parrafo>Contador: <util:counter /></parrafo> </contenido> </pagina> </xsp:page>

La estructura es bastante similar a la anterior, salvo que se declara el espacio de nombres util en vez del request; en cuanto a las peticiones, dan, por este orden, 1) la hora con un formato determinado (y no se puede omitir la cadena de formato), 2) incluye un fichero externo, que debe ser XML y 3) además te cuenta las veces que se ha pedido la página. Esto último es posible porque en realidad cada página XML se convierte en un servlet (lo cual puede dar lugar a múltiples problemas cuando se trata de recargar una página que uno ha modificado) y en realidad se contará mientras esté ejecutándose el servidor. La salida que dará está en el servidor, pero en todo caso será algo similar a:

Uso del tag UTIL

Fecha: 13/09/2001
Fichero incluido:
Este párrafo se ha incluido
Contador: 11

Ejercicios
1. Hacer una página XML que incluya las etiquetas anteriores; por ejemplo, que muestre la hora, los parámetros que se le pasan y demás. Una mezcla de los dos ejemplos anteriores.

Agradecimientos

Agradezco a los participantes del grupo de correo JUGAnd, de usuarios de Java en Andalucía, su ayuda a la hora de instalar Tomcat y Cocoon, y sus críticas de este tutorial.

Bibliografía y enlaces relacionados con Cocoon

Una de las pocas cosas que se encuentran en castellano son Usando PHP y XML con Apache Cocoon, que explica como usar todas esas cosas juntas.

El libro Java y XML, de Brett MacLaughlin, es bastante interesante en todo lo que se reviere a XML y Java, e incluye un capítulo dedicado al cocoon.