Daniel Fagerstrom wrote:
I think we should really start and move all blocks out of the core
I would prefer generating gump.xml from block.xml. It will be easier to develop and deploy (external) blocks if all info about them is contained within the block. Also it is better to have a block.xml format that not is dependent on gump's format as it allow us to put all info that we want to have about blocks in that file.
IIRC we went for the gump solution as we where concerned about the lack of robustness in generating the gump.xml on demand. Also the gump format was close enough for our needs back then. But now I think that the centralized gump.xml is in the way for a smooth evolution towards "real" blocks. The robustness issue can maybe be handled in other ways, e.g. compile time checks of the block.xml, so that no one happens to check in a faulty block.xml that kills the compilation.
Thinking further about it: could not the blocks be own Gump sub projects that depends on Cocoon core? If that is possible it would only be necessary to have a list of the blocks that we want to have checked by Gump, no need for a centralized list containing all block dependencies.
(for 2.2 - 2.1.x should stay as is) and then it would make sense for me to have
an own gump descriptor for each block.
I also agree that it's better to generate the gump descriptor from the block descriptor than vice versa. If we go this road, there is only one issue to solve: how does Cocoon know which blocks are available? Just scanning the src/blocks directory isn't enough. Blocks can be anywhere in the file system. The current build system is able to include blocks from any location.
Carsten
-- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
