cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [RT] Implementing Cocoon Blocks
Date Thu, 18 Sep 2003 02:51:26 GMT
Stefano Mazzocchi wrote:

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



Mime
View raw message