cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: CocoonComponentManager
Date Fri, 16 Apr 2004 10:36:53 GMT
Leo Sutic wrote:
> I've recently started thinking about embedding Cocoon in 
> another application.
> One of the issues that I have is the CocoonComponentManager - 
> since I use another component manager in the application, I'd 
> like to just host the TreeProcessor in that manager.
> The issue I have is that CocoonComponentManager exposes a 
> number of static methods that makes it imposible to replace. I.e.
> you have components (TreeProcessor) that really do care about 
> what container they are in.
> I can't subclass the CocoonComponentManager, since 
> TreeProcessor refers to the class by name.
> But what I could do is this (and this is what I propose to do):
>     Move the static methods out from CocoonComponentManager and
>     put them in the Context.
> The CocoonComponentManager could then expose those methods 
> via a custom InternalCocoonContext interface that extends the 
> Context interface.
This would give everyone access to the info (ok, the current static
methods are accessible as well) and imho makes it more visible.
For 2.2 I rewrote the whole handling and moved all methods out
of the manager into a separate class (the methods are still static)
and we don't need an own component manager anymore.

Just curious, why do want to do this? Do you just want to use the
TreeProcessor as a processor for a custom XML? Or are you
using the TreeProcessor to process a sitemap in a different
Now, I think, if the TreeProcessor is used for custom XML, then
you could use the TreeBuilder I think (I'm not that sure).
If you want to process a sitemap, you need the dependency to
the cocoon stuff anyway.


View raw message