cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: defaulting to a matcher when another one is not present
Date Mon, 07 Oct 2002 11:54:38 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Carsten Ziegeler wrote:
>>>Currently I'm -0 but with a tendency to -1.
>>>Why? I see these reasons:
>>>1) This is an incompatible change - currently if nothing matches in the subsitemap,
the error handler is invoked and people rely on this, so this will break many installations.
>>Agree : this behaviour should be explicitely written in the mount. This can go through
and additionnal attribute such as <map:mount src="sub/" must-match="false">
>>The "must-match" (or a better name) attribute tells if the request must be handled
by the request and defaults to true to ensure backwards compatibility.
>>>2) I think it is more natural if a sub sitemap is invoked that it is the sole
responsibility of this sub sitemap to process the request.
>>That's true if you consider each subsitemap to be a fully autonomous subapplication,
but not if you consider the top-level sitemap to be a sort of container providing global services
to subsitemaps.
>>Considering also that a parent sitemap already provides components to subsitemaps,
this doesn't seem so unnatural. Some people also asked views to be inherited by subsitemaps,
which also goes in this direction.
>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.

>>>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.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message