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.) <[EMAIL PROTECTED]>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
