Hi John,
You asked me to email you to elaborate on the use case I was asking
about regarding evaluating dynamic JavaFX script...
I would like to be able to create JavaFX scripts dynamically which
define "Scenes". I would then like to be able to send the JavaFX script
to the client (i.e. JavaFX applet running in a browser) and have the
client compile / run the scene (it might be nice to even send portions
of a Scene Graph to be updated or added to the existing Scene Graph).
One of the nice things about virtually all scripting languages is the
ability to dynamically process them. However, JavaFX does not seem to
be able to do this easily. The parsing capabilities of the language
have .jar file dependencies that don't exist in the typical environment
(perhaps there is an easy way around this? I haven't found one).
Working in this manner versus statically defining scenes in a .jar file
which is packaged and deployed as an applet, would allow me to easily
convert our large traditional JSF-based application to JavaFX (this
assumes also that the necessary input components and other equivalent
functionality is available -- I understand this is something that is
coming soon). In addition, our application allows for "plugins" which
add new pages or page fragments to our application (which would be new
scenes or often scene fragments in JavaFX). This means our application
is not well defined at "build time", much of it is discovered much later
than that by our plugin system. Dynamically evaluating JavaFX script
would make this very easy.
I do not think it would be a good solution to compile JavaFX script on
the server and send an entirely new JavaFX applet for every change.
While this might be doable with JavaFX today (not sure), I would rather
leave 1 (or potentially several) JavaFX applets running in the browser
for a long period of time while updates are made to them (swapping out
scenes). Otherwise, we'd end up with lots of browser pages which have
to reload applets over and over, which does not appear to be a good
solution at all.
Is this making sense? I tried proto-typing something which attempted to
use a plain Applet which called FXEvaluator.eval(...) on a java.fx
script it retrieved from the server. I was able to get the .fx script
but have not yet gotten past a security exception:
java.lang.RuntimeException: java.security.AccessControlException: access
denied (java.util.PropertyPermission
com.sun.tools.javafx.script.sourcepath read)
at javafx.util.FXEvaluator.eval(FXEvaluator.java:79)
at Hello.paint(Hello.java:38)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:814)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
at
javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:694)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.security.AccessControlException: access denied
(java.util.PropertyPermission com.sun.tools.javafx.script.sourcepath read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:652)
at
com.sun.tools.javafx.script.JavaFXScriptEngineImpl.getSourcePath(JavaFXScriptEngineImpl.java:349)
at
com.sun.tools.javafx.script.JavaFXScriptEngineImpl.parse(JavaFXScriptEngineImpl.java:191)
at
com.sun.tools.javafx.script.JavaFXScriptEngineImpl.eval(JavaFXScriptEngineImpl.java:149)
at
com.sun.tools.javafx.script.JavaFXScriptEngineImpl.eval(JavaFXScriptEngineImpl.java:140)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247)
at javafx.util.Evaluator.eval(FXEvaluator.java:40)
at javafx.util.FXEvaluator.eval(FXEvaluator.java:77)
... 13 more
Anyway, this approach may not be correct and may be attempting to work
around the currently supported methods of processing a JavaFX script. I
think what I am trying to do would be very interesting to web developers
as it would allow them to develop applications the way they are used to
developing them (or to migrate legacy web applications -- as in our
case). I'd be happy to answer more questions about this if you'd like.
Thanks,
Ken Paulsen
GlassFish Administration Console Architect
ken.paulsen_at_sun.com
x42083