cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: #{$cocoon/request/request/protocol}
Date Wed, 11 May 2005 08:03:25 GMT
Daniel Fagerstrom wrote:
>> 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.
> 
> 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.
The accessors do not solve the problem with 
$cocoon/request/requestAttribute or $cocoon/request/requestParameter 
(preferably $cocoon/request/attributes/someAttribute and 
$cocoon/request/parameters/someParameter)

>> 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 ;)
They aren't correct. The only thing changed from oryginal Request 
interface is that you can access request attribute using 
cocoon/request/attribute. It wouldn't work for "protocol" attribute as 
there is such property in Request interface. It does not work for 
request parameters at all - you have to query them using a method).

I'd like to fix that even before we move to accessors. I do not know how 
to do it properly though so these constructs provide valid results:

JEXL:
cocoon.request.property - works now
cocoon.request.parameters.someParameter
cocoon.request.attributes.someAttribute

JXPath:
$cocoon/request/property
$cocoon/request/parameters/someParameter
$cocoon/request/attributes/someAttribute

None of above JXPath constructs work now.
I've listed JEXL and JXPath separately because we have to provide 
different wrappers for Request interface.

Jexl uses JSIntrospector (assumes cocoon.request is scriptable).
JXPath assumes nothing and tries to work on the bean as it is - does not 
work at all.

Of course there are similar problems with session and context.
It is a serious blocker for users to just try to switch to 2.2-dev and 
use new JXTG.

> 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?
If you're asking for non-ugly ones - none..

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message