cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: source resolving in 2.2
Date Tue, 27 Jan 2004 22:14:21 GMT
Unico Hommes wrote:

>Carsten Ziegeler wrote:
>>>I am currently trying to get act nodes to work and am have a question about the
source resolving in 2.2. Currently the environment source resolver is put into the object
model in the PipelinesNode. However, now that the environment no longer implements SourceResolver
but appears to be implemented by EnvironmentHelper instead I no longer have access to it there.
So, I was thinking whether we should move that logic into EnvironmentHelper.enterProcessor()
/ leaveProcessor() ? Does that make any sense to you?
>>Ok, I never liked putting such objects into the object model as the om is available
to all sitemap components and users *can* take those objects out of the om and use them.
>>IMHO we should avoid putting any internal objects into the om or into the environment
if possible. But that's only my personal opinion :)

+1 ;-)

Actually, I don't remember why I added it to the OM. It could have been 
better as an environment attribute, but actually this isn't even needed 
(see below).

>>The Processor holds an EnvironmentHelper instance and each node can simply (and should)
pass on this instance to a sitemap component. So, you can do a
>>resolver = this.processor.getEnvironmentHelper();
>>in the ActNode (if this node has access to the processor). 
>>The pipeline implementation e.g. does it this way.
>>If the ActNode doesn't have access to the processor, than there are two choices:
>>a) Use the attributes of the environment or
>>b) Use the new EnvironmentContext mechanism This allows to store arbitrary objects
"at" the environment without directly adding them to the environment. This keeps the env.
clear Perhaps this is FS or overdoing things, I don't know. Anyway, you can get an EnvironmentContext
using a static method on the EnvironmentHelper getEnvironmentContext(Environment) and  add/get
attributes from there.
>>Personally, I would prefer passing the processor to the act node as this is imho the
cleanest but also the fastest solution (no lookup required during runtime).
>OK thanks. It looks like we had the same idea :-). I went ahead and implemented it the
way you describe in option b) . I also added two static helper methods to EnvironmentHelper:
getSourceResolver and getRedirector so we don't have to pass in the processor instance.
>If you find the time perhaps you can proof-read the changes?

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 

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!)

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.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message