Bipunto..

Impresiones sobre Cocoon 2 Estaba yo contestanto con un comentario a la llamada que hacía Abraham en su comentario a la notícia Apache Cocoon 2.1.6 cuando me percaté que el redactado final acabaría ocupando mucho más de lo que se puede considerar adecuado para un comentario. Es por esto, que me he decidido a ponerlo aquí. (¿Para cuando un trackback en Cáñamo?).
Como su interés, también es el mío, con tu permiso Abraham, hago propias tus inquietudes y el mismo llamamiento. Impresiones sobre Cocoon 2: Para los que no lo conozcan, lo primero que hay que entender es que se trabaja básicamente con XML/XSL y que sólamente se va a necesitar rascar código Java/Javascript/... para cosas puntuales como el control del flujo del progama (o para implementar funcionalidades muy específicas). Y es que se pueden hacer cosas realmente complejas con muy pocas líneas de código. Cocoon consta de numerosos 'bloques' predefinidos, con las funcionalidades más comunes, ya escritos y que sólo hay que 'ensamblar'.

1. No es precisamente fácil de aprender, puesto que cambia la manera de atacar el desarrollo de una aplicación. Pero ¿lo es Struts? o cualquier otro entorno de los basados en extender una API con decenas de clases/métodos?.
2. Además, la curva de aprendizaje se incrementa, no por el propio framework, sino por que hay que entender XSLT, que por méritos própios no es nada trivial. Pero a estas alturas ¿quien no domina XSLT?
3. La documentación podría mejorarse mucho, pero como los 'masters' han estado más por la labor de ejercer como escritores en vez de contribuir desinteresadamente a la comunidad, pues esta está esparcida entre el propio web, el wiki y webs excindidas. Tampoco es precisamente de las más estructuradas ni actualizadas y podría ser mucho más exaustiva. El tutorial va en la línea. Destacar el Libro "Cocoon developer's handbook" de Lajos Moczar y Jeremy Aston.
4. Tiene (en términos docentes) el inconveniente endémico de Java y sus tecnologías. Para resolver un problema tienes una amplio abanico de posibilidades, y esto cuando se está empezando despista. Luego evidentemente aporta numerosas ventajas.
5. No es fácil hacer un debugging en runtime. Pero también es mucho más difícil, por la naturaleza del entorno, cometer errores de esos que tienes que ir línea a línea, como en Java. Por tanto, no se echa tanto en falta. Por otro lado hay que ser un campeón para generar una excepción y cuando algo funciona correctamente, es difícil que deje de hacerlo. Las aplicaciones generadas son muy robustas y en este aspecto le podrían sacar los colores a otros frameworks, especialmente cuando de por medio hay equipos sin el adecuado bagaje.
6. Cuando lo dominas, es productivo, muy productivo, pero mucho más que otras alternativas. Además permite, en equipos de cualquier tamaño, realizar un desarrollo en paralelo molestándose lo mínimo. Esto es un objetivo que los diseñadores de Cocoon persiguen casi obsesivamente.
7. En vez de implementar XForms como tecnología de formularios, con sobrada razón y además justificando que ese estándar nace con pocas ambiciones, evidentes carencias, y demasiadas limitaciones, los responsables de Cocoon innovan en una nueva manera de abordar dicho problema. Por contra, se salen de lo que hoy se apunta como estándar, y aunque conceptualmente sea difente, al final y en la práctica es muy similar, al acabar ambos acudiendo al "form" de Html.
8. Tras el proyecto, hay implicada gente muy muy válida, para mí, auténticos fuera de serie, pioneros en concebir e implantar conceptos como la IoC, SoC, continuations, o, como antes decía, un paradigma académicamente mucho más coherente que XForms para trabajar con formularios, ... Esto garantiza la continuidad del proyecto, la coherencia y el compromiso que asegura que en un futuro no se encuentre uno trabajando con una herramienta obsoleta.
9. Como inconveniente no es un entorno demasiado extendido ni ¿conocido?, sobre todo por estos lares, sin embargo, se le está dando un gran impulso y en Alemania hay grandes empresas y consultoras independientes que lo utilizan en diferentes proyectos, allí hay varios integrandes del equipo de desarrollo de Cocoon. Este avance se está impulsado también al ser utilizando como plataforma para crear nuevo software servidor como wikis, CMS, Portales, etc ...

Para terminar, apuntar que Cocoon es pionero en el paradigma que ahora se está poniendo de moda por Laszlo con su LPS/LZX, Macromedia con su Flex/MXML, Mozilla con su Mozilla/XUL, 1060 con su Netkernel/DPML e incluso la propia Micro$oft con su Longhorn/XAML, además de Orbeon con su OPS/XPL, y es que a mi entender se aproxima a la abstracción pretendida con los pretéritos y defenestrados 4GL, en contra de los 3GL y sus monstruosas API's con cientos de Clases y métodos que difícilmente se llegan a dominar al 100%. Y por último, si yo tubiera que embarcarme de nuevo en esta cruzada, empezaría con su primo-hermano Orbeon Presentation Server, también opensource, ya que tiene una curva de aprendizaje más plana, está más centrado en el uso de XML/XSL incluso para el control de flujo, implementa el estandar XForms y tiene un Ide basado en Eclipse que facilita el desarrollo. Este tampoco está exento de inconvenientes por lo que habrá que sopesar los pros y los contras de uno y otro en cada caso particular. ¿Será que empieza la era de la programación con XML?.. Posted by Feliciano Borrego Vicente in Cocoon at 20041123