Currently it is possible to create one own's browser using WebView where the 
WebEngine processes
script code written in JavaScript for event attributes or for script elements.

WebEngine is currently implemented such that only JavaScript gets supported for 
scripts in HTML (in
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?

---rony


Reply via email to