Carsten Ziegeler wrote:
I'll try to summarize what we've got so far (as far as I interpret this thread :) ):
A VPC (virtual pipeline component) is like a macro (I didn't find a better term); it can contain matchers, selectors and actions. A Virtual Generator must have a generator (and perhaps some transformers in it), but no serializer A Virtual Transformer should have one or more transformers (but no generator or serializer) and a Virtual Serializer can have one or more transformers and has to end with a serializer.
I like Stefano's apprach for labels:
here is my suggestion: a vpc is just syntax sugar, it should not change the semantics. this means that internal labels should be treated as just if they were external.
the only issue is with collisions and here I think overloading should apply: if the label is on the vpc and the vpc itself includes a component that has the same label, the output of the whole vpc will be sent to the view.
For parameter handling, I can quote Sylvain:
Passing parameters to a VSC is very similar to passing parameters to resources. There's however a special handling of the @src attributeresources.
that exists on generators and transformers, which does not exist on
</map:virtual-generator>Example:
Definition (syntax and exact location still has to be defined):
<map:virtual-generator type="foo">
<map:generate src="{src}"/>
<map:act type="lang-select">
<map:transform type="i18n"/>
</map:act>
<map:transform type="xslt" src="stylesheets/{bar}.xsl/>
Usage:
<map:generate type="foo" src="blah">
<map:parameter name="bar" value="baz"/> </map:generate>
I have the same understanding after reading the whole thread. Though I'm not sure if we have consensus on actions. Anyway, what will be the order of execution of actions? IIUC all actions within a pipeline are execute *before* the pipeline is executed, aren't they? Will this behaviour remain?
Another question: Is this order of execution of actions by design and if yes, what's the reason?
Apart from the syntax (which we could define last), I see only two open
points:
a) are VPCs inherited to sub sitemaps
I guess, we all say: "Sure"
yes sure ;-)
b) (my favorite topic) Source Resolving
As long as the VPC is defined in the same sitemap as it is used, we don't
have a
problem, but if we answer question a) with yes, then we have a problem.
Look at the sample from Sylvain above, now imagine the Usage is in a
subsitemap.
So the src ("blah") should refer to a source that is relative to the sitemap
of the Usage. The VPC from above resolves two sources (the src and the stylesheet).
The stylesheet should imho be resolved relative to the sitemap where
the VPC is defined.
Now, a first approach would be: all resources of VPC are resolved relative to the sitemap where the VPC is defined. And if a src information is passed (for virtural generators or transformers) this src information is resolved relative to the usage sitemap and then passed as an absolut path to the VPC.
This works nicely as long as only the "src" attribute defines a resource
but not a paramaeter.
As a user I would expect it this way.
After finishing this discussion we should start a vote, shouldn't we?
-- Reinhard
