cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Rethinking the SourceResolver concept
Date Mon, 20 Oct 2003 14:00:44 GMT
Unico Hommes wrote:
> > > 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) ?
>
Ok, a) will break existing implementations (as noted) which might be
ok, but is not really a change users want to see, I guess.
I'm not sure, but if you go for b) wouldn't that mean that you
have to declare *all* components on each sitemap?
Situation: two CMs, A being the parent of B.
A: Component One - using Component Two
   Component Two - using the Source Resolver (this falls into category b
from
                   above)
B: Component Three - using Component One

As Component Two uses the Source Resolver, it has to be defined
in CM B as well, so we get:

B: Component Three - using Component One
   Component Two - using the Source Resolver (this falls into category b
from
                   above)
Now, Component Three looks up Component One (from CM A) and this looks up
Component Two, also from CM A - and the source resolving doesn't work
as expected anymore.

Carsten


Mime
View raw message