cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: [RT] SourceRepository and davmap
Date Fri, 31 Oct 2003 16:27:23 GMT
 

Stefano Mazzocchi wrote:
> 
> 
> On Thursday, Oct 30, 2003, at 16:28 Europe/Rome, Unico Hommes wrote:
> 
> > Not all functionality of the Linotype SourceRepository is 
> implemented.
> > For instance I have not gotten to the versioning part yet.
> 
> ok
> 
> > (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).
> 
> sounds like a good idea to me.
> 
> > 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.
> 
> I'm not sure I follow you here, can you elaborate more on this?
> 

For instance, in the davmap flowscript I do something like:

var repository = cocoon.getComponent(SourceRepository.ROLE);
function put() {
  var input = cocoon.parameters["in"];
  var output = cocoon.parameters["out"];
  var status = repository.save(input,output);
  cocoon.sendPage("cocoon:/status/" + status, {});
}

In the sitemap there is a matcher that generates the input that is to be
saved:

<!-- generates the body of the request for PUT actions
     here you can customize and/or validate the input 
-->
<map:match pattern="request/PUT">
  <map:generate type="stream" />
  <!-- eg.:
  <map:transform type="badlanguagechecker" />
  -->
  <map:serialize type="xml" />
</map:match>

... And this one is matched after a PUT request:

<map:match pattern="PUT/**">
  <map:call function="put">
    <map:parameter name="in" value="cocoon:/request/PUT" />
    <map:parameter name="out" value="file://myrepo/{1}" />
  </map:call>
</map:match


In the case of Linotype the "in" parameter above could either be a
cocoon:/ source location like in the davmap case or in the case of
uploading a file a string that is resolved to 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);
> 
> Cool, that's exactly what I wanted. Where does the 
> polymorphism take place? at the cocoon.xconf level?
> 

Yes we could make it so.

Currently there is only one SourceRepositoryImpl. And the interface
actually specifies that the implementation follows WebDAV behavior. To
take advantage of polymorphism we'd need to let implementations more
freedom than that. Make the contract so that it only states that http
codes are returned to communicate status information but let
implementations decide what those codes are or how to actually behave.

Take for example the delete() method. WebDAV specifies that "the DELETE
method on collections must act as if Depth:infinity header was specified
on it". This is behavior that different editor environments may want to
redefine. We could opt to make one large service interface that defines
all possible scenarios. (In the case of the delete() method it would
mean adding a depth parameter for instance.) Or we could go with what
you seem to be suggesting and keep the interface small and leave it up
to the individual implementations to adapt the behavior to their needs.
I think I like your approach better because before you know it you've
put all the complication back into the flow layer again because you need
to specify a thousand things before when using the service layer. It
also reduces complexity of the code in SourceRepository as well.

Just to clarify some of my thinking about this. My idea of the
SourceRepository component is a kind of utility service that hides some
nitty gritty details for persistent operations on Sources. This could
all be done in the flow layer as well, but not as nicely as in Java
where you have better exception handling, polymorphism proper, Avalon
style IoC, as you point out.

In my mind the responsibilities are as follows:

- sitemap: parses request space; calls flow layer; defines views (both
input and output);
- flow: glues sitemap and service layer; defines page flows; coordinates
authentication;
- service layer: do all the complicated low level stuff and report back
to flow; provide software hooks to interested parties; do logging;

The responsibilities of the SourceRepository here is a bit more confined
than the current Linotype one that also has some code for parsing
versioning information from the request IIRC. But I think this does
establish a clearer SoC this way.


-- Unico


Mime
View raw message