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...
Mess...
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...
Pier
