cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antti Koivunen <anryo...@users.sourceforge.net>
Subject Re: [RT] Cocoon Blocks and internal web services
Date Sun, 31 Mar 2002 15:02:13 GMT
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 :) 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.

> 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"/>

> 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. Following proper SoC, perhaps the role itself should provide 
the tools for more complex validation. 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.

So, the best approach might actually be 1+2+3 :)

(: A ;)

-- 
Antti Koivunen (Mr.) <anryoshi@users.sf.net>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message