cocoon-dev mailing list archives

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

On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:

> Date: Fri, 13 Jan 2006 11:19:26 +0100
> From: Daniel Fagerstrom <danielf@nada.kth.se>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> 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?

+1

> 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 - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDx510LNdJvZjjVZARAitjAJ4/THIUZlyO6Nx366GQ3mLp4RMSLACgsaZQ
21EkasoE8rnwPmWYgx3F884=
=7xhp
-----END PGP SIGNATURE-----

Mime
View raw message