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.
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).
WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
