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).
Correct.
Now, since you are the TreeProcessor guru, how do we implement this? :-D
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
