Re: Migrating TreeProcessor to Fortress

[Joerg Heinicke]

I guess I simply mix all and everything: the sitemap, your pseudo xconf, 
XML in general and the "object model". I do not understand much of it 
and maybe I should shut up because of this :-)

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