cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: block perspectives
Date Thu, 02 Oct 2003 14:16:16 GMT

On Thursday, Oct 2, 2003, at 15:04 Europe/Rome, Stephen McConnell wrote:

>>  1) lack of polymorphic dependencies
> Dependencies are adaptive to the implementation strategy.
> A block author does not need to declare any dependencies as these are  
> implicity established based on service dependencies declared by  
> components that make up the block implementation.
> When a block is deployed - the container wires the block up service  
> published by other components and/or blocks.
> That process will result in the resolution of set of dependencies that  
> are a function of the component dependencies that constitute the block  
> implementation.  This approach means that there is no requirement for  
> dependency declaration at the level of a block.

You are assuming that blocks just include components and are not  
functional components "per se". This is insufficient for our needs  
(more below).

>>  2) lack of block metadata for human consumption.
> Correct.  The block matadata focusses on the definition of an  
> implementation strategy. This is balanced by meta-info at the  
> component type level that supports association of human readable data  
> across all aspects of the component defintion.  As mention before -  
> the block implementation presents as a dynamic component - and as  
> such, human readable information would be exposed as meta info.

Again, you make the assumption that a block is just a container of  

For us, a cocoon block is a first-class functional unit, in short, a  
"component" for cocoon webapps. What you are doing at the component  
level, we need to do it at the block level.

This is why we need explicit dependencies (althought dependencies can  
be on block behaviors, thus behave polymorphically), explicit metadata  
and so on.

You assumption that this is not needed becase "it should happen at  
another level" just doesn't work for us since while for you every  
service is an avalon component, for us that's clearly not the case.

>>  3) lack of extension capabilities.
> We disagree here.  The entire meta-data model has been created with  
> extension and interoperation in mind.  In fact if you take a look at  
> the composition package apis, you will find comprehense set of model  
> interfaces and an implementation approach which assumes that  
> meta-models form different environments are working together as part  
> of composite solutions.
> model/package-summary.html

Extension == "inheritance" as in "one block extending another block".

You have no notion of one block inheriting another block. And this is,  
again, due to the assumption that blocks provide no functionality per  
se, thus the concept of "inheritance' has no meaning.

For us, the concept of block inheritance is very useful.

>>  4) lack of block-level parameter definitions
> Given the scope of parameterization covered in the following data  
> types:
> data/package-summary.html
> What aspects of parameterization do you think are lacking?

Again, a block has its own functional capabilities. so it requires its  
own properties to be configured at deploy time. We explicitly indicate  
these properties so that at deployment time they can be asked by the  
deployment manager to the user doing the deployment.

You have no such notion.

>>  5) definition of the component/service hint at the provider level
>> [I believe this is bad, the provider should specify the component ID,  
>> the compontent requirer should specify how it is hinted in its local  
>> domain of use]
> There is no notion of "hint" by providers.

from your example in

<component name="application"
         class="tutorial.application.Application" activation="startup">

"name" is a hint. Potentially, two blocks in the same address space  
might provide the same hints. This creates conflicts. Hints/names, IMO,  
should not be given by the provider, but by the user.

In our design, the provider states

  <component class="mypackage.MyComponent"/>

and the consumer states

  <uses component="mypackage.MyComponent" name="mycomponent"/>

so, different consumers might use different hints for the same  
component, or the same hints for different components but no collission  
will happen.


View raw message