En estos días me estoy *peleando* con Cocoon. No, no es que no lo conociera todavía, me lo habían *presentado*, pero no en profundidad. Ya me sonaba del primer proyecto de documentación de Alba Software, aquella típica página de inicio tan similar a la que ahora conozco como página de inicio de los ejemplos de Cocoon 2.1. Que curioso.

El caso es que ahora lo necesitaba conocer más a fondo, me he paseado y utilizado el proyecto Forrest de Apache, y me ha parecido muy interesante. Se trata del proyecto de documentación de la ASF, y está basado en Cocoon. No sabía yo que Cocoon era tan potente, que incluso se podía utilizar sin atacarlo como servlet, es decir, mediante el *command line interface*.

Bueno, pues Cocoon en sí es todo un esquema de generación de documentos, más bien, generador de respuestas según coincidencias en la petición. A raíz de una URI que enviemos al servlet, se genera toda una serie de procesos, generación de entrada XML, transformaciones, serialización, etc; me ha dejado fascinado.

Solamente le veo un inconveniente, y es que cada uno de los componentes, está *desconectado del otro*, es decir, no van a compartir espacios de memoria, si no que se intercambian información en formato XML. Si esto es así, y lo que interesa es que todo el proceso de petición-respuesta esté *encadenado*, no alcanzo a entender como hacer para unir los componentes de un *pipeline*. Si, ya se, tenemos los actions que generan claves de sustitución (procesos que calculan variables y las hacen disponibles al siguiente componente), pero esto no me sirve porque... ¿que pasa si estamos hablando de arrays de datos?, la solución de Cocoon es una serie de tuplas clave-valor, y no veo como hacer cuando manejas otra serie de datos y los quieres pasar al siguente componente.

Realmente es un proyecto interesante, ya que todo el tema de generación de documentos de diferentes content-types está ya solucionado. En fins, seguiré investigando.