cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Unblocking Blocks - microstep 1
Date Sat, 01 Feb 2003 23:00:36 GMT


Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
> 
> <snip/>
> 
>>>> 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 DefaultTreeBuilder.java, 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...

Ahh, bad boy, bad boy ;-P

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

Yup, got to that.

> 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

Ok.

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

Ahhh, now it's getting interesting...

> 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()").

Ok.

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

Yeah, this is it! So I need to change the CocoonComponentManager to be 
able to handle the creation of stuff from the loaded blocks.

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

Ok. Since we will have a map:blocks section, what do you propose to do 
in code? IE where to load the blocks? Probably simply pass also that 
info to the CocoonComponentManager?

> Does this answer your question ?

Thanks :-D

http://wiki.cocoondev.org/Wiki.jsp?page=InterpretedSitemapInternals

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message