[WIKI-UPDATE] BlocksDefinition Fri Mar 28 13:00:04 2003

[st...@outerthought.org]

Page: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition , version: 13 on Fri Mar 28 11:09:22 2003 by NicolaKen

+ !How to do a first microstep towards the goal.
+ Taken froma mail from SylvainWallez on cocoon-dev.
+ 
+ {{{
+ > 
+ > 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.
+ > 
+ }}}
+