> >> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
