cocoon-dev mailing list archives

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

> Daniel Fagerstrom wrote:

<snip/>

>> 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.

<snip/>

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

/Daniel


Mime
View raw message