cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Cocoon Blocks and internal web services
Date Thu, 04 Apr 2002 12:26:17 GMT
Antti Koivunen wrote:
> 
> Stefano Mazzocchi wrote:
> > Antti Koivunen wrote:
> >
> >>Stefano Mazzocchi wrote:
> >>>
> >>>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?
> 
> Well, this is a bit different. It might be quite convenient during
> development, e.g. the deployment is faster and it's possible to
> add/remove features without having to update the descriptor every time.

Good point.

> Also, if the URI is used to locate the descriptor, there's always the
> possibility that you're offline or behind a firewall (although the block
> manager should provide a way around this by giving the option of storing
> the descriptor locally).

Yes, of course.

> Of course, I agree that strong compliance checking is a good idea. My
> point here was convenience in certain situations. Possible modes of
> operation could include:
> 
>    1. Validate everything. Only the resources explicitly defined in the
>       descriptor are available.
> 
>    2. Check dependencies but allow the block to be queried for resources
>       not explicitly defined in the descriptor.
> 
>    3. Only check the URI. All other validation occurs at runtime.
> 
> >>>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.
> 
> Very good.
> 
> >>>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.
> 
> Exactly my point, but as said before, a few simple validation rules
> would go a long way (but probably not all the way).
> 
> >>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!
> 
> Well, SoC isn't just about who writes the Java code. Offering a clean
> Java API to the block (role) authors for defining the validation rules
> might be better than offering an "insanely complex" XML API. Our main
> concern is to perform the validation in a uniform way according to these
> rules.

Yes, but it's a matter of *trust* more than SoC at this point: I give
you the contract, you give me the implementation *and* a way to check
the validation.

As italian, I'm always very sensible at cheating :)

> >>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.
> 
> I'm also quite hesitant to go beyond XML, but it might be difficult to
> define standalone roles. Consider the following fairly simple example:
> 
>    <validate-xml file="foo.xml" schema="http://mystuff.com/xfoo"/>
> 
> Now, if the schema URI does not resolve to a valid schema (or there's no
> internet access or the server is down), we have a problem. There are a
> couple of possible solutions (pre-install the schema, require momentary
> internet access), but wouldn't it be more convenient to download a
> single file that contains everything? Then we could do something like:
> 
>    <validate-xml file="block:foo.xml" schema="role:schema/xfoo.xsd"/>
> 
> This is just one example, but I'm pretty sure there other similar
> situations.

Ok, I'll try to come up with something as soon as I have time.

Ciao

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


Mime
View raw message