cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Fri, 02 Nov 2001 10:04:06 GMT
Gianugo Rabellino wrote:
> Cocoon
> looks to me as the crypt() functions: a perfect, robust and stable
> system with the feature or limitation of being almost totally "one way".

Plus, Cocoon is too monolithic. It's developed with the Avalon
framework, but it can't run under Phoenix. It's not made up of a set of
components (blocks) that can be combined freely. I can't just run Cocoon
without the Sitemap or swap the Sitemap with my own scheme. For example,
95% of what I need is a block that does XML-->XSL(FO|T). I have many
server-side apps, who would love to use this block. Why should they make
a costly HTTP connection to some server that runs Cocoon and commit to
the interfaces Cocoon prescribes? Wouldn't it be much cooler if I used
the "XML-->XSL(FO|T)" block from Cocoon and keep everything within the
framework and on the same JVM? I could even run a HTTP/Servlet server
under Phoenix (e.g. Jo!) and have it use Cocoon's blocks for doing XML
stuff - no costly TCP connections to some servlet engine anymore.

So, my belief is that Cocoon must be componentized, before complex
things like content management or workflow become possible. If the
Sitemap would bother you in a WebDAV workflow, you could just take it
out. It would become easy to bypass troublesome generators and get at
"the pure XML source".

> but I'd rather see a CMS (or, even better, a CMS framework) written from
> scratch *using* Cocoon that generally enabling any Cocoon to
> transparently edit content.

Components is the magic word :)


Ulrich Mayring
DENIC eG, Systementwicklung

To unsubscribe, e-mail:
For additional commands, email:

View raw message