Re: [RT] Implementing Cocoon Blocks

Geoff Howard Fri, 19 Sep 2003 19:33:04 -0700

Stefano Mazzocchi wrote:

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

Stefano Mazzocchi wrote:

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.


So, what does a block use from another block if not a component?  I've
been thinking that neither file resources or classes would be accessible
directly.  So all that's left is components (either sitemap components
or no)? (ah, source resolving through block: protocol?)  In the example
what does the first block (@id="cob:mycompany.com/webmail/1.3.43") use
from cob:mycompany.com/skin aka "external-skin"?  I'd guess all that's
left is resolving sources through the block: protocol?  So this would
mean there's a block:external-skin which will probably be some xsl file?
 If it's a virtual component, would this need to be declared on both
the provider and requirer as a component?

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>

Sounds good. You snuck in type="hidden-string" by the way which raises the question: what are the allowable values of type? string, integer, hidden-string, (basic "primitive" values) or complex values like "phone-number" or "ip address"? No need to enumerate specifics now, but the general concept might be good to address. And is it extensible?

  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>


Ok, but we have now at least three different attribute names describing
the block uri/id: id, behavior, and block which may be harder to
remember and to identify that these things go together.  I'd propose
using only two:
- @id to identify the definition of the unique block element
- @block to refer to this id elsewhere. (alternatives: @behavior,
@contract ...)

So that becomes
    <implements block="cob:mycompany.com/skin/1.2"/>

I'm not convinced of this, but wiki'd it that way just to try it out.
The distinction of @behavior and @block does kind of make sense to me
but here's a question:

The implements uri and the requires uri match up based on versioning
rules but are separate for wiring purposes from the @id.  But in the
scenario:
  cob:yetanothercompany.com/skins/fancy/1.2.2
    implements -> cob:mycompany.com/skin/1.2

  cob:mycompany.com/skins/corporate/34.3.345
    implements -> cob:mycompany.com/skin/2.3
    extends -> cob:yetanothercompany.com/skins/fancy/1.2.2

Does cob:mycompany.com/skins/corporate/34.3.345 also implicitly
implement cob:mycompany.com/skin/1.2 because it extends
cob:yetanothercompany.com/skins/fancy/1.2.2?

Also, does the fact that no component initially defining
cob:anothercompany.com/MailRepository/2.0 exists here matter?

With this and the above questions I'm trying to get at where the hidden
contracts are.

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.

ok

...

<provides role="com.anothercompany.repository.Repository"/>
change role to component? [role is avalon terminology and might confuse non-avaloners]


I'm ok either way.  I think "role" is very easy to grasp as the more
general concept and "component" could get confused between the role and
the implementation of that role.  Still, I've wiki'd it with component
for now unless you or others find that argument compelling.

Here's the provides which might also be "exposes".
both are fine for me.

me too.

Ok, I've wiki'd the latest with my proposal about @id and @block included.

Geoff

Re: [RT] Implementing Cocoon Blocks

Reply via email to