Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4016E2BD.5040000@apache.org>
Date: Tue, 27 Jan 2004 23:14:21 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: source resolving in 2.2
References: <84F0A43A4248CE45B5C0E20F4C40779C600B49@naomi.webworks.nl>
In-Reply-To: <84F0A43A4248CE45B5C0E20F4C40779C600B49@naomi.webworks.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

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.

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com