For scripting languages that possess javax.script (part of Java since Java
1.6/6!) implementations
the JavaFX infrastructure is of a great attractivity.
JavaFX would allow script programmers for creating platform independent GUIs to
take fully advantage
for their own purposes, i.e. "surfing on Java" to get at a modern, maintained,
up-to-date GUIs in an
open manner!
Of course, scripting support in form of Nashorn/ECMAScript/Javascript is on
board of modern Java
distributions, however there are many more javax.script scripting languages
available. (In my case I
am very interested in ooRexx, the opensource version of IBM's Open Object Rexx,
which is a very easy
to learn, yet powerful OO language, and am the author of the JSR-223
implementation of ooRexx, which
will be included in the next distribution of BSF4ooRexx which is a bridge
between ooRexx and Java.)
While evaluating the possibilities (for non-informatic students) of taking
advantage of the JavaFX
infrastructure, I have been experimenting and exploring the JavaFX
infrastructure. Being acquainted
with the details of javax.script/JSR223 it has been very interesting to learn
how javax.script is
being deployed on JavaFX. Basically, using SceneBuilder and then manually
editing the FXML file it
becomes possible to run any scripting programs from (I assume FXMLLoader),
given that there is a
processing instruction like e.g.
<?language rexx?>
or
<?language Nashorn?>
which causes FXMLLoader to load the denoted scripting language by name. As a
result all script code,
be it defined in fx:script elements with a source attribute pointing to the
file containing the
script code or any code supplied in attributes like "onAction" will be executed
with this denoted
scripting engine.
This is it. Nothing else is currently available. Not even employing
javax.script programming
languages in the context of a WebView/WebEngine, although HTML defines a "type"
attribute for the
"script" element!
E.g, it is not possible to employ more than one script language for the same
document, although this
is plain easy! Or, it is not possible to have script controllers defined (only
Java controllers) in
SceneBuilder. Or it is not possible to use javafxpackager to create a jar-file
with pure
javax.script code and JavaFX resources, as there is no support to denote a
script to be used as the
"main class".
---
As this is the JavaFX developer list, I would like to propose in this e-mail
very few and (really!
:) ) easy to implement enhancements that immediately would increase the
usability and the
attractiveness of JavaFX for script writers. If there is an official tracker
infrastructure where I
could post at least the simple enhancements, please advise!
---
1. Suggestion # 1: wherever script code can be denoted, allow a "type"
attribute with the mime type
value of the javax.script engine to be used to execute the script code.
Whenever such a "type"
attribute is found, one can load the respective javax.script engine by
merely using
javafx.script.ScriptManager.getEngineByMimeType(mimeType) and then have it
execute the script code.
FXML candidates are the fx:script element itself as well as all attributes
(like "onAction")
that allow to denote script code. But also in HTML 5 (WebView/WebEngine)
the script element and
its "type" attribute (cf. <https://www.w3.org/TR/html5/scripting-1.html>).
* Examples in FXML-documents:
<fx:script source="myProgram.js" type="text/javascript" /> <fx:script
source="myProgram.rex"
type="text/x-rexx-java" />
* Example in any fx-elements that have attributes that allow code:
<Button fx:id="button" layoutX="170.0" layoutY="89.0" onAction= "use
arg slotDir /* always
supplied by BSF4ooRexx as the last argument */ ; call klickButtonAction
slotDir /* now
process the event, pass on slotDir */ ;" type="text/x-rexx-java"
text="Click Me!"
textFill="GREEN" />
2. Suggestion # 2: whenever (probably FXMLLoader, WebEngine) execute
javax.script code, then please
add the following entries to javax.script.ScriptContext.LOCAL_SCOPE
javax.script.Bindings:
1. if the "source" attribute (script-element in HTML 5, fx:script-element
in FXML) denotes a
file name, then use the key javax.script.Engine.FILENAME and store the
value of "source" in
the LOCAL_SCOPE Bindings. The scripting engine implementation is then
able to supply that
name to the script program (e.g. in the case of a runtime error, or for
debugging purposes),
which currently is not possible.
2. if arguments are to be passed to the script code, then create a Java
array object with the
arguments, use the key javax.script.Engine.ARGV and store the Java
array with it. The
scripting engine implementation is supposed to pass on these arguments
in the scripting
language's format, which currently is not possible.
As you can see, these are very few suggestions, but for javax.script language
programmers (no matter
which languages they use and mix) they immediately improve the usability of
JavaFX tremendeously!
It would be great, if someone would be able and willing to implement these
little suggestions
(probably in the FXMLLoader and WebEngine classes). If there is anything I
could do to help, please
let me know (also, if anyone can point me to a formal way of submitting these
requests for
enhancements to a JavaFX-tracker related system, I would appreciate it).
---rony
P.S.: It may be the case that the original javax.script developer(s) in JavaFX
have departed and no
one else has a working knowledge of javax.script. Even if that would be the
case the above
suggestions would be still very easy to implement for any professional Java
programmer! In case
there would be javax.script related questions that I can answer (I served as an
expert on JSR-223
that defined the javax.script framework), I would be more than happy to do so.
P.P.S.: If anyone can point me at the trackers for the Java development kit's
"jrunscript.exe" (can
only run Nashorn scripts, running other script engines causes errors despite
documenting, that that
should be possible) and to the Nashorn bug tracker (its script factory creates
output statements
with syntax errors that Nashorn throws up upon), I would file the found bugs
there.
