cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: #{$cocoon/request/request/protocol}
Date Wed, 11 May 2005 09:54:12 GMT
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 :-)

> 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 


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message