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 -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
