cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Schema of block.xml
Date Sat, 26 Mar 2005 09:21:59 GMT
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>> I think it's time to work on the contracts of blocks a bit more as I 
>> want to start to move the blocks into /cocoon/blocks/[name]/trunk. As 
>> we agreed that state information should be part of meta files, we also 
>> have to agree how this meta file should look like in detail.
> <snip/>
>> It's widely the same as the XML Stefano proposed (long) time ago. I 
>> added a "state" element that desribes the community (committed, 
>> supported, deprecated), interfaces (stable, unstable) and 
>> implementation (stable, unstable) state and has a link to resource 
>> that desribes this in more detail.
>> Comments?
> Looks good. What I don't agree with is the single inheritance (extends 
> and implements). I think that a typical use case will be that you build 
> your webapp as a block. Then it will be quite natural to put it together 
>   by extending a number of blocks that take care of things like skining, 
> user handling, content management etc. You mount the URI spaces for 
> these blocks relative to your own block and overrides (polymorphically) 
> components and sitemap resources in the extended blocks with behaviour 
> in your own.
> We need IMO think a little bit more about what extends and implements 
> means in the context of blocks. 

yes indeed

For example what if block A extends
> block B, will the concrete B block be determined first at deploy time? 
> IMO it makes sense and creates more flexiblity than the extension 
> mechanism in Java or C++. But it is quite different so we should try to 
> understand the consequences.

ok, let's discuss this based on an example :-)

Block A requires block B to work correctly:

<block id="">
   <requires block="" name="B"/>

IIUC this requirement doesn't say explicitly that it requires a specific block 
but a block that implements the interface

Let's assume that block B provides PDF-making functionality:

<block id="htp://">
  <implements interface=""/>

I think Daniel is right here that there is no reason that we need 
single-interface implementation. So let's change this to

<block id="htp://">
    <interface id=""/>

(Note to myself: I have to enhance the deployment desriptor so that it provides 
information which block _implementation_ should be used for a specific 
requirement which is "only" an interface.)

To make it clearer that a requirement is an interface, we should change the 
requirements descriptor a bit:

<block id="">

Note that I added a "default"-attribute to make auto-deployment possible.

I changed the cob schema according to the current state of discussion.

What we haven't discussed yet is what does an *block interface definition* look 
like? Is this an explicit definition that desribes all contracts or a very loose 
marking of a block in its block.xml? Ideas?

                                - o -

More difficult is block extending. We have to consider what extension means for 
several aspects:

  - services:
    * components
    * sitemaps/pipelines
    * flowscripts
  - deployment

As I grew up with Java I have only used single-inheritance yet. We had a long 
discussion what inheritance means for flowscripts (e.g. we have to support 
super() calls) at the beginning of this year.
I think we need the same discussion for components and pipelines too. Stefano 
already gave an example what inheritance could mean for piplines 

Improvement #3: block inheritance

The third step is to allow blocks to extends other blocks.

The idea is to be able to wrap a block with another one, creating an 
'overloading' mechanism similar to the one used by OOP inheritance where methods 
are 'fall back' to the extended class if the extending class doesn't implement them.

Let us supposed we have the following block (very simple):

block "A" implements "skin"


and let us suppose that we want to change the look and feel of that block. The 
first two stylesheets provide simply a way to adapt from more specific markup to 
the Document DTD. So, my block would need to change only the last two resources 
'document2html.xslt' and 'logo.gif'.

The best solution is to allow my block to explicitly "extend" that block and 
inherits the resources that it doesn't contain.

block "B" extends block "A"


but then block B still is considered implementing behavior "skin" because the 
rest is inherited.

This mainly:

     * reduces block development and maintanance costs because changes and 
bugfixes are directly inherited by all the extending blocks, thus allowing 
better SoC between the two groups mainaining the different blocks

     * easy customization: blocks can be adapted for personal specific needs 
simply with a wrapper around and without the need to repackaging.


I'm not sure about multiple-block inheritance. For me it's some kind of an 
anti-pattern but maybe I'm too Java-minded.

I don't think that deployment will be the difficult part here. If block A 
extends block B, the deployment process has to ensure that block B is installed 
correctly. It's just another dependency that has to be resolved.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message