Hmm,
That would involve some kind of reverse engineering then, to determine the location to store the edits? The thought crossed my mind once but I thought it would be rather complex to implement. Thinking about it now it seems that something basic would not even be too difficult perhaps. I imagine you can do a lot with just adding a couple of id attributes. This of course means that the editor will not only have to be webdav aware but will also need to know about these additional semantics and not violate them. On the cocoon side the contents of the webdav method would be generated and routed thru some kind of source writing transformer. For the purposes of content management I don't think such a symetric model is neccessary. The architecture we have is that of a content model that resembles the logical structure of the data to publish and a presentation layer that is applied to the content model to produce the web view. The content model is accessed as a webdav repository thru Slide, without any of the semantics that may be required for publishing it to this or that channel. This way concerns are not mixed leaving the content model stuctured according to its own internal logic. To see why this is a cleaner approach consider the case that your content is mapped onto multiple views. What view should be the view thrue wich to edit the content? All of them? Is it clear that, when you edit the content, not only does that particular view change, but all of the views the content is mapped upon? How and where to add content if not on a logical structure of you data ? That having said, and after saying that ;) I also see the benifits in your approach. For instance, as the content is presentation-less XML, it would be nice to have a more user-friendly view of it than just XML. Currently we employ what we call 'back-end templates' for our editor views on the content. As it is now our editor needs to get them over webdav and apply them to the content. Moving that concern to the server would be a more flexible approach. Unico -----Oorspronkelijk bericht----- Van: Michael Homeijer [mailto:[EMAIL PROTECTED]] Verzonden: maandag 23 september 2002 13:37 Aan: Unico Hommes; '[EMAIL PROTECTED] ' Onderwerp: RE: WebDAV sitemap Hi, I don't want to access stylesheet and sitemaps over webdav, but I want my application-generated resources to be accessed over webdav. This way I can generate/aggregate data from a filesystem/db etc. and edit it through a webdav aware editor. The same way I can transform data that is saved by the webdav editor through Cocoon. This is something different than to access application resources through webdav because that only means that Cocoon and the webdav interface use the same resources. Michael. -----Original Message----- From: Unico Hommes To: [EMAIL PROTECTED] Sent: 23-9-2002 1:05 Subject: RE: WebDAV sitemap Conceptually I don't see any difficulties with using Slide for Cocoon, in fact this is what we have in the planning at our company. I've seen the Slide/Repository integration developements in the latest Cocoon CVS-HEAD but don't really understand what the need is for all that code. The concept of Slide is that it is abstracted from the level of the application. It basically substitutes tomcat's file-system based resource context with its own slide based resource context, thus making it completely transparent to the application. What that means in terms of a usage scenario is something like the following: - Configure a new Slide namespace and start Slide-Tomcat - Drop an unpacked cocoon into the WebDAV root, i.e. in Slide under /files In the default configuration of Slide, you can now edit your content/stylesheets/sitemaps over WebDAV at http://host:8081/cocoon , administer Slide at http://host:8082/cocoon , and surf cocoon at http://host:8080 The thing you need to remember is that since the Slide resources have been installed as jndi resources under the context, source resolving that depends on absolute filesystem paths will not work. I am not sure how Cocoon handles this exactly but I do foresee some potential problems in this area. >From the Slide user guide: "Any web application which is designed so that it doesn't access the files within its web application directory using direct filesystem access should run without any modification (file access should be replaced by calls like ServletContext.getResource, which abstract filesystem access). This includes applications like Jasper, and any web application written according to Sun's guidelines" -----Oorspronkelijk bericht----- Van: Michael Homeijer [mailto:[EMAIL PROTECTED]] Verzonden: maandag 23 september 2002 12:06 Aan: 'Martin Holz '; '[EMAIL PROTECTED] ' Onderwerp: RE: WebDAV sitemap There's allready a RequestMethodSelector that can do map:select type="webdav". I prefer this one since I don't like writing code. ;-) I don't think Slide can do the job here, because it works om a standard type of repository or interface, not on an application build in Cocoon. With webdav on Cocoon you can map the protocol to anything written in Cocoon. Your application will then act as a virtual webdav repository. I am not sure what can be reused to implement this. Michael -----Original Message----- From: Martin Holz To: [EMAIL PROTECTED] Sent: 23-9-2002 11:45 Subject: Re: WebDAV sitemap On Monday 23 September 2002 10:07, Michael Homeijer wrote: > Hi, > > I found and received info on slide, but I was thinking of a sitemap that > has matchers and additional actions, transformers etc. that make supporting > webdav from an application much easier. This way you can easily expose an > application as a webdav resource. A sample sitemap would contain the > following matchers: > > <map:match pattern="/"> > <map:act type="requestmethod"> > <map:generate src="cocoon:{request-method}"/> > <map:serialize/> > </map:act> > </map:match> > > <map:match pattern="PROPFIND"> > </map:match> > > <map:match pattern="PROPPATCH"> > </map:match> > > <map:match pattern="MKCOL"> > </map:match> > > etc. > > Does this make sense? Yes, adding Webdav methods to the cocoon makes sense. However it would duplicate the work done for the slide webdav servlet. Slide webdav contains lot of code, so porting it to cocoon is a major project. Do you want to extend the matcher or introduce a new one? You could do either <map:match type="wildcard" method="PROPFIND" pattern="**./ > .... </map:match> or <map:match type="wildcard" pattern="**./ > <map:select type="webdav"> <map:when test="PROPFIND"> ... </map:when> <map:when test="PUT"> ... </map:when> </map:select> </map:match> I would prefer the second solution, since you don't have to change existing matchers. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
