Re: [RT] Implementing Cocoon Blocks

Stefano Mazzocchi Fri, 19 Sep 2003 07:03:31 -0700

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.

Re: [RT] Implementing Cocoon Blocks

Reply via email to