Berin Loritsch wrote:
TreeProcessor is a complicated beast, so examining the classes does not lend any clues to what is going on. However, the key to understanding TreeProcessor is the treeprocessor-builtins.xml file.
?? Haven't you seen my explanation to your previous request?
See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106649931022515&w=2
Ok. Now I have read it. I will respond to specific points in a moment.
As to implementation, the TreeBuilder creates a heirarchy of ECM implementations that add any necessary components and Builder components. The particularly troublesome portion of this is the use of the Recomposeable interface.
The whole issue with the Recomposable interface as it is written here is that the child and parent component managers are constantly overwriting each other. THis is a serious conflict, and it will break as soon as we proxy components. The proxied components hide any lifecycle interfaces so that no rogue client can usurp the component manager, or any other part of the lifecycle of a component, and provide for a more stable system.
The Recomposable interface is used here so that node builders know the component manager of the tree that is being built, because this is where the builders should lookup components when they need some.
Is this the *whole* tree, or a portion of the tree?
If it is the *whole* tree, then we can come up with another workable solution.
I admit this is not clean, as it mixes the container which manages the node builders (built with the treeprocessor-builtins.xml file) and the container in which the tree that is being built has to live.
A solution can be to add a getTreeManager() method to the TreeBuilder interface, that would return the manager for the tree being built (i.e. the one defined by <map:components>).
How does it sound?
If the Sitemap is set up as its own container, with all the associated components, etc. then we can call the tree processor with the "Processing ServiceManager" supplied by the container.
Of course, the whole thing of the Sitemap==Container for a nice heirarchy going on here is that we do have to manage the interaction for the TreeProcessor and the container. For example, how do we add component definitions?
In the end, it can be done, without any repurposing of components at runtime/ build time.
Hmmm...
Container
{
void addComponent(ComponentHandlerMetaData);
ServiceManager getServiceManager()
}This would be enough to provide a TreeBuilder interaction for the Sitemap container building (at least from my understanding).
THe recomposable calls scare me because they look like something that would work under low load, but would break down under high load. With something like Cocoon that is a big issue. I don't have any numbers to show everyone, but it is just a feeling I get by looking at the code.
You should not wonder, since this is used only to _build_ the sitemap, i.e. at startup or when the sitemap file is changed.
I still don't like them... They *shouldn't* be necessary.
I know I want to have a new Container per sitemap, but I think I need some help in mapping it to this problem space. Ovideu, do you think you could at least spare some guidance?
Ahem... I guess Ovidiu won't isn't the right person for this stuff, but I hope my explanation will help ;-)
My apologies. I knew there was one guy who did all the work for this, saw Ovidiu's name, and thought it was him.... I know he is responsible for the Flow system....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin