Stefano Mazzocchi wrote:
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).
We already have this src="" attribute which currently is a raw string. Does this mean that we will enforce the contract on this by explicitely stating that it's a URI that will be resolved in the local context where the instruction is written?
We have to check if all of our current components use src as an URI.
I think this solves the issue.
Mmhh... what if other parameters are also URIs?
<snip/>
Right, nothing new, but a formalization of why the generator/@src is so different from transformer/@src.
I have to read again your previous post as I don't see that difference. Moreover, we added some time ago the abilitity for a Serializer to also be a SitemapModelComponent, thus allowing it to have src="" and parameters. This is needed e.g. by the FOP serializer to read the configuration file.
In all cases (G, T, S), the src="" looks to me like the identifier of "something" that drives the function of the component. Some need it (FileGenerator, TraxTransformer), others don't (RequestGenerator, I18nTransformer).
<snip/>
Now, since you are the TreeProcessor guru, how do we implement this? :-D
I had a discussion with Carsten at the GT about the relations of VPCs with the pipeline object and caching. The whole question is about we consider that VPCs and pipeline services must be an implementation of the corresponding Java interface (Generator, etc) or if it can be a "mini-Processor" that simply wraps a sitemap evaluation tree snippet.
If we want them to implement the Java interfaces, that requires to define "mini-pipelines" that chain the VPC's components and provide a combined cache key and validity to the enclosing pipeline object. That leads to loosing some of the features of the cache that caches up to the latest cacheable component in a chain (a VPC is considered as as a single component in this regard).
If we say that a VPC is a mini-processor, implementation is rather easy as it just means adding to the Processor interface some lookup method to get a Processor object that will be a wrapper around the VPC's instructions. Pipeline components added by the VPC are added as usual to a single pipeline chain, as we have today.
The problem of that second approach though, is that it's not possible for Java code to lookup e.g. a Serializer that would be defined by a VPC. Some components in Cocoon use that, e.g. the SourceWritingTransformer and the ZipArchiveSerializer.
I prefer the mini-pipeline approach which is simpler and more efficient than wrapping behind the interface, but we loose some of the current functionnality.
Or maybe a good solution can be to combine both approaches: the sitemap engine will use the mini-processor approach, and component lookups (which are not that often used) lead to the creation of a simple wrapper object implementing the Java interface, but that doesn't care about caching as SWT and ZipArchiveSerializer don't care about it.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
