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)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.
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).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 ;)
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 [EMAIL PROTECTED] 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
