cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Block deployment: working with blocks from a user's point of view
Date Fri, 13 Jan 2006 12:30:42 GMT
Hash: SHA1

On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:

> Date: Fri, 13 Jan 2006 11:19:26 +0100
> From: Daniel Fagerstrom <>
> Reply-To:
> To:
> Subject: Re: Block deployment: working with blocks from a user's point of view
> Reinhard Poetz skrev:
>>  Giacomo Pati wrote:
>>  <snip/>
>> >  In Reinhards document it is META-INF/block.xml on the Wiki it's 
>> >  COB-INF/block.xml. So we need to make a decision:-)
>>  Please use META-INF/block.xml, AFAIK we agreed on making our blocks valid
>>  JAR files.
> Ok.
> ...
>> > >  Now to answer your question ;) the position of the .xconf of a block 
>> > >  is defined in the components element of block.xml.
>> > 
>> >  Ok, looking at [1] it is defined in the block.xconf file, which is 
>> >  located in COB-INF (or WEB-INF or META-INF respectively). Is that still 
>> >  correct?
>>  I'm not sure where block.xconf should go to. I'd put it under cocoon-app
>>  and not under META-INF. WDOT?
> block.xml contains or point to the block.xconf, so it can be place anywhere.

I haven't found any formal specification about this "pointer to 
block.xconf". The only thing I've found on the wiki if 
COB-INF/block.xconf (so now META-INF/block.xconf).

> But if we should have a default place, wouldn't META-INF be the most natural 
> place?


> Also, even if it isn't implemented yet, the idea is to make the choice of 
> component container configurable, something like:
> ...
>   <components class="org.apache.cocoon.core.container.CoreServiceManager">
>     // Container specific configuration
>  </components>
> ...

Hmm.. the tricky part will be how to instantiate such a 
(unknown) FQCN from the class attribute. This needs a formal interface 
which such ServiceManagers must implements to allow the Deployer (or is 
it the BlockManager) to initialize the component container.

> So a default name isn't possible.

Except you only allow containers know to us and instead of a class 
attribute you'll have a type (or whatever) attribute which you can 
select from the implenetations we do have. Of course this way it isn't 
individually extensible.

- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message