The block descriptor file contains a reference to the root sitemap of the block. In Cocoon the main configuration (cocoon.xconf) is the starting point instead. In the http environment the configuration file can be defined in web.xml or is taken from its default position. Then the root processor is configured with e.g.:

  <sitemap file="context://sitemap.xmap"/>

Starting from the sitemap instead of from the configuration could simplify things for the blocks authors as they don't need to write a configuration file for a simple block and can define the compnents in the sitemap instead.

But there is still the question how the block sitemap should be configured, should it get the reload parameter from the Cocoon root sitemap, and what about the config attribute? Also there is the question if there should be a "block.xconf" and how it should be related to the sitemap.

IMO we should have the same behaviour in blocks as in the "main Cocoon". So if we have the sitemap as "main configuration" in blocks we should allow the same in the "main Cocoon".

To simplify prototyping of the block manager I let block.xml point at the block configuration file instead as a temporary solution.

                      --- o0o ---

So, what is your opinions about this, has it been discussed before?

/Daniel

Reply via email to