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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
