Return-Path: 
 <cocoon-dev-return-25159-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 60299 invoked by uid 500); 3 Apr 2002 15:39:41 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 60288 invoked from network); 3 Apr 2002 15:39:41 -0000
X-Antivirus-Data: Virus data file v4189 created Mar 06 2002
Message-ID: <3CAB22A5.E4CFE8C5@apache.org>
Date: Wed, 03 Apr 2002 17:41:25 +0200
From: Stefano Mazzocchi <stefano@apache.org>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Cocoon Blocks and internal web services
References: <3CA33854.639EC67D@apache.org> <3CA724F5.3060607@users.sf.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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
code?

> > 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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

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