cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] applying SoC on cocoon itself
Date Tue, 19 Oct 2004 19:11:43 GMT
Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:
> <snip/>
>> and this solves *ALSO* the issue that was identified at the GT about 
>> "virtual pipeline components" resolving services locally or remotely 
>> (block-wise).
> The current problem with VPCs is the context in which relative URIs must 
> be resolved. We have not found a good solution for this as that depends 
> on the point of view that is considered. What we're missing actually is 
> the notion of "typed parameter" that would allow us to absolutize a URI 
> at the closest point where we can determine that it is a URI and not a 
> raw string.

In the syntax I proposed, the uri="" becomes the identifier for the 
service (thru relative to the block that exposes the service) and the 
src="" becomes the identifier for the instructions for the service (thus 
relative to the block that requires the service).

I think this solves the issue.

>> it would finally introduce a real "pipeline level" polimorphism that 
>> will allow the creation of real blocks.
> Ok, I understand all this and actually this is nothing new compared to 
> what's already been discussed regarding pipeline services, blocks and 
> virtual sitemap components. Just that we forgot a bit with all the 
> classloader shielding and pojo stuff what the actual goal was.

Right, nothing new, but a formalization of why the generator/@src is so 
different from transformer/@src.

> But still, I don't understand the pattern in "name" in <map:transformer 
> name="blah/*" uri="..."/>. Does this mean you create a whole space of 
> transformation services, i.e. blah/a, blah/b, blah/c, etc? IMO, the 
> service names must be a discrete enumeration, i.e.
>  <map:transform name="blah" uri="http://my/blah/pipeline/service/uri"/>

I thought more about it and I agree, there is no need to introduce token 
expansion at the service identification level, so discard that.

> Actually, I don't see much difference between pipeline services and 
> VPCs: pipeline services may simply be the generalization of VPCs looked 
> up in the current sitemap, ancestor sitemaps or remote blocks ("remote" 
> meaning in a different block and not on a remote machine).


Now, since you are the TreeProcessor guru, how do we implement this? :-D


View raw message