cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Implementing Cocoon Blocks
Date Fri, 19 Sep 2003 14:03:50 GMT

On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:

> 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.

yes

> - the sitemap element will force the deploy process to prompt for a 
> mount point (we may want to allow for a default suggested one)

correct.

> I wasn't sure what "uses component" meant functionally.

the blocks declares what component is going to use from that block and 
will name it. This is the inverse of the cocoon.xroles file but does 
the same thing, providing a shorthand version of the role identifier in 
the context of that block.

> 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. :)

Ok, let me try again:

<block xmlns="http://apache.org/cocoon/blocks/cob/1.0"
        id="cob:mycompany.com/webmail/1.3.43">
   <sitemap src="/webmail.xmap"/>
   <requirements>
    <requires
        block="cob:mycompany.com/skin"
        name="external-skin"
    />
    <requires
        block="cob:mycompany.com/skin/2.0"
        name="internal-skin"
    />
    <requires
        block="cob.anothercompany.com/MailRepository/2.0"
        name="repository">
      <uses
          component="com.anothercompany.repository.Repository"
          name="repository"
      />
    </requires>
   <requirements>
   <parameters>
    <param name="user" type="string"/>
    <param name="password" type="hidden-string"/>
   </parameters>
  </block>

>>   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?

well, in theory, we implement the block behavior that is identified by 
that URI. So I would write it as

  <block xmlns="http://apache.org/cocoon/blocks/cob/1.0"
         id="cob:yetanothercompany.com/skins/fancy/1.2.2">
    <implements behavior="cob:mycompany.com/skin/1.2"/>
  </block>

> 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?

yes. you need to specify *exactly* what behavior you are implementing. 
you cannot implement a range of behaviors, that can potentially lead to 
inconsistent states.

>>   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.

<extends block="cob:yetanothercompany.com/skins/fancy/1.2.2"/>

same as above

>>   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">

change uri to ID

>     <implements uri="cob:anothercompany.com/MailRepository/2.0"/>

change uri to behavior

>     <provides role="com.anothercompany.repository.Repository"/>

change role to component? [role is avalon terminology and might confuse 
non-avaloners]

>     <parameters>
>       <param name="host" type="string" default="127.0.0.1" />
>     </parameters>
> </cob>
>
> Here's the provides which might also be "exposes".

both are fine for me.

>   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.

yep

comments?

--
Stefano.


Mime
View raw message