cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Java components in blocks
Date Sun, 17 Apr 2005 13:03:13 GMT
On 16 Apr 2005, at 12:43, Torsten Curdt wrote:

>> Reading these discussions after the fact, having Blocks provide only
>> sitemap components seems to make a lot of sense
> ...not to me - sorry. But maybe I just missed something.
> Pier is totally right: we have two different concerns.
> One is the pipeline services interface and one is the
> component interface of a block.
> But reducing a block just to it's pipeline services basically
> gives us virtual sitemap components on steroids. What about
> its dependencies? Well, IIUC one argument in this discussion
> was that the dependency will be satisfied through a pipeline
> service - not through a component.
> Block A:
>  provides: a pipeline service to transform xml
>  requires: a pipeline service to transform xml with a STX stylesheet
> Block B:
>  provides: a pipeline service to transform xml with a STX stylesheet

Hmm... As far as I can see, intra-block dependancy is "available" only 
through interface blocks, right?

So, the "Forrest" block, requires the "ForrestSkin" interface, and this 
is injected into it by creating a new "instance" of the "CocoonSkin" (a 
block which implements ForrestSkin).

So, now we end up with a problem: if to provide the pipeline service to 
transform XML, my "CocoonSkin" uses an XSLT, this block will depend on 
the "XSLTTransformer", if it uses STX it will depend on the 
"STXTransformer", if it uses XSLT2.0 and XQUERY I might want to use 
"SaxonTransformer" version 8.0 or greater...

You see that if a block needs to specify its COMPONENT requirements 
(not BLOCK requirements) only through interface, we'll end up having 
one interface block probably per each implementation block...


If we separate blocks and components, at this point, we can carve into 
stone that block requirements _must_ go through interfaces, components, 
actually are a completely different beast. A block exposing a PDF 
serializer for "BOOK.DTD" documents might require specifically a 
version of FOP, because its stylesheet works around some bugs into that 
particular implementation...


View raw message