Reinhard Poetz wrote:
Yesterday I tried to upgrade to the latest Cocoon and found out that jxpath expressions don't work, e.g. #{$cocoon/request/protocol.
Ideas?
Aren't you following the list ;) http://marc.theaimsgroup.com/?t=111573583200002&r=1&w=2. It is a well known problem, the environment is accessed through o.a.c.environment.TemplateObjectModelHelper, which in turn uses the request etc wrappers from FOM. I made it this way because I wanted the refactored JXTG to have exactly the same behaviour as the original one. And after some the refactoring of FOM some months ago accessing of properties like your example above stoped working both for the original and the refactored JXTG. The problem is that the FOM wrappers extends org.mozilla.javascript.NativeJavaClass which JXPath doesn't work with, while JEXL have specialized reflection code for JS and still work atfter the FOM refactoring.
The POJOfied Environment RT and vote threads was one step in geting rid of the dependency on the FOM wrappers. But there are still work left to do. Take a look at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.AttributeHolderJavaObject and the wrappers that extends it. From the description of the request wrapper:
/**
* JS wrapper for Cocoon's request object.
* <p>
* Request <em>parameters</em> are also present as properties on this object.
* Note that this is different from <code>FOM_Context</code> and <code>FOM_Session</code>
* that do the same with <em>attributes</em>.
*/
We must implement this behaviour in the TemplateObjectModelHelper before we can get rid of the dependency on FOM. There where something like that in TemplateObjectModelHelper once:
Carsten added such wrappers in rev 27976 of the TemplateObjectModelHelper and removed them in 153807. Maybe we should add them again ;)
/Daniel
