cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Cocoon Blocks and internal web services
Date Wed, 03 Apr 2002 15:41:25 GMT
Antti Koivunen wrote:
> Stefano Mazzocchi wrote:
> > Now that Cocoon 2.0.2 is out of the door, I think it's time that we
> > continue the discussion on Cocoon Blocks, which, IMO, represent the
> > major step forward that we should aim for Cocoon 2.1.
> >
> > Thanks to all of those who helped me shaping up the cocoon block idea.
> In case that includes me, you're very welcome :) 

Yes, it does :)

> I actually meant to get
> back to you earlier, but found myself insanely busy. Anyway, here goes...
> <snipped-a-lot-of-good-stuff-that-requires-no-further-comment-at-this-stage/>
> > So, what level of description we need for our block contracts?
> >
> > I see several levels:
> >
> > 1) no description: blocks identify their contract with an URI that
> > that's it, there is no way to validate the fact that a block implements
> > a specified contract, this is the weakest form of contract. It's easier
> > to implement and places the burden of validation at runtime.
> Probably not enough, but must be possible, i.e. the block manager must
> provide a way to turn off validation for certain blocks.

Hmmm, ... but shouldn't we force block compliance automatically? just
like you can't turn off interface checking when you compile your java

> > 2) little description: the contract identifier indicates the 'skeleton'
> > of the contract but doesn't declare more detailed behavior. There is a
> > way to perform structure validation on the blocks and also a way to
> > auto-document the block contract itself, but the behavioral validation
> > cannot be automated and it's left to the user checking at runtime.
> I think we should provide this, at least, e.g. the following would
> actually go a long way:
>    <provides-file name="xslt/document2html.xslt"/>
>    <provides-implementation interface="com.mystuff.MyThing"/>

Yes, this is where I aim to start.

> > 3) detailed description: the contract identifier indicates both the
> > skeleton and the behavior of the contract. This allows high granular
> > automatic validation.
> Sounds good, but would be difficult to implement using just an XML
> descriptor. 

If you are saying that the XML descriptor might get insanely complex, I
totally agree.

> Following proper SoC, perhaps the role itself should provide
> the tools for more complex validation. 

No, this *breaks* SoC! Validation is not your concern is *our* to
understand if what  you provided us with works depending on the contract
that we are expecting!

> The role descriptor could make
> use of the simple built-in validators (see above) and/or define custom
> ones if necessary.
> It should be possible to define an 'intermediate' API to make it easy to
> implement new validators, e.g.
>    interface Validator
>    {
>        void validate( ValidationContext ctx ) throws ValidationException;
>    }
>    interface ValidationContext
>    {
>        BlockInfo getBlockInfo();
>        URL getResource( String name );
>        ClassLoader getContextClassLoader();
>        Configuration getConfiguration();  // from the role descriptor
>    }
> This approach would allow practically any level complexity, but would
> also mean that the role might not consist of just the XML descriptor,
> i.e. we might end up with another archive format, say '.cor'. Still,
> it's probably be better than trying to please everybody and ending up
> with 50kB role descriptors.

Hmmm, no, I was thinking more of using namespaces to trigger different
validation behavior during installation.
> So, the best approach might actually be 1+2+3 :)

no, 3 extends 2 and 1 should not be allowed, IMO.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message