Daniel Fagerstrom wrote: > Take a look at > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106649931022515&w=2 > for a description on how the treeprocessor works. The function of the > virtual sitemap components is described here > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111316710610638&w=2. > I don't know if the VPCs work anymore, haven't tested them for quite a > while. > > For the understanding the resource handling (or other parts of the > treeprocessor), it is a good idea to start looking at > http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/treeprocessor/treeprocessor-builtins.xml, > which configure all the execution element of the sitemap. Where you > can see that a resource definition is handled by a > NamedContainerNodeBuilder, and that calling a resource is handled by a > CallNodeBuilder. > > IIRC, there are a few subtle things involved in the resource handling > code, so be prepared to that you might need to spend some time > learning how it works ;)
Views and resources are handled similarily as things that are purely internal to a sitemap. They are therefore looked up and "hard-linked" as part of the processing node tree building phase. Having inheritable resources means: 1 - they should be stored into a location that's visible from child sitemaps. Either the sitemap-specific service manager or Avalon context object should fine (I prefer the latter). 2 - they should not be looked up at build time but at execution time. However, that's probably not enough, as the URL resolution in inherited resources will be relative to the context of the sitemap that called the resource. Solving this, well, is very close to virtual sitemap components and is not trivial. Sylvain -- Sylvain Wallez - http://bluxte.net
