cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinhard_po...@yahoo.de>
Subject Re: [2.2] Dynamic xconf try to open non-existing files (bug?)
Date Sun, 13 Feb 2005 17:05:29 GMT
Daniel Fagerstrom wrote:
> 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.

I think your ideas lead into the right direction! Though I think we should agree 
on a feature freeze *now* and release ASAP. Then we can continue the discussions 
about blocks - maybe at a special blocks hackaton :-).

WDYT?

-- 
Reinhard Pötz           Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------


Mime
View raw message