cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: #{$cocoon/request/request/protocol}
Date Wed, 11 May 2005 10:41:50 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:


>> Sylvain refactored the environment handling in flow to simplify it, 
>> but it also lead to some back incompatibilities that we had long 
>> heated discussions about this in the begining of this year, check the 
>> archive. The varoious changes in the TemplateObjectModelHelper was to 
>> keep it in synch with the changes in FOM_Cocoon.
> For the record, the back incompatible changes were removed :-)

I know that you removed them. But $cocoon/request/property doesn't work 
for JXPath, you need $cocoon/request/getProperty() instead, IIUC. I 
think this has to do with the  functionality of 
FOM_Cocoon.AttributeHolderJavaObject and that it is an effect of the 
refactoring, but maybe it didn't work before either.


>> But again, IMO we should start to use the accessors instead and focus 
>> our environment refactoring on them and remove the 
>> TemplateObjectModelHelper. I got stucked in the devlopment of them 
>> because I couldn't find any (non ugly) ways to make the sitemap 
>> parameters accessible as "cocoon.parameters", as accessors are 
>> components and only have access to the service manager and the 
>> context. If we separated the sitemap parameters from the rest of the 
>> environment handling we would get rid of this problem, but that would 
>> introduce a rather severe back incompability.
>> Any ideas?
> Update TreeProcessor so that it stores the parameter stack in the 
> object model?

Sound like a good solution!


View raw message