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 -- Ulrich Mayring DENIC eG, Systementwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
