cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@rabellino.it>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Fri, 02 Nov 2001 12:50:38 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message