Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
<snip/>
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 :-)
I know that you removed them. But $cocoon/request/property doesn't work for JXPath, you need $cocoon/request/getProperty() instead, IIUC. I think this has to do with the functionality of FOM_Cocoon.AttributeHolderJavaObject and that it is an effect of the refactoring, but maybe it didn't work before either.
$cocoon/request/getProperty() this will not work now either.
JXPath queries FOM_Request for properties (with public getters - thats my understanding) and gets none "meaningful" as FOM_Request looks like this:
public static class FOM_Request extends AttributeHolderJavaObject {
private final Request request;
public FOM_Request(Scriptable scope, Request request) {
super(scope, request, Request.class);
this.request = request;
}
protected Enumeration getAttributeNames() {
return this.request.getParameterNames();
}
protected Object getAttribute(String name) {
return this.request.getParameter(name);
}
}
If you "accidentally" provide a getter for private final Request request;
than you are able to do $cocoon/request/request/protocol and the properties are visible. It means that FOM_Request is not able to properly proxy Request interface to JXPath.
-- 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
