> 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?]
I'd say this is it. Better: this is way too much :) > 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). Sure, but not only that: probably you don't want your sitemap, components and the like to be accessible from WebDAV: I for sure wouldn't, for security reasons to say the least. > 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)? Exactly. Probably impossible and wrong for sure. > 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. Take for granted that if you have writers they absolutely need the disk drive metaphore and wouldn't settle for anything less. And yes, I think that browsing is a must. > 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. But this is the easy part! Take mod_dav, slide or the WebDAV servlet and you're ready to go, you don't need any specific Cocoon support. Just WebDAV-enable your cocoon webapp and try out Pollo (http://pollo.sourceforge.net) as a starting point. It shouldn't be difficult to integrate Pollo into, say, Netbeans, et voila' you have a Cocoon IDE ready for your marketing guys ;) > 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. This is exactly my concern. I know that WebDAV is great and I want WebDAV access to my content. The problem is where this support should be placed. The strenght of Cocoon (unmatched by the other alternatives) is the incredible flexibility and power that gives to you. I'm dreaming of being able to specify sets of action to be undertaken when a document is uploaded to the server (an example? commit it to a CVS server and make that CVS my repository), or to map my security access rules (the authorization or PMI part) directly in the Sitemap. And I'm wondering about a perfect world where I can write my application filters so that I can present the content to my writers in the format of their choice (I was thinking about using Majix and JFor to allow for RTF editing of simple XML documents). The problem is if Cocoon is the right place for that. > 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. Please define what you exactly mean for "end user" and "developer". Where are content developers (i.e. writers) placed in your setup? I understand that you're labeling them as "end users", and I don't agree completely with you on that. > - within the 'developer' role, they need to edit #1-4 (the sitemap, etc). And there's no need for anything fancier that any plain WebDAV environment for that. Or am I missing something? Note: there are RTs floating around suggesting that in a production server the sitemap should be compiled, i.e. not editable directly, and I basically agree (with some concerns) to that. > - 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?] There might be XSLT writers that need to edit the presentation, but again there's no need for WebDAV in Cocoon for that. > - '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?] Web forms suck big time. This is the main concern: if you are a writer and need to edit real world documents you can't stand the textarea limitations. > 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. This is exactly my point: I think we need to understand if it makes sense to WebDAV enable Cocoon or if it's better to resort to other already existing WebDAV environments. > 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. But again, this can be done by any WebDAV application, there's no need to extend Cocoon just for this. And I'm not that sure that I'd like to give WebDAV access to my single point of failure (the sitemap). Not before the sitemap becomes more robust (i.e. refusing to load an incorrect sitemap). Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
