Craig wrote:This is unavoidable, since the API code will have to massage data going between MapTool and JavaScript and back again.
Probably. For many things, anyway.
I can see some things not needing any managing. Such as numbers and strings (which come into Java as Doubles and Strings). So methods like Token.getName() will work without change, but any code that modifies objects will need to be checked to ensure that related information stays up to date. That's what I expect the additional layer of code will do.
The use of Bean properties with method names that start with
js might take care of some of that. We're going to want a layer for other plugins anyway, so we could create one ProxyToken object that has functions like getName() and jsGetName(). The first is for use by Java-based plugins and the second is for use by JS. The JS one might handle permission issues that the plugin doesn't need to deal with, or maybe the JS one needs to do data conversion. But it keeps the interface layer for both in one place.
And in any case the JavaScript macro system will have to be sandboxed so that it can't mess with the internals of MapTool and only go through a well defined API.
Yep, as expected.
I read something the other day on Oracle's site regarding JSR-223 and integration of Java and JS. There are a lot of ways that Java functionality could be exposed that would reduce the amount of work needed in building the extra layer. The requests to the importClass() and importPackage() functions can be filtered, for example. And direct use of Java package names can be turned off as well.
I expect that the simplest approach will be to turn off access to everything, then put an object into the JS "script context" that acts as an interface layer. We then build the code for that object dynamically at the time we build the JAR files. The build process knows what to include by reading a config file, so when we decide to open a function up to JS, we edit the config file and we're done. Creating that build process is going to be a pain, though.