You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/04/03 17:41:25 UTC
Re: [RT] Cocoon Blocks and internal web services
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks and internal web services
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> At 2:26 pm +0200 4/4/02, Stefano Mazzocchi wrote:
> >> 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 :)
> ^^^^^^^^^^^^^^^^^^^^
>
> Hi Stefano,
>
> I believe you meant to say "sensitive to cheating"?
>
> Otherwise you said:
>
> "As an Italian I always cheat in a very calm, intelligent and appropriate way"
>
> ;)
Right.
Well, to be honest, even the other meaning can be appropriate at times
:)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks and internal web services
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks and internal web services
Posted by Antti Koivunen <an...@users.sourceforge.net>.
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.
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).
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.
>>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.
(: A ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org