cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Homeijer <>
Subject RE: WebDAV sitemap
Date Mon, 23 Sep 2002 11:36:58 GMT

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.


-----Original Message-----
From: Unico Hommes
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

- Configure a new Slide namespace and start Slide-Tomcat
- Drop an unpacked cocoon into the WebDAV root, i.e. in Slide under

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

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 []
Verzonden: maandag 23 september 2002 12:06
Aan: 'Martin Holz '; ' '
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
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.


-----Original Message-----
From: Martin Holz
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
> has matchers and additional actions, transformers etc. that make
> webdav from an application much easier. This way you can easily expose
> 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

<map:match type="wildcard" method="PROPFIND" pattern="**./ >


<map:match type="wildcard"  pattern="**./ >
  <map:select type="webdav">  
	<map:when test="PROPFIND">
      <map:when test="PUT">

I would prefer the second solution, since you don't have to change 
existing matchers.


To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message