Michael Hartle wrote: > You are using Cocoon in GUI applications ? No kidding ? GUI was the last > place where I would have searched for applying Cocoon ;)
There are wonderful and unexplored landscapes where Cocoon can help. More on this later ;) >> The main problem area lies in the Cocoon "one way" approach: Cocoon is >> great in "virtualizing" the URI space and decoupling resources from >> actual layout. It fails tremendously short the other way around: > I hope I understood you correctly; IOW, Cocoon perfectly produces and > delivers content, but can hardly receive and decompose it. If we assume > that we edited final dynamic and intermixed contents as a whole (e.g. a > personalized corporate frontpage) via WebDAV, then I agree that > reversing the production process is almost impossible to do. As I posted > in my earlier response to Stefano, we have to target complete atomic > contents instead, those informations that are being taken, transformed > and intermixed. The URI space for standard web pages and WebDAV > operation does not necessarily have to be the same, nor would it make > sense. Exactly. It would be perfectly feasible, given a generic WebDAV support to deploy a Cocoon application configured in such a way that content can be clearly identified and edited. But if this is true I see no point in using Cocoon over mod_dav, Slide or even the Tomcat 4 servlet. I think that this effort should be undertaken only if there is a clear advantage over existing technologies: being Cocoon a framework even the WebDAV stuff should be really generic and extendable, which means that it should be possible to use it independently from any actual layout. If this is not the case it wouldn't make sense to spend resources in this task (of courseIMHO). > It might be next to impossible to completely transform OO to DocBook or > the other way around without loosing information at the moment, but I am > confident we could do it at a lower level that DocBook; I haven't been > able to check out DocBook or OO markup documentation. We have a > multitude of options available regarding OpenOffice, including that we > can ask for non-OpenOffice-markup to remain unaltered, or check out > whether enabling DocBook in OpenOffice might be a future solution. I hope to be proven wrong, but AFAIK it's really hard to transform OO content and style into any kind of real world structured layout. Just think about how OO deals with styles, building a sort of "dynamic catalog" which, if I understood correctly, can change not only on a template basis but even in different documents which are instances of the same template. I'm currently looking at the ODK (OpenOffice Developer Kit): while it offers several advantages over going through the OO documents "manually", it has the major drawback of needing a "server" OO instance to attach the calls too. I'm not sure that OO used in a "server side" way can scale or behave correctly. >> be locked). In this case yes, Cocoon would rock, 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. > Where would you differentiate between subprojects to belong to the CMS > framework or Cocoon ? Cocoon is about XML handling and presentation. A CMS is responsible for the "backoffice" part and has several concerns that are difficult to model in Cocoon: think about users, groups, permissions, workflow, scheduled publishing, categorization and so on. I remain convinced that the best solution would be a CMS where all those concerns are addressed specifically (most of such a beast can be done using Cocoon as the base framework) *and* a way to access the CMS from the "presentation" side using Cocoon via custom generators or, even better, a (pseudo-)protocol. It can be a perfect candidate for the next CWAs, but I'm almost sure that it would be pretty difficult to manage transparently in the same context both the content creation and presentation issues. Again, I sincerely hope to be proven wrong :) Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
