cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject RE: WebDAV sitemap
Date Mon, 23 Sep 2002 11:05:59 GMT

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 []
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 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.


-----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:

View raw message