Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F6CC707.2000508@leverageweb.com>
Date: Sat, 20 Sep 2003 17:30:47 -0400
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Implementing Cocoon Blocks
References: <AB1451EA-EB66-11D7-B98A-000393D2CB02@apache.org>
In-Reply-To: <AB1451EA-EB66-11D7-B98A-000393D2CB02@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

> On Saturday, Sep 20, 2003, at 04:34 Europe/Rome, Geoff Howard wrote:
> 
>> 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?
> 
> pipelines and virtual pipeline components

Ok.  pipelines if a sitemap is declared, and virtual pipeline components
if they are "provide"-ed or exposed.

Also below though they expose files (xsl)...

>>  I've
>> been thinking that neither file resources or classes would be accessible
>> directly.
> 
> yep

But from the example below there's obviously a shade of meaning in 
"accessible directly".  They are accessible through the block protocol, no?

>> So all that's left is components (either sitemap components
>> or no)? (ah, source resolving through block: protocol?)
> 
> the blocks carry three things:
> 
>  1) pipelines (called via the block: protocol)
>  2) avalon components (accessed via the component manager)
>  3) pipeline virtual components (declared in your sitemap)

and file resources as below?

>> 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?
> 
> yep
> 
>>   So this would
>> mean there's a block:external-skin which will probably be some xsl file?
> 
> no.
> 
> block:external-skin identifies the root of the URI space addressed by 
> that block. You could do things like
> 
>  block:external-skin:/stylesheets/news2html.xslt
> 
> that would return a stylesheet. And so on.

So where is the fact that external-skin can be expected to provide 
/stylesheets/news2html.xslt recorded?  Is it implicit because the 
resource is actually there in the block?  Is it only available if a 
pipeline matches it (eg <map:match 
pattern="stylesheets/news2html.xslt"><map:read 
src="stylesheets.news2html.xslt... ).  Can it be assumed that any 
physical file resource in the block can be considered "provided"?

I think there may be a danger here, a parallel to the problem we face 
when public methods are arbitrarily overridden.

The alternative would be some list of publicly available resources 
available through "block:".  I'd guess we'll want to avoid anything 
other than public or private (declared or not declared) - i.e., no 
package private, no protected, etc.

Oh, and while we're abusing the java analogy, how many <implements> and 
<extends> are allowed?  I'd think 1 each but I haven't thought it out.

>>  If it's a virtual component, would this need to be declared on both
>> the provider and requirer as a component?
> 
> Yes, because the virtual component doesn't have a java classname that 
> can be used to uniquely identify it.

...

>> 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"?
> 
> KISS
> 
>> No need to enumerate specifics now, but
>> the general concept might be good to address.  And is it extensible?
> 
> FS for now. Let's have String, Number and HiddenString. That should be 
> enough, because the code should do checking at runtime anyway.

Sounds good.

...

>> 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?
> 
> Not necessarely. Since cob:mycompany.com/skin/1.2 and 
> cob:mycompany.com/skin/2.3 have different major version numbers, they 
> are declared to be back incompatible. It could be that 
> cob:mycompany.com/skins/corporate/34.3.345, in order to be implement 
> cob:mycompany.com/skin/2.3 had to overload a few URIs from 
> cob:yetanothercompany.com/skins/fancy/1.2.2 whose behavior would not be 
> compliant to implements -> cob:mycompany.com/skin/1.2.
> 
> For example, say cob:mycompany.com/skin/1.2 includes 
> /stylesheets/news2html.xslt and /stylesheet/doc2html.xslt.
> 
> The first, by default, strips all content that doesn't belong to the 
> news markup language. cob:yetanothercompany.com/skins/fancy/1.2.2 
> implements this behavior.
> 
> Later, a new need is identified (for whatever reason) and the behavior 
> of news2html.xslt is changed so that content in different namespaces is 
> copied over. Clearly, this is a back-incompatible change and this 
> required an increase of the major version number of the URI identifying 
> that behavior (cob:mycompany.com/skin/2.3).
> 
> The developers of cob:mycompany.com/skins/corporate/34.3.345 decide to 
> reuse doc2html.xslt (because they know that behavior is still the same) 
> but need to overload news2html.xslt to provide the new behavior that 
> conforms to cob:mycompany.com/skin/2.3.
> 
> As you see with this simple (yet very likely to happen) example, the 
> "implements" property is not, generally, transitive.

Gotcha.

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

Well, we've said it implements this (really set of) block behavior(s) 
but in the example so far, no block exists with the original "interface" 
definition.  I know there is not a very tight analogy with java 
interface implementation, but should there be some requirement to have a 
definition of what a block is implementing when it says it implements it?

If not, whose responsibility is it to ensure that the implementation is 
complete?  The block developer?  If so, how do they know when they've 
done it?

>> With this and the above questions I'm trying to get at where the hidden
>> contracts are.
> 
> Great. This is useful to me as well, as it stress-tests the design. keep 
> up the nice thinking.

...

>> Ok, I've wiki'd the latest with my proposal about @id and @block 
>> included.
> 
> ok, sounds good to me.
> 
> anybody else?

I suspect that either others are not really paying attention anymore 
because of the length of the thread, or the relative "unsexyness" of 
this first step.

I think a followup email pointing to the wiki results so far and asking 
for comment would be a good step here RSN.  I suppose this doesn't need 
a vote (?) but that would be another way to ensure someone will peek 
their head in.

In the meantime I am happy to play the Meno to your Socrates,

Geoff