cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [2.2] Dynamic xconf try to open non-existing files (bug?)
Date Sat, 12 Feb 2005 22:58:14 GMT
Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>>
>>>> The more it think about this, the more I believe that <imports> 
>>>> should not be done explicitly but implicitly, based on some 
>>>> aggregated dependency information (for example, the blocks should 
>>>> have their block descriptor block.xml and include the dependency 
>>>> information there)
>>>>
>>> I think this is not too hard to do: a simple ant task that copies 
>>> the xconf for a block into the xconf directory and adds all include 
>>> statements.
>>>
>>> If I have time, I will look into that this weekend, but can't 
>>> promise anything :)
>>
>>
>> The include features in xconf allows to very simply add or remove a 
>> block by just moving files around. I would like to keep this 
>> simplicity and avoid by all means to go back to some build-time 
>> generation of these files like we have today with xpatch in 2.1
>
>
> Amen.
>
>> There aren't that much inter-block dependencies, and I don't have the 
>> feeling hand maintaining them is really complicated.
>
>
> 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!?!


Mmmh... maybe not that much, but this requires a naming and/or lookup 
scheme for these files. We could enumerate all files having the same 
name ClassLoader.getResources() but I suspect we'll be encountering some 
problems related to classloader hierarchies. Or we can include it from a 
block's xconf using "resource://" as we already do it for roles.

Several points come to mind also:

1) we are defining a strong contract for the location and names of block 
xconf files, namely "context://WEB-INF/xconf/cocoon-${block}.xconf" 
whereas today they can be placed anywhere because they are explicitely 
included. I have nothing against this, but this contract must be well 
stated and defined as we will live with it for a long time.

2) how is this related to gump.xml, which already contains inter-block 
dependency information? Can gump.xml be generated from the various 
block.xml files or does Gump require it to be a static resource? I 
personally would prefer gump.xml to be generated from the various blocks 
as the dependency information belongs to the block rather than to a 
centralized resource.

3) we've seen that some inter-block dependencies only come from the 
samples. That means we must be able to distinguish real block 
dependencies from the additional dependencies brought by samples.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message