Carsten Ziegeler skrev:
Giacomo Pati wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
My goal is having a completly self-reloading Cocoon application that also
includes the block dispatching mechanism and not only at sitemap level. (As a
side note: We shouldn't consider sub-sitemaps as the number one way of
modularization in Cocoon anymore).
I think this side note is very important - and this remembers me about
my pending proposal to remove sub sitemaps completly.
Hey guys, what does that mean? No more blocks?
No, no, quiet the opposite. With the new block architecture and the
dispatching stuff Daniel wrote, you can mount sitemaps in the spring
context by just defining a sitemap servlet (I don't know the exact term,
but I hope this gives an impression) which is configured with two
values, the mount path and the sitemap location.
The dispatcher servlet looks for all Spring managed components that
implements the Servlet interface and has a mountPath property. The
dispatcher servlet will dispatch to the mounted servlet which mount path
is the longest prefix of the path info.
So we could have had a Spring managed sitemap servlet as with a sitemap
path and a mount path property as you describe above. Such a sitemap
servlet bean would need to have some extra code for getting the servlet
context right and geting the initialization order right.
Instead we have a special block servlet that embed an ordinary (non
managed) servlet as e.g. the sitemap servlet. It also provide some extra
functionality like the polymorphic block protocol.
I'm not sure but I
think we already have running examples somewhere in our tree.
Sure :)
Take a look at
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/META-INF/cocoon/spring/cocoon-forms-sample-blockServlet.xml,
for an example that make the forms samples available through the
dispatcher and block servlet. It should work OOTB in the
cocoon-dist-samples if you point you browser to
http://localhost:8888/blocks-test/cocoon-forms-samples/.
Some more of the features, like connecting to other blocks servlets with
DI is demonstrated in the blocks fw samples:
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/resources/META-INF/cocoon/spring/.
In the cocoon-blocks-fw-demo[1|2] there are examples using the block
servlet with other servlets than the sitemap servlet.
By this, you mount new functionality just by adding your components to
the spring context and that's it. These components (or servlets) are
called "directly" from the dispatching servlet without going through the
main sitemap.
So if you have two sitemaps in your block, one for /myblock and one for
/myblock/misc, then you add two component definitions to the spring
context and you don't have to mount the misc sub sitemap in the myblock
sitemap.
Exactly.
Removing the need of sub sitemaps would make our architecture and
implementation *much* cleaner.
Agree.
But isn't the main problem component configurations in sub sitemaps?
Wouldn't it be enough (from architectural cleanliness POV) to remove the
ability to define components in sub sitemaps?
/Daniel
