I have committed the code I described at the GT
(http://wiki.apache.org/cocoon-data/attachments/GT2006Notes/attachments/12-CocoonBlocks.pdf).
So now we have a Spring based block architecture that is usable already
in 2.2 (of course there is still a lot of testing and stabilization work
left to do).
I have also removed all OSGi related stuff from the trunk. I still
strongly believe that we need OSGi to get a "real" plugin architecture
in Cocoon. But as I have written earlier it is better to base that on
the "official" OSGi-Spring integration. Right now the most important
thing is to get a 2.2 release, after that we can continue on the OSGi
integration work.
There is obviously need for documentation for the blocks framework, I
hope to find time for that later. For the moment there is the
presentation cited above. Some of the earlier documents are still partly
relevant:
The Servlet API based architecture described in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114237414521595&w=2 is
still essentially used, but we are using Spring instead of OSGi
declarative services. And the inter block component management that we
put a lot of work in, is replaced of the more primitive concept of a
global Spring component repository that all blocks contribute components to.
The description of the block source and the block path and property
modules in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111791016006393&w=2 is
still relevant.
To see some examples of how it work take a look at the
cocoon-blocks-fw-demo[12] for examples how to use pure Servlets as
blocks. And cocoon-blocks-fw-sample for sitemap based examples. The
forms, ajax, template and core samples are available through the blocks
fw as well as in the usual way. The blocks fw is found in
cocoon-blocks-fw-impl. All blocks are called through the
DispatcherServlet that already is configured in web.xml in
cocoon-webapp, so the examples are already running in the latest
checkout of trunk, nothing extra is needed to be done.
/Daniel
