cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: JXTemplate initialization in non-flowscript scenarios
Date Sat, 21 May 2005 09:15:36 GMT
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
> 
>> Ok, but I still need to know the content of the value attribute to the 
>> jx:set that creates the problem to be able to help. From the 
>> stacktrace it seem like something goes wrong when JXPath uses 
>> reflection on the value.
> 
> 
> The debugger showed that it's this line:
>       <jx:set var="cformsHelper" 
> value="#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}"/>

> 
> 
> Unfortunatly my knowledge in jxtemplate isn't sufficient to see the 
> difference between the two cases (with/witout <map:flow/>).

You are only supposed to have direct access to java.*, IIUC, packages 
from FOM for other packages you must have a "Package." prefix, i.e. 
value="#{Package.org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}

This is the behaviour that is implemented in 
o.a.c.environment.TemplateObjectModelHelper.addJavaPackages.

In 
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupPackages 
the packages javax.*, org.* and com.* where also setup so that you have 
direct access to them in rev 26848. The log says: "Also added 
experimental fix to provide direct access to javax, org, and com 
packages". Don't know if there was any discussions or decisions about this.

Anyway, we have had the functionality for 16 months, so we should 
probably continue to support it.

/Daniel

Mime
View raw message