cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Unblocking Blocks - microstep 1
Date Sat, 01 Feb 2003 21:57:47 GMT
Nicola Ken Barozzi wrote:


>>> 2. Where does the treeprocessor actually create these components? ;-P
>>>  It seems that methods are calling methods that are... you get the
>>>  picture... I've got not much time to dwelve into that code, but
>>>  I looked at the, but still I'm puzzled.
>>>  Can someone please help me and explain how Cocoon uses-handles
>>>  the ComponentManager(s), and how the TreeProcessor works?
>> On that, I can't help you mate, but once you figure something out, I can
>> help you writing some code for it! :-)
> Sylvain? (the Source ;-)
Sorry for the delay, I was away for 2 days...

The TreeProcessor works by creating an evaluation tree of 
ProcessingNodes corresponding to sitemap statements. It asks a 
TreeBuilder to create this tree and then handles requests with it.

The TreeBuilder reads the sitemap file (in an Avalon Configuration 
object) and builds this tree by invoking a ProcessingNodeBuilder for 
each element encountered in the sitemap. The ProcessingNodeBuilder in 
turn creates an appropriate ProcessingNode that will be used at runtime 
to "execute" the sitemap

The ProcessingNode isn't created directly from the sitemap element, 
since some sitemap elements don't always lead to identical processing 
depending either on their attributes (e.g. <map:call resource=""> and 
<map:call function="">) or the used components (e.g. <map:match> which 
is different for regular Matcher and PreparedMatcher).

The DefaultTreeBuilder has a createComponentManager() method that 
creates - guess what? - the CM that is to be used within the processing 
tree to lookup components. In that default implementation, this is just 
the "current" one (i.e. the one passed to "compose()").

But if you look at SitemapLanguage, which is a subclass of 
DefaultTreeBuilder, you will notice that its createComponentManager() 
method creates a new CocoonComponentManager and configures it with 
<map:components>. So <map:components> defines components of the sitemap 
just a cocoon.xconf defines them for the Cocoon object.

Adding a custom classloader to the sitemap to handle blocks should thus 
be just a matter of giving that custom classloader to the created CM.

Does this answer your question ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

To unsubscribe, e-mail:
For additional commands, email:

View raw message