cocoon-dev mailing list archives

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


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

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

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"/>

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).



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message