Carsten Ziegeler wrote:
>
> Unico Hommes wrote:
> >
> > I haven't thought it all the way through either but I see some
> > complexity arising now.
> >
> > For instance in a subsitemap the components container must inherit
> > from the supersitemaps components container. But the
> subsitemaps node
> > container needs to inherit from both the supersitemaps node
> container
> > and the subsitemaps component container. This cannot be
> accomplished
> > by allowing the subsitemap component container to inherit from the
> > supersitemap node container because then the subsitemap components
> > would have access to the supersitemap nodes. Still with me ;-)
>
> Yes :)
>
> >
> > It looks as if some kind of multiple container inheritance
> is needed?
> >
> Hmm. Ok, for me this sounds too complex, but the current
> approach is not safe as any component can lookup a tree
> processor node. Is this right?
>
Correct.
> So we need an easy and safe solution. Perhaps using the
> container to build the tree is not the right way to go? (I
> really don't know)
>
I haven't had doubts that hosting nodes as components in an IoC
container is a good approach, I think it makes perfect sense in light of
a sitemap's inheritable nature. What I *have* been having doubts about
is the way the container is now being configured from a sitemap
following a transformation to a general container configuration, but
that may be another story alltogether.
I think that defining a separate lifecycle extension for nodes in
combination with a semantic restriction on sitemap components that says
they must not implement Node will work well.
For instance, we could define:
interface Node {
/** creation time LFE */
setup(Context context, ServiceManager manager);
}
where context and manager parameters contain private objects that are
not available to their equivalents passed in through contextualize and
service respectively.
The LFE should just make sure the component it services is not a sitemap
component.
Wouldn't that work?
Unico
