Per Kreipke wrote: >>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. >> > > Well, I'm not so sure (could be my ignorance!). I suppose that sub-sitemaps > solve concurrent access problems but here's what I'm curious to try. Instead > of locking an entire site map or sub-sitemap to add a generator or transform > to a particular resource, what if I could lock and update just a particular > element top most <map:xxx> element or sub element.
> E.g. in the large sitemap included with the distribution, suppose I have 3 > site developers who need to manage a portion of a live site, it'd be slick > if you could simply lock a portion of the file > > /foo/sitemap.xmap//map:serializers[@name='wap'] Looks like you're talking of a WebDAV locking at the *element* level in an arbitrary XML document. Cool for sure, how feasible? :) The next consideration come from the good old software engineering motto: are we doing the right thing? are we doing the thing right? I'm scared at the idea of 3 different people that need to play around continuously with the sitemap so much to require a "low level" locking (speaking in database terms): I think I still have to see a site that needs such a level of intervention at the *sitemap* level, and I tend to think that you shouldn't edit your sitemap much more times than you would be editing your httpd.conf. The only scenario where I can see such a need is in a mass virtual hosting environment, but again I'm not that sure that Cocoon would fit in such an environment. > What does the 'folder' metaphor looks like when you drill into an XML > representation of Michael's headline/article store (or something more > complicated)? What's the most granular item? What's the content type of each > 'file' (needed to map it to an application, or do they all have file > extensions)? What if that 'file' is itself an aggregation? Sorry, I still > don't get this part but I'm eager to! :-) I'm afraid I can't help you here but saying that overall managing a write-enabled Cocoon in a general would be a PITA :) This is way I'm more and more convinced that the CMS concerns should be handled outside of Cocoon (maybe *using* Cocoon to build a CMS). >>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 ;) > > Ok. I'm with you but I think for large sites, more granular management could be needed. Again: possibly not at the presentation level. Careful sitemap design and a powerful CMS as a backend should help in dealing with those issues (meaning that the day to day work should be done in the CMS). >>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. >> > > You're right. I mean 'content developers'. I basically mean the guy at the > browser, not the guy sitting with XMLSpy working on the sitemap. OK, let's agree on something. I propose the following names (Stefano, bear with me: I know this is not exactly what we have in mind, but it's just to clarify my point): 1. End users: the ones that sit in front of a client and enjoy the services and contents from the sites (me reading Slashdot) 2. Content developers: the ones that write the content of the site (me writing a news for Slashdot); 3. Editors: the ones that decide what content is suitable for publication (CmdrTaco that approves my news and publishes it in Slashdot); 4. Webmasters: the ones that decide the layout of the site and manage the sitemap and the web server configuration files; 5. Web developers: the ones that write the software components (assembled and deployed later on by webmasters). My point is that only 2) and 3) might benefit from a Cocoon-enabled WebDAV. 4) might use the existing tools (even though having integrated locks and versioning might help). 5) in general should not have any access to the production site and hey might well work on staging environments. >>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. >> > > That's true. But there are lots of plug-ins for enhanced text areas. Which suck big time too ;) If you're a writer you want your tool. If I'm a sysadm I can't do system administration using a web browser: I want my shell. If I'm a programmer I can't code using textareas: I want my editors (no, this does not include Emacs ;P). If I'm a writer, I want my word processor. It's just a matter of the right tool for the right job. > Also, I think you're getting very document centric. I think of Cocoon as a > complete XML engine, it's not all text articles. Gotcha. You're right, but probably in that case you wouldn't need WebDAV. > Ah. If you only had element by element locking and validation ;-) And versioning, and transcations, and an Open Source JVM, and real threads in Linux, and Bill Gates working in a salt mine... ;-) Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
