Leszek Gawron wrote:
Daniel Fagerstrom wrote:
<snip/>
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).
Are you certain about that it doesn't work for properties? I can't test right now, but looking at http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java?rev=27976&view=markup
in DynamicMap.getDynamicInfo it looks to me that it handle properties.
...
result = PropertyUtils.getProperty(*this*.information, key.toString());
...
I'd like to fix that even before we move to accessors.
Its a different concern from what accessors solves, so that sounds reasonable.
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
IMO we should make the Request interface bean friendly and add the methods:
Map getParameters(); Map getAttributes();
A poll is needed for such interface changes.
I'm not certain why $cocoon/request/property doesn't work. But I think that o.a.c.components.flow.javascript.fom.FOM_Cocoon.AttributeHolderJavaObject, the base class of FOM_Request etc, makes sure that the Java bean properties only can be accessed as functions, not as properties.
If we use the Request object directly in TemplateObjectModelHelper, the reflection mechanism in JXPath should be able to handle ordinary Java beans.
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.
IMO we should make Request bean friendly instead. To me it seem like all this special purpose reflection stuff only makes things hard to understand, use and maintain.
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.
IIRC it has nothing to do with the new JXTG, it didn't work with the original either. It is, IIRC, an effect of the refactoring of FOM in 2.2.
/Daniel
