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] Rethinking the SourceResolver concept
Date Mon, 20 Oct 2003 13:50:29 GMT


Carsten Ziegeler wrote:
> 
> Unico Hommes wrote:
> > 
> > Carsten Ziegeler wrote:
> > > 
> > > Now, I think we can make it simpler :)
> > > a) A sitemap component gets a Cocoon source resolver anyway.
> > >   We can provide in the setup() method a wrapper for
> > >   the Avalon SourceResolver that knows it's sitemap. This
> > >   is simply and doesn't need thread locals etc. anymore.
> > > b) The only problem lies in all this nice little thread
> > >   safe components that resolve URIs relative to the
> > >   current sitemap. 
> > > One solution for b) is to say, relative paths are always
> > > resolved to the context directory of cocoon than we can
> > > remove a lot of the hacky things. But I fear this might
> > > break some things.
> > 
> > I fear this as well but think it will make the contract much 
> > clearer too, so I would be in favor of changing the 
> behavior in this way.
> > 
> > The way I understand it is that cocoon has a hierarchical 
> > containment model. The root container manages components declared 
> > in cocoon.xconf and the child containers each manage the 
> > components of the sitemap they represent. A SourceResolver is 
> > contextualized against the current sitemap (= container context 
> > managing the sitemap components). Therefore it means that each 
> > container in the hierarchy should provide its own SourceResolver 
> > contextualized relative to its own context instead of following 
> > the traditional ECM paradigm of inheriting all components it does 
> > not specifically declare itself from the parent container.
> I'm currenlty implementing exactly this for 2.2.
> 
> > 
> > Hmm. But shouldn't *any* contextualizable component that lives in 
> > a hierarchical containment model *always* be contextualized 
> > against the container it was looked up on? Shouldn't that 
> > actually be part of the Contextualizable contract? I would say 
> > that goes without saying (no pun intended :-). What about 
> > components that have a dependency on components that are 
> > contextualizable? ad infinitum?
> > 
> This is exactly the problem. You define a nice service that
> takes in any uri (relative and absolute). This service
> is defined at the root CM but is called from everywhere,
> so e.g. from a sub sitemap. Now, in order to work
> correctly this nice service has to know the context
> of the sub sitemap (ok, not this service by itself,
> but the source resolver the service uses).
> 

Yes, but I think we should just either say that

a) the service will not be able to resolve against the current sitemap context, i.e. it will
be relative to the root CM.
b) the service will not be one instance per container hierarchy but one instance per container
so that it is local to the current sitemap container and receives the SourceResolver that
belongs to it.

Perhaps this is a matter of defining a seperate lifestyle for b) ?


Mime
View raw message