cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject RE: defaulting to a matcher when another one is not present
Date Tue, 08 Oct 2002 18:44:11 GMT
On Mon, 7 Oct 2002, 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.
>
> > >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?

I agree in global with Carsten. If a sitemap hands over a hierarchy of the
URI space to a subsitemap it should be responsible to handle it
*completely*. This is in total harmony with the hierarchical structure
choosen for the sitemap design.

If a subsitemap is not handling all URIs the parent sitemap should take
into consideration using different matching patterns (i.e. regexp)

Giacomo

>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message