You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2003/02/01 22:57:47 UTC
Re: Unblocking Blocks - microstep 1
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...
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
>
> Sylvain Wallez wrote:
<snip/>
>> 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?
CocoonComponentManager (CCM) -- actually ECM, its parent class --
already has a constructor with the ClassLoader that's to be used to load
components. We just have to write a BlockClassLoader that extends
ParanoidClassLoader and give it to CCM.
Cut, paste, glue, and we're done ;-)
>> Does this answer your question ?
>
>
> Thanks :-D
>
> http://wiki.cocoondev.org/Wiki.jsp?page=InterpretedSitemapInternals
Thanks ! I should have done it myself and just replied with this link ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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