cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject RE: source resolving in 2.2
Date Wed, 28 Jan 2004 09:15:16 GMT

Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> > Two suggestions regarding sourceResolver and redirector:
> > 
> > SourceResolver (the Cocoon one) is a legacy requirement because we 
> > can't change the interface of actions, generators, etc, and 
> is used by 
> > the Processor (for Actions) and the pipelines (for 
> SitemapModelComponents).
> > Now since 2.1, the Excalibur resolver is available to every 
> > Serviceable component.
> > 
> > So why don't we simply write a wrapper that implement the legacy 
> > interface around the looked-up excalibur resolver? That 
> way, there's 
> > no need to store the legacy resolver neither in Environment nor 
> > EnvironmentHelper (and even less in the object model!)
> Yes, we have this wrapper in 2.2. So, if you use the 
> ServiceManager to lookup the SourceResolver you get this wrapper.
> So, we *could* lookup the SourceResolver e.g. in the ActNode 
> and pass it to the action and have a clean solution.
> But :) i tried to make the environment handling (and source 
> resolving) as fast as possible and avoid any unnecessary 
> lookups. if you use the source resolver you get from the 
> service manager, this source resolver has to get the current 
> "processor" for resolving in order to get the current 
> location of the sitemap. So, this is one lookup per resolving 
> a source.
> Therefore I added the EnvironmentHelper object, that 
> implements the SourceResolver interface as well to each 
> sitemap processor. This instance directly resolves to the 
> location of its sitemap. 
> So if you pass this object into the sitemap components like 
> actions etc.
> you avoid this one lookup.

An alternative would be to have the SourceResolver implement a
per-thread lifestyle instead of a singleton lifestyle. That way it can
maintain state in the context of a single request.

> Now, of course this lookup doesn't cost that much, but if we 
> can avoid it, it would be great. I still think, the easiest 
> solution would be if the each Node that needs a resolver, 
> knows the processor or gets this EnvironmentHelper object via 
> IoC on tree creation.
> Then we have both, a clean and a fast solution.

The Processor currently is already available to a ProcessingNode from
the Context so a ProcessingNode implementing Contextualizable will be
able to get to the EnvironmentHelper via that route.

> > 
> > The Redirector is needed only within the Processor, so we 
> can simply 
> > add it as a property of the InvokeContext. Again, no need 
> to clutter 
> > other classes with processor-only concerns.
> > 
> Sounds good!

But the Redirector is currently also used by the FOM so we'd need an
alternative implementation for that.


View raw message