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.