- Tabla de contenidos
- 1. �Por qu� Cocoon?
- 2. Cocoon
- 3. Estructura y arquitectura de Cocoon
- 3.1. Conceptos claves
- 3.1.1. Estructura
- 3.1.2. Arquitectura
- 4. Cocoon y las XSPs
- 5. Paralelismo con Cocoon
- 6. Instalaci�n de Cocoon 2
- 7. Configuraci�n y personalizaci�n en Cocoon
- 7.1. El sitemap
- 8. Desarrollo en Cocoon
- A. Formato de reuni�n semanal
- 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:
Si se quieren obtener distintas presentaciones, es necesario modificar el c�digo Java que se encarga de dar formato a los datos
El mantenimiento puede no ser tan transparente ya que un dise�ador puede alterar el c�digo embebido en el HTML.
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.
 | 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:
El usuario solicita un documento de cualquier tipo al servidor.
La solicitud se analiza para concluir si se puede atender o no. Si no se puede atender se produce un mensaje de error.
Si se puede atender se analiza a qu� productor XML corresponde. Se genera un documento XML con el cual se trabajar�.
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.
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.
3.1.2. Arquitectura
- 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.
4.2. Tipos de p�ginas XSP
De acuerdo a la forma como se programan, las XSPs se pueden dividir en tres grupos:
Con la l�gica embebida en la presentaci�n
Con hojas de estilos
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.
 | 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
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:
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.
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:
Cuando se le pregunte por una contrase�a escriba anoncvs. Luego escriba lo siguiente:
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:
�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/.
 | 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:
Declarar los componentes que ser�n utilizados por cualquier pipeline.
Declarar los pipelines necesarios para el funcionamiento de las aplicaciones.
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:
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.
| 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/
 | Tenga en cuenta la ruta en la que guarda su DTD para que el fichero XML la pueda reconocer. |
| Es recomendable manejar rutas relativas en la declaraci�n de la DTD para mejorar la portabilidad de la aplicaci�n. |
| 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:
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").
| 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
| En Construcci�n |
8.2.2. Acceso a bases de datos
Para acceder una base de datos usted debe tener en cuenta tres pasos:
�sto lo debe hacer en al fichero cocoon.xconf a�adiendo las siguientes l�neas en la etiqueta datasources
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:
Si usted est� utilizando la Base de Datos que viene con Cocoon (hsql)este paso no es necesario
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:
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
A�ada un pipeline en el sitemap que sea de la forma:
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.
8.2.2.1.2. Ejemplo con uso de etiqueta ESQL
A�ada un pipeline en el sitemap que sea de la forma:
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.
| 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:
Incluir en el sitemap general de Cocoon el subsitemap (y especificar a qu� y en d�nde se aplica ese subsitemap).
Incluir el subsitemap en el lugar correcto.
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:
Bien, miremos un poco este c�digo para comprenderlo mejor:
En la l�nea match pattern="MiAplicacion/*" se le est� indicando a Cocoon que cualquier recurso que intente ser accedido por el URL http://localhost:8080/cocoon/MiAplicacion/ debe ser atendido con el fichero ubicado en $MiAplicacion/sitemap.xmap (esto se le est� indicando con el atributo src de la etiqueta mount, es decir, en la l�nea mount uri-prefix="MiAplicacion" check-reload="yes" src="$MiAplicacion/sitemap.xmap" )
Con el atributo uri-prefix le estamos diciendo que cuando siga el flujo del requerimiento del usuario al subsitemap no le pase la cadena MiAplicacion. Esto es l�gico, ya que para el subsitemap de MiAplicacion, todos los requerimientos que va a atender son de la aplicaci�n MiAplicacion, por lo cual incluirlo en cada uno de los pipelines del subsitemap ser�a redundante.
Con el atributo check-reload damos la opci�n de que Cocoon verifique cuando el subsitemap de MiAplicacion sea modificado para que lo vuelva a cargar. Si el valor del atributo es yes, chequea cada vez que sea modificado, si el valor es no s�lo carga el subsitemap cada vez que sea cargado Cocoon.
Por �ltimo, con el atributo reload-method le indicamos el modo como debe recargar el subsitemap. Si el valor es synchron, recarga el subsitemap cuando se le haga una solicitud y no muestra el resultado del requerimiento hasta que es recargado por completo, caso contrario a cuando el valor es asynchron ya que en este caso, aunque tambi�n recarga en el momento que se haga el requerimiento, deja mostrar el resultado del requerimiento mientras va recargando el fichero. Es de tener en cuenta aqu�, que como el subsitemap no ha sido recargado en el momento que se muestra el resultado de la solicitud del usuario (cuando muestra el resultado empieza a ejecutar el proceso que lo recarga), el resultado mostrado no estar� actualizado con respecto al estado actual de la aplicaci�n, s�lo hasta que sea pedido en la siguiente ocasi�n.
| 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:
Miremos un poco este subsitemap:
En las l�neas:
<!-- =========================== 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>se est�n declarando los componentes del subsitemap y se est� diciendo con el atributo default que para la aplicaci�n en cuesti�n los componentes predeterminados son los que se declararon con el valor de dicho atributo en el sitemap general de Cocoon.
Por otro lado, en las l�neas:
<map:pipelines> <map:pipeline> <map:match pattern="index.html"> <map:generate type="file" src="$MiAplicacion/XML/index.xml"/> <map:transform 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>se est�n declarando los pipelines. Esto se hace de igual forma que como se hace en el sitemap general de Cocoon.
F�jese que en la l�nea
<map:match pattern="index.html">se est� diciendo que si se hace una solicitud de la p�gina index.html, tome los datos del documento index.xml y le aplique la transformaci�n dada en index.xsl. Lo importante aqu� es observar que esta p�gina ser� mostrada cuando se cargue la direcci�n http://localhost:8080/cocoon/MiAplicacion/index.html ya que el subsitemap esta dentro de $MiAplicacion y en el sitemap general se dijo que la cadena $MiAplicacion ser�a truncada.
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.
| 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.
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�.
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.
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:
Guardar el fichero XML y su DTD en el directorio que usted escoja. Para nuestro ejemplo lo haremos en la ruta $ReunionSemanalHome/XML.
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.
En el fichero sitemap.xml de Cocoon a�ada un Pipeline de este estilo:
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:
| Tenga en cuenta la ruta en la que guarda su DTD para que el fichero XML la pueda reconocer. |
| Es recomendable manejar rutas relativas en la declaraci�n de la DTD para mejorar portabilidad de la aplicaci�n. |
| Cuando est� construyendo aplicaciones en Cocoon es bastante �til definir directorios para guardar sus ficheros XML, XSL, sus DTD, sus fuentes, sus clases, etc. |