You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Alexander Klimetschek <al...@mindquarry.com> on 2006/11/19 11:50:37 UTC
Re: Sub-sitemaps
Joerg Heinicke schrieb:
> Component inheritance is a standard functionality of Spring's
> ApplicationContext implementations. So this should be no problem at all.
Although this is not yet used in any way with the blocks. Two blocks,
where one inherits from another, don't know that the other one uses a
SitemapServlet, and the only interface between them is the servlet api.
Components you define in your sitemap might be known to Spring but its
about letting the TreeProcessor know how to resolve component names. So
I don't think it is possible at all to integrate that into the blocks fw.
BTW: What about those sitemap-additions directory?
> But I wonder if there is a replacement for "fallback to parent sitemap
> if no match was found in sub sitemap".
With the current blocks-fw implementation we put this matcher at the end
of all sitemaps that "inherit" from another block, ie. that have a
"super" block defined in the connections of the BlockServlet bean.
<match pattern="**">
<read src="block:super:/{1}" />
</match>
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Sub-sitemaps
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Alexander Klimetschek skrev:
> Joerg Heinicke schrieb:
>> Component inheritance is a standard functionality of Spring's
>> ApplicationContext implementations. So this should be no problem at all.
>
> Although this is not yet used in any way with the blocks. Two blocks,
> where one inherits from another, don't know that the other one uses a
> SitemapServlet, and the only interface between them is the servlet
> api. Components you define in your sitemap might be known to Spring
> but its about letting the TreeProcessor know how to resolve component
> names. So I don't think it is possible at all to integrate that into
> the blocks fw.
This is by design.
In earlier incarnations of the block architecture, the idea was to have
component inheritance (and polymorphism) as well as servlet inheritance
(or rather sitemap inheritance). We had some discussions about what this
would mean at the list, and the main conclusion is that it gets rather
complicated. You need to make sure that components always are executed
in the right context and classloader and this gets really messy when
combine with polymorphic block protocols that communicate over SAX events :/
And even if we had the energy and ability to solve these problems, I
that the concept of mixing component reuse and servlet reuse is flawed
and overly complicated anyway.
IMO, it is much better to consider component management and servlet
reuse as separate concerns as we do in the current architecture. The
blocks fw takes care about servlet reuse. For component reuse we have
Spring. Now the current mechanism for component reuse with Spring in
Cocoon is rather basic, we could get much further by using OSGi and the
OSGi-Spring bridge. But we should probably try to release 2.2, before
starting to work on that ;)
> BTW: What about those sitemap-additions directory?
Didn't we remove them?
/Daniel