cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: Java components in blocks
Date Sun, 17 Apr 2005 13:16:59 GMT
On 16 Apr 2005, at 13:56, Daniel Fagerstrom wrote:
> 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
>> So block B does not provide the component with
>> hint "stx" but a service that could be anything
>> doing the job satisfying the dependency. Ok.
>> Now what about the component dependencies? Let's
>> say in order to implement the "transform-via-stx"
>> service block B requires a component of hint "stx".
>> Since the block B has its own component manager
>> and the component "stx" being declared in the block's
>> sitemap all is left is a java class level dependency
>> to the stx implementation. Now the question is - will
>> the block B provide the stx jar? Let's say yes for the
>> moment.
>> So what if the "transform-via-stx" component needs
>> another component? We could list all the required
>> component in the components section for that very block.
>> ...but still the classes need to be available!
>> What if the classes are in a different block?
>> Essentially this means to me: As long as we don't want
>> to ship every block with every component it requires
>> I cannot see how we can get around of having blocks
>> also expose component services.
>
> The idea is that if you have a component that you want to be able to 
> use in several places, you package it in a certain way. Then the 
> improved component handling system that Pier feel the itch to build 
> can found its jar in some repository somwhere, reolve its dependencies 
> and offer a shielded parent classloader with the depndencies you have 
> asked for.
>
> I don't know the exact details about Pier's vison about this, but you 
> can take a look at the kernel in whiteboard for part of it and Maven 
> is also a part of the equation for downöloading and dependency 
> reolution.

My vision is quite simple... How many _COMPONENT_ interfaces we need 
for Cocoon? Probably 3:

"Generator"
"Transformer"
"Serializer"

(well, you might have another 2 or 3 of them but do you see the point?)

How many _BLOCK_ interfaces can we have on the other hand?

"ForrestSkin", "WebMailRepository", ....

hundreds.

Then, if each implementation of a block interface is allowed to say "To 
provide this transformer pipeline service I need the SQL transformer 
component, the XSLT component and STX component" (all those three 
simply implement the component "Transformer" Java interface, the 
problem of dependancy resolution is so easy from both sides:

On the block side, you can completely ignore classloaders and java 
code, on the component side, you're pretty much sure that the number of 
component interfaces is not going to be so big and so "volatile" in 
terms of version numbers (and therefore simplifies the classloading 
structure).

I mean, the problem right now is not that we have two versions of the 
"o.a.c.s.Serializer" (Java) interface, but that we _need_ to have in 
the same Cocoon two versions of "Fop" implementing the 
_same_precisely_exact_ Java interface...

See what I mean?

	Pier


Mime
View raw message