RFE: Allow any javax.script language to be used for script code in HTML event attributes and script elements processed by WebView/WebEngine
Rony G. Flatscher
Rony.Flatscher at wu.ac.at
Thu Nov 7 10:44:44 UTC 2019
Currently it is possible to create one own's browser using WebView where the WebEngine processes
event attributes or script elements). This request for a feature enhancement is therefore asking to
enhance WebEngine such that it allows any of the javax.script languages to be used for writing
scripts in HTML, very much like FXML controllers can be implemented in any of the Java script languages.
The javax.script language (e.g. groovy, jruby, jython, rexx, ...) to be used could be determined
with the "type" attribute (expecting a mime-type) or like in MS InternetExplorer with the (in the
meantime deprecated) "language" attribute (expecting the language name).
As one of the results this would allow one to use WebView as the presentation (and print) layer for
(stand-alone) applications written in any javax.script language.
A comparable solution has been available (and quite heavily exploited in some companies) with MS
InternetExplorer and MS IIS allowing any ActiveX script language (JScript, VBScript, etc.) on
Windows to be used in client HTML text and ASP for server side (this exists for twenty+ years on
that platform). However, this solution has been restricted to MS Windows and MS InternetExplorer and
not supported by any other competing browsers.
Although HTML allows for denoting the name/mime-type of a script language used for script code, it
seems that only MS has honored that in the past.
Using WebView/WebEngine with any javax.script language would make a comparable solution totally
platform independent and truly portable (and independent of any other third-party Web browser like
Chrome, Safari, Firefox and the like). It is assumed that adding this feature would be quite
attractive for private use, but also for small to medium sized companies.
Any ideas how complex it would be to change WebEngine accordingly? Would there be related classes
that need to be changed as well? What pitfalls would one have to think about?
More information about the openjfx-dev