-----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 <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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-----
