cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <...@onclave.com>
Subject RE: [RT] Integrating Cocoon with WebDAV
Date Fri, 02 Nov 2001 17:32:53 GMT
> >> 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).
>
> My target is not in using WebDAV to deploy Cocoon applications, but to
> expose a virtual drive with virtual folders containing virtual contents
> with the power of Cocoon over WebDAV; loadable content would be
> generated on the fly as needed, and when content is being saved, it is
> being handled (unpackaged and saved somewhere, for instance) depending
> on your specific demands.
>
> The pipeline concept of Cocoon has Generators as a start and Serializers
> as an end; in a way, a Generator could be considered a Deserializer. I
> had a short look into SOAP some time ago and when I heard of SOAP
> logicsheets running with Cocoon 2, I was of the opinion that Ovidiu had
> taken exactly that way. If we are able to deserialize the content being
> saved, a kind of reversing the serialization process that will not work
> in all cases (no perfect way from JPEG to SVG, I know...), but can be
> done in some.
>
> The situation is that I have to spend work on integrating WebDAV with
> Cocoon as I definitely need such a setup, so the resources (at least
> mine ;) ) will be spent on this subject, and I am hoping on good ideas
> and hints how to do this right, so that this investment gives
> maximum value.

Having thought much about this issue also, I'd like to add my $0.02.

IMO, the categories of Cocoon 'components' that are of interest to manage
via WebDAV:
1. the sitemap file itself
2. specific elements within the sitemap (e.g. edit just the matchers in
sitemap)
3. any subsitemaps
4. the 'code' referenced by the sitemap (e.g. Java generators, actions,
XSLT, etc).
5. the content used or aggregated by the sitemap.
6. the final output

[Q: What did I miss?]


Very simple summary of thread so far:

a. what Stefano, Michael, Gianugo, Ulrich agree on is that handling #1-4
(sitemap) is different from #5 (the content).

b. it'd be extremely hard to edit #6 (the output): reversing the
transformations, then decomposing it into its constituent pieces using the
'reverse pipeline' discussed in this thread. How it even work when the same
document is available in PDF, WML, HTML, XML, on different devices, etc? As
stated by others: does it even have meaning to edit a transformed document
because it implies that the author is crossing concerns (e.g.
presentation/content)?


Observations/Questions:

i. is 'web folders' access to #1-6 necessary (e.g. does it need to be
browsable)? We could just use WebDAV to do resource locking, searching,
versioning, etc without browsing.

ii. corollary: perhaps not all methods of WebDAV need to be supported.

iii. WebDAV access to #1-4 (sitemap) would be interesting and would require
integration with Cocoon. I can't wait to see a Cocoon aware IDE based on
this.

iv. WebDAV access to #5 (content) shouldn't require access through Cocoon,
it could integrate directly to the XML content (dbXML, etc). This is the
'atomic' stuff Stefano, et al mentioned (I think). Con: it would require a
separate URL space independent of the sitemap controlled space.

v. note: Slide's low level API is _already_ a CMS.


Which brings me to SoC.

- the important separation of concern, IMHO, is end-user vs. developer. I'm
not as concerned with different developer roles (presentation/coder). That
might be because I really want Cocoon to rock for implementing the 'two way
web', not just the one way one.

- within the 'developer' role, they need to edit #1-4 (the sitemap, etc).

- within the 'end-user' role, they need to edit the pure content. [Q: hmm,
not necessarily true if they want to edit the presentation. Maybe impose
this restriction?]

- 'end-user's edit content through: web forms, document processing (Word,
OO), other apps, and on various devices (PDA, Web, application, etc). [Q:
isn't 95% of the use here though web forms?]

- aside: if we were to try and get Word and OO to edit Cocoon output, we
could perhaps simplify by imposing restrictions on the XML structure such
that the word processor really becomes a form tool: each sub-part is
individually editable instead of the whole document at once.



To me it doesn't necessarily makes sense for Cocoon to manage the WebDAV
access to the content. I can do it just as well or better using Slide in
parallel, or from within my Cocoon actions using their CMS API.

It does make sense to me for Cocoon to allow some WebDAV control of the
sitemap, etc. If I could use Forte or FrontPage or XMLSpy or some such to a
portion of the sitemap, that'd rock.


Humbly,
Per Kreipke


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message