cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [2.2] Dynamic xconf try to open non-existing files (bug?)
Date Sun, 13 Feb 2005 15:43:15 GMT
Carsten Ziegeler wrote:

> Stefano Mazzocchi wrote:
>
>>
>> What I would like to see is something like this:
>>
>> 1) src/block/*/block.xml
>>
>> that contains something as simple as
>>
>>  <block name="a">
>>   <depends-on block="b"/>
>>   <depends-on block="c"/>
>>  </block>
>>
>> 2) this info used by cocoon at startup time (NOT COMPILE TIME!) to 
>> drive the xconf imports.
>>
>> How hard can that be!?!
>>
> Go ahead :)
>
> Seriously: imho we have too many places that have to be maintained 
> with such a solution: you have to update gump.xml and this block.xml. 
> I think one of the two locations should simply be enough and we can 
> generate the other one.
> So, do we want to generate gump.xml (or parts of it) out of the 
> block.xml or otherwise?

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.

/Daniel




Mime
View raw message