Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <428C44C5.20000@nada.kth.se>
Date: Thu, 19 May 2005 09:48:21 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: JXPath environment expressions broken in jxtemplate
References: <428C2C12.1030908@apache.org>
In-Reply-To: <428C2C12.1030908@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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