Stefano Mazzocchi wrote: > > Talking about perfect timing ;-) > > On Thursday, Oct 30, 2003, at 15:46 Europe/Rome, Unico Hommes wrote: > > > I'm in the process of refactoring and furthering the davmap > samples in > > the WebDAV block. Methods that I've added are DELETE and MKCOL, and > > will be adding a PROPPATCH in the following few days and look into > > LOCK, COPY and MOVE methods as well. I've also made some general > > improvements to PROPFIND, PUT and GET. All these have been tested > > using XMLSpy as WebDAV client (somehow couldn't get eclipse WebDAV > > integration to work yet). > > Awesome. > > > One of the things I have done to make my life a little easier is > > define a service called o.a.c.c.repository.SourceRepository in the > > repository block. It basically reuses the idea from the > > SourceRepository in the linotype block but instead of being > a JVM-wide > > static it is a container managed singleton. Apart from > being able to > > obtain a SourceResolver via the ServiceManager instead of via > > CocoonComponentManager.getCurrentEnvironment - which will > be absent in > > 2.2 - and do better logging I think this will also allow us > to hook in > > interesting stuff such as monitoring. > > Uh, very cool. How can I use this from Linotype? I would love > to get rid of the repository class in the linotype block.
Not all functionality of the Linotype SourceRepository is implemented. For instance I have not gotten to the versioning part yet. (And haven't really thought out how this would best be done. (One idea is, continuing with the WebDAV approach, to follow the Delta-V spec as a guide to SourceRepository abstraction layer). One other difference is is that I don't use the Request and Part objects directly as input. But an operation such as save() only gets called with two strings: input location and output location that are both resolved via the SourceResolver. This way you can use what you called at the GT 'pipeline T-ing' in order to do some preprocessing. Or you could use the recently added PartSource. Anyway from a flowscript it's as easy as: importPackage(Packages.org.apache.cocoon.components.repository); var repo = cocoon.getComponent(SourceRepository.ROLE); > > > Each method the service defines returns an integer > describing the exit > > status of the operation. This exit status closely follows > the WebDAV > > specification (RFC 2518). Now I think that this could map > very well to > > other editing environments like linotype as well which is > why I put it > > in repository for the time being. > > > > I know many of you have a lot of ideas about all these things so if > > people are interested in this, I'd like to hear what you think. > > Criticism, questions, suggestions, disagreements, any kind > of remark > > really that will be qualitively constructive is very much welcome. > > I just love the idea of having a much more solid "repository" > class for linotype to use. Even better would be the ability > to have such repository polymorphic and packaged as an avalon > block that I (from > linotype) can simply lookup and use... and using full IoC, > linotype does care if its writing on disk or writing on a > WebDAV server a thousand miles away. > > This is the first step for Doco (and for allowing me to edit > my weblog locally and rsync between webdav servers) so any > help in this direction will be MOSTLY welcome!!! > > keep up the great work! > Glad you like it :-) -- Unico > -- > Stefano. > > >
