cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: defaulting to a matcher when another one is not present
Date Mon, 07 Oct 2002 11:15:34 GMT
<snip/>

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

...

> And sorry, I really think that this idea comes near to FS - but what
> do others think about this?

This reminds me on the cocoon get-together at the cebit where someone wanted 
components _not_ to be inherited.

I have to admit that I stumbled over the same question as Ovidiu did lately.

What happens (or should happen) if you have an unmatched uri that's within the 
scope of a subsitemap. If the subsitemap is fully autonomous it should handle 
the error. But if not - shouldn't it be passed to the parent sitemap? 
Otherwise I would have to define the error handling in each subsitemap.
This doesn't sound like FS to me. In fact it could reduce redundancy a lot...

Well, I do think we need at least some clearer definitions here. (Do we have 
anything explicitly stated in the docs yet?)
--
Torsten

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


Mime
View raw message