cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sun, 21 Sep 2003 13:19:59 GMT

On Saturday, Sep 20, 2003, at 23:30 Europe/Rome, Geoff Howard wrote:

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

Hmmm, you made me realize that it's not clear how block can provide 
virtual pipeline components if a sitemap is not declared.

what do you people think about this?

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

yes, but never *directly*. see below.

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

as reading pipelines

>>> In the example
>>> what does the first block (@id="") 
>>> use
>>> from 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?

no, that would create a contract on the file system layout of the 
block, which might be undesirable (just like the protected/public 
method you imply below)

> Is it only available if a pipeline matches it (eg <map:match 
> pattern="stylesheets/news2html.xslt"><map:read 
> src="stylesheets.news2html.xslt... ).

yep. look that it's entirely possible to do a

  <map:match pattern="*">
   <map:read src="{1}"/>

and forget about it... but later, extending blocks don't necessarely 
have to follow the same file system approach (they might be already 
using that directories for something else!) but just have to overload 
the sitemap.

this gives more flexibility, file system decoupling and explicitness, 
as in the spirit of the sitemap.

> Can it be assumed that any physical file resource in the block can be 
> considered "provided"?

no and should not.

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

that would be a duplication of what the sitemap can do by itself.

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

one <extends> and many <implements>, as we follow Java in disallowing 
multiple inheritance (which would be painful to maintain).

>>>  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"?
>>> 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:
>>>     implements ->
>>>     implements ->
>>>     extends ->
>>> Does also implicitly
>>> implement because it extends
>> Not necessarely. Since and 
>> have different major version numbers, they 
>> are declared to be back incompatible. It could be that 
>>, in order to be implement 
>> had to overload a few URIs from 
>> whose behavior would not 
>> be compliant to implements ->
>> For example, say includes 
>> /stylesheets/news2html.xslt and /stylesheet/doc2html.xslt.
>> The first, by default, strips all content that doesn't belong to the 
>> news markup language. 
>> 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 (
>> The developers of 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
>> 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
>>> 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?

no. the java analysis falls short because, for block behaviors, we do 
not have a way to "describe" this behavior. Eventually, it could be 
possible to look it up thru the URI (directly, if we move to http: URI 
or indirectly if we keep cob: URI as we need a lookup machanism), but 
this is not necessary at this point, it would be only to validate 
whether or not the block actually *does* implement that behavior, but 
checking this is simply too hard so we decided to go down the weak 
typing approach.

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

Eh, you are touching a nerve here and, by far, the most critical thing 
of the whole design.

To draw a parallel, it's weak typing vs. strong typing. Over the years, 
I came to appreciate both approaches: weak typing for rapid scripting 
and strong typing for solid foundations.

Where do blocks reside? well, one could say that block reside in the 
'solid foundations' realm (if looking from the block developer 
perspective) or in the rapid scripting (if looking from the block user 
perspective). Who is right? I don't know.

The only thing I know for sure is that writing a "block behavior 
descriptor" is such a complex task that it would be foolish to attempt 
to do so.

Consider the example before: a stylesheet that changes behavior in 
copying-over or dropping content in another namespace? how do you 
signal that? how do you test it? an image that is more than 123 pixels 
wide but less than 134 pixels otherwise the page layout is ruined? how 
many things would there be to checkout?

As for strong typing advocates: java is not that strongly typed as it 
seems at first. If you use collections without generics, well, you are 
on your own. CCE and NPE are avoided only with *your* care during 

In short, I think block behavior validation will simply work on its 
own, by comparing to a reference implementation of that behavior. That 
behavior URI might point to a document that explains what services are 
provided and what not, but this is not to be machine digestable, but 
simply a for-humans descriptions of what the blocks do.

True, it's entirely possible to incrementally create an ontology of 
block operations and use DAML+OIL software to perform validation and 
truth analysis, but given the amount of people that volunteer their 
brain to do that truth analysis on their own, why should we substitute 
"real intelligence" with "artificial" one?

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


I agree on the general unsexyness of these things, but only because we 
don't have anything working.

As soon as things start to work, I expect tons of comments, mostly of 
things that were already said before ;-) but, hey, that's life.


View raw message