Daniel Fagerstrom wrote:
I have continued Vadim's and Sylvain's work and added a first, hopefully working version of virtual sitemap components (VPCs) to the trunk.
Awesome!!!
You (and Vadim) rock!
I'm a happy camper.
Thanks :)
Use ===
To use VPCs one define them in the components section in the sitemap, e.g.:
<map:components>
<map:readers>
<map:reader name="virtual1" src="org.apache.cocoon.reading.VirtualPipelineReader">
<map:generate type="file" src="vpc-test.xml"/>
<map:serialize type="xml"/>
</map:reader>
</map:readers>
virtual readers? hmmmm, never thought of that one. What does that buy you? I mean, it's not harmful to have it, but do you see any real use of that?
They have the same use as resources, but are exportable to subsitemaps or from blocks. Can't say that the name reader is that illuminating for more complicated behaviours, but they have the same semantics as readers. We could export resources instead but they are not considered as components so that would require a separate mechanism.
<map:transformers default="xslt">
<map:transformer name="virtual2" src="org.apache.cocoon.transformation.VirtualPipelineTransformer">
<map:source param="src2"/>
<map:transform src="vpc-include.xsl">
<map:parameter name="file" value="{src}"/>
</map:transform>
<map:transform src="vpc-include.xsl">
<map:parameter name="file" value="{src2}"/>
</map:transform>
</map:transformer>
</map:transformers>
</map:components>
then they can be used as any component:
<map:read type="virtual1"/>
<map:transform type="virtual2" src="vpc-test.xml"> <map:parameter name="src2" value="vpc-test2.xml"/> </map:transform>
in the sitemap where they are defined and in all its subsitemaps.
and in the future, they will be accessible from the blocks that are wired to them.
Yes!!!
One of the complicated things with VPCs was how and where to resolve sources that are given to VPCs. I followed Sylvain's aproach in http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110064557022481&w=2 modified with my ideas (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110539791029866&w=2) about how to increase the level of isolation between the caller and the callee. This will be needed when we use them from "real" blocks.
To use a source as a parameter one have to declare it with
<map:source param="src2"/>
in the definition. The "src" is always supposed to be a source. Sources are alwas resolved in the calling sitemap.
Ok, makes sense.
--- o0o ---
More examples of use can be found in the sitemaps for the test cases in src/test/org/apache/cocoon/[generation|transformation|serialization|reading].
I didn't research old mails about VPCs about what things are supposed to be called. So suggestions about better names and syntax are welcome.
I think that having a src="" attribute in a VPC is YAGNI: do you really see yourself using different implementations of the internal wiring of a virtual component? If so, it's probably a configuration parameter for the tree processor than something you want to use there.
So, my proposal is to keep the above semantics, but differentiate between 'real' and 'virtual' pipeline components, with the existance of the src="" attribute. If missing, the tree processor will consider it a virtual one and construct it from there.
The tree processor recognize that it is a VPC on the src parameter, I just kept that from Vadim's prototype. Recognizing it from the lack of src attribute is fine for me.
/Daniel
