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]
