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.
> >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. And sorry, I really think that this idea comes near to FS - but what do others think about this? Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]