Berin Loritsch wrote: > Stefano Mazzocchi wrote: > >> On Friday, Oct 17, 2003, at 20:36 Europe/Rome, Berin Loritsch wrote: >>> Anyone have a logical view of how the Treebuilder is supposed to work? It would >>> definitely help me in refactoring things. As it is now, the >>> Treebuilder is >>> tightly integrated with the ECM, so it is something that won't work right >>> away... I am just trying to get to a place where I can compile 2.2 so that my >>> testcases will run and I can verify what I am doing works. >> Sylvain knows this and, AFAIK, he's one of the few (only?) that does. Which is also something that I'm particularely comfortable with, even if this is not clearly Sylvain's fault if what he writes works as expected and nobody has to go there and fix it ;-) >> But a description of the internals of the tree processor would be helpful not only for migration for also for future reference >> (refactor? cleanup? profile? whatever) > > > I am slowly getting up to speed, and I will eventually get there. The important thing is to grok the big picture, which will help me with the details. >
Main steps ---------- The TreeProcessor is set to get the Processor role in the cocoon.roles file. During the configuration of the TreeProcessor an ExtendedComponentSelector (builderSelector) is set up using the configuration file "treeprocessor-builtins.xml". While calling TreeProcessor.process(environment), i.e. the method that takes the environment, applies the sitemap on it and produces the output, the following things happen: * The method setupRootNode is called (if necesary) and the builderSelector is used to get a TreeBuilder (builder). The build method on the builder is called with the sitemap as argument and a tree of ProcessingNodes corresponding to the sitemap is returned. * The sitemap is then executed by calling the invoke method for the root node. Building the tree ----------------- In Cocoon using "treeprocessor-builtins.xml" SitemapLanguage that extends DefaultTreeBuilder is used as TreeBuilder. Within the DefaultTreeBuilder (during execution of the build method) a RoleManager is set up based on the "roles" section of "treeprocessor-builtins.xml" and a ExtendedComponentSelector is set up based on the "nodes" section. The "nodes" section associates the sitemap concepts to the appropriate ProcessingNodeBuilders. It also configures a ProcessingNodeBuilder so that it knows what type of children it is allowed to have and which ones that are forbidden. The build process starts (in the method createTree) by creating the ProcessingNodeBuilder (rootBuilder) that corresponds to the root element in the sitemap, associate the rootBuilder to the current TreeBuilder and call the rootBuilder.buildNode method with the configuration tree created from the sitemap. The FooNodeBuilder.buildNode method creates and returns a FooNode object and recursevly creates the child nodes of the object by creating and executing the corresponding builder objects. Executing the tree ------------------ While (recursevly) executing the invoke(environment, context) method for the node objects in the tree a Pipeline object is constructed that is stored in the context object (other things happens as well). When a SerializeNode is invoked, the current Pipeline is proccesed and the output is stored in the environment. ---------------------------------- <sidenote> I builded a Cocoon inspired signal processing framework about a year ago and tried to reuse Sylvain's framework. While most of it is very general, there are some Cocoon specific details in the Context and Environment interfaces, so I ended up in building something similar but simpler instead. </sidenote> HTH /Daniel
