Ok, after reaching some stasis on wiring.xml, starting the discussion on cob.xml (or whatever). I expect that both of these will be much more interesting discussions after real implementation starts.
> Implementation Phases > --------------------- > > Phase 1: definition of the contract between the block manager inside > cocoon and the standalone block deployer. These contracts include:
... > 3) description of the block metadata schema
So, here's a proposed simple xml version (each xml snippet would be it's own cob.xml of course):
File System Layout and wiring data ----------------------------------
Let us suppose we have the following blocks that are deployed in our system
cob:mycompany.com/webmail/1.3.43 has a sitemap located on -> /webmail.xmap depends on -> cob:mycompany.com/skin names this dependency -> external-skin depends on -> cob:mycompany.com/skin/2.0 names this dependency -> internal-skin depends on -> cob:anothercompany.com/MailRepository/2.0 names this dependency -> repository uses component -> "com.anothercompany.repository.Repository" names this component with role -> repository requires the configurations: "user" of type string with no default "password" of type string with no default
<cob xmlns="http://apache.org/cocoon/blocks/cob/1.0"; uri="cob:mycompany.com/webmail/1.3.43"> <sitemap src="/webmail.xmap"/> <dependencies> <depends-on uri ="cob:mycompany.com/skin" name ="external-skin" /> <depends-on uri ="cob:mycompany.com/skin/2.0 name ="internal-skin" /> <depends-on uri ="cob:anothercompany.com/MailRepository/2.0" name ="repository" > <component role="com.anothercompany.repository.Repository" name="repository"/> </depends-on> </dependencies> <parameters> <param name="user" type="string" /> <param name="password" type="string" /> </parameters> </cob>
I'm assuming here that:
- all parameters will be required and declaring them with no @default will force the deployer to supply a value.
- the sitemap element will force the deploy process to prompt for a mount point (we may want to allow for a default suggested one)
I wasn't sure what "uses component" meant functionally.
For the record, I hate <dependencies> and <depends-on> and I left them that way in the hope that they are so offensively bad that someone will think of a better one. :)
cob:yetanothercompany.com/skins/fancy/1.2.2
implements -> cob:mycompany.com/skin/1.2
<cob xmlns="http://apache.org/cocoon/blocks/cob/1.0"; uri="cob:yetanothercompany.com/skins/fancy/1.2.2"> <implements uri="cob:mycompany.com/skin/1.2"/> </cob>
do we implement a uri? Is it right to specify the whole version here and let the versioning rules specified in the RT work out that this satisfies <depends-on uri="cob:mycompany.com/skin" name="external-skin"/> from above?
cob:mycompany.com/skins/corporate/34.3.345
implements -> cob:mycompany.com/skin/2.3
extends -> cob:yetanothercompany.com/skins/fancy/1.2.2
<cob xmlns="http://apache.org/cocoon/blocks/cob/1.0"; uri="cob:mycompany.com/skins/corporate/34.3.345"> <implements uri="cob:mycompany.com/skin/2.3"/> <extends uri="cob:yetanothercompany.com/skins/fancy/1.2.2"/> </cob>
Extends is introduced here, same questions as implements.
cob:mycompany.com/repositories/email/exchange/3.2.1
implements -> cob:anothercompany.com/MailRepository/2.0
exposes component -> "com.anothercompany.repository.Repository"
requires the configurations:
"host" of type string, with default "127.0.0.1"
<cob xmlns="http://apache.org/cocoon/blocks/cob/1.0"; uri="cob:mycompany.com/repositories/email/exchange/3.2.1"> <implements uri="cob:anothercompany.com/MailRepository/2.0"/> <provides role="com.anothercompany.repository.Repository"/> <parameters> <param name="host" type="string" default="127.0.0.1" /> </parameters> </cob>
Here's the provides which might also be "exposes". Also, here's an example of a default provided for a param. During install, the block manager would prompt the admin to provide a value but would not be required because a default is given.
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
Geoff
