Carsten Ziegeler wrote:
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.
+1
I think part of the work concerning design and implementation of compiling blocks based on a blocks descriptor is allready done by Reinhard in http://wiki.apache.org/cocoon/BlockBuilder and http://svn.apache.org/viewcvs.cgi/cocoon/whiteboard/block-builder/. Reinhard, needs to be done to achive that?
see my other mail - if nobody objects I will setup the block-builder in Cocoon 2.2 over the weekend. Then we can decide if we like it or not.
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.
That's the task for Reinhard's block deployer, but as it AFAIU is targeted more for real blocks than for the current ones, it might be overly ambitious to start using it now.
The design of the block deployer could cover the blocks that we have now too. But the implementation isn't far enough.
In the mean time, replacing the blocks.properties with a list of paths to the blocks that one want to use might be enough.
We also need to decide where we should put the blocks in the SVN, we could follow Reinhard's approach in the block-builder and moving the trunk/src/blocks/ directory to the top level and inserting a trunk directory:
/cocoon/blocks/forms/trunk/ ...
However IMO we should as a service to our users and ourselves, be a little bit more explicit in how much trust one can put in the various blocks and have something like:
core-blocks supported-blocks unsupported-blocks
Where everything goes to unsupported-blocks and promotion to core and supported is based on votes. OTH, moving the blocks out of trunk and indicating community support level are different concerns so we could do one at a time and I think moving out the blocks should have highest priority.
WDYT?
What about
/cocoon/blocks/core/ /cocoon/blocks/supported/ /cocoon/blocks/unsupported/
I like the structure but which one of the three directories would be the appropriate one for the templating block?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
