Read on, you seemed to hit my concern:
On 11.11.2003 12:33, Unico Hommes wrote:
Do you mean:
parent.xmap: <sitemap> <components> <generators default="file"> <generator name="file" src="..." /> </generators> </components> </sitemap>
child.xmap: <sitemap> <pipelines> <pipeline> <match pattern=".."> <generate type="file" src=".." /> <serialize /> </match> </pipeline> <pipelines> </sitemap>
?
Yes, exactly.
No this is not a problem because the ServiceManager of the parent processor acts as the parent to the ServiceManager of the child processor. The match node will ask the child ServiceManager for the file generator, and if the child ServiceManager doesn't find it among its own components it asks the parent ServiceManager for it. This is also how it is handled today.
The tree-like lookup is clear.
The sitemap components will actually be handled a little different from the pipeline nodes. The above parent.xmap translated into a fortress configuration will look like:
parent.xconf: <fortress> <generator id="file-generator" src="..." /> </fortress>
And the child.xmap looks like:
child.xconf: <fortress> ... <match id="p1-m1"> <generate id-ref="p1-m1-g" /> </match>
<!-- this is the generate node.
It looks up its Generator
on the service manager using key "org.apache.cocoon.generation.Generator/file-generator"
--> <generate id="p1-m1-g" type="file-generator" />
and here I thought of idref="file-generator", which does not exist from an XML POV.
</fortress>
In which form will the fortress configuration exist? Do you want to start a transformation or is the above only an XML representation for a completely hidden and automatically handled "feature"?
Joerg