cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [FYI] How TreeProcessor Works
Date Fri, 24 Oct 2003 16:17:44 GMT
Sylvain Wallez wrote:

> 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

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

> 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.


     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

View raw message