cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: defaulting to a matcher when another one is not present
Date Mon, 07 Oct 2002 12:23:38 GMT

Sylvain Wallez wrote:
> >>
> >No, I don't agree here. Yes, components are inherited and yes 
> views should imho also be inherited, but this is a 
> one-way-street. The main sub sitemap gives control to the sub 
> sitemap. You can't use components declared in the sub-sitemap in 
> the main sitemap etc.
> >  
> >
> I guess there's a misunderstanding here : what I understand in the above 
> is that you don't want a pipeline to be partially built in a subsitemap 
> and terminated in the parent sitemap.
> *I fully agree with this* : a subsitemap should either fully handle the 
> request (from generator to serializer) or not handle it at all.

> What is proposed is different and is only about giving control back to 
> the parent sitemap if a subsitemap did not handle the request, i.e. 
> there was no match in the subsitemap.
Ok - thanks for the clarification.

> >>>3) Before you consider implementing this simple sounding 
> change, have a look at all the component manager and source 
> handling stuff which takes place when a sub sitemap is invoked - 
> it's very difficult to implement your wantet behaviour without 
> breaking everything.
> >>>
> >>Why is this so difficult ? The environment context is changed 
> when mounting a subsitemap. Will it be difficult to restore the 
> context when "unmounting" a sitemap ?
> >>
> >Yes, I think so - I haven't looked too much into the code but I 
> remember that there will be some problems with respect to the 
> special lifecycle interfaces handled by the CocoonComponentManager.
> >
> With the above clarification (no cross-sitemap pipeline building), will 
> those problems arise ?

> >And sorry, I really think that this idea comes near to FS - but what
> >do others think about this?
> >
> When several people have a good use case for something, then this may 
> not be FS but a real need. So let's see what comes out from this 
> discussion.


To unsubscribe, e-mail:
For additional commands, email:

View raw message