cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: #{$cocoon/request/request/protocol}
Date Wed, 11 May 2005 10:05:53 GMT
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
>> Leszek Gawron wrote:
>>> Leszek Gawron wrote:
>>>> Vadim Gritsenko wrote:
>> <snip/>
>>>>> Why FOM_Request is in jx in the first place? I understand why it is 
>>>>> in old jxtg in Cocoon 2.1, but new version should be flow independent.
>> The flow independence we talked about was to make JXTG work without 
>> needing to call flow before JXTG in the pipeline, not about making it 
>> independent from the flow code. As discussed before in various 
>> threads, we should factor out environment handling code from flow, 
>> jxtg and sitemap and have a common model. I started to work on such 
>> code in o.a.c.components.accessor in the template block.
>>>> for that we have to ask Daniel as he was the one to introduce it in 
>>>> TemplateObjectModelHelper revision 159059: "Using FOM wrappers for 
>>>> request session and context, to get the same behaviour as in the 
>>>> original JXTG."
>>>> We should revert it IMO and fix inconsistencies other way.
>>> AAHA! remember now. On pure o.a.c.environment.Request you cannot do
>>> coocon/request/someParameter (previous syntax) or the better one:
>>> cocoon/request/parameters/someParameter
>>> cocoon/request/attributes/someAttribute
>> 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 :-)
from flow POV, not JXPath in JXTG...

>> We could copy the wrappers from flow to make jxtg independent from 
>> flow. But as long as we don't factor out flow to a separate block I 
>> don't see the point. IMO it is better to focus on finish and start 
>> using the accessors that we have discussed in earlier threads about 
>> unified unvironment models.
>>> We could provide some kind of request wrapper (do not know how to 
>>> emulate getParameters though) or implement RequestJXPathBeanInfo (do 
>>> not know how also :))
>> Carsten added such wrappers in rev 27976 of the 
>> TemplateObjectModelHelper and removed them in 153807. Maybe we should 
>> add them again ;)
>> 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?
Seems like addressing a problem at the basis :)

Leszek Gawron                            
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message