Hi Cameron, Helder, Helder Magalhães <[email protected]> wrote on 01/30/2009 11:27:01 AM:
> > I agree. Were I starting from scratch, I'd expose only > > importPackage, importClass and Packages from Rhino (as well as the > > classes from org.w3c). > > Exposing only these seemed like a good compromise! :-) > I'll be happy to help towards hunting and reworking those samples > which are tied to this sort of functionality, if this behavior is to > be changed... ;-) I've change the import stuff so it reads a file (META-INF/imports/script.txt) each line of the file can start with either 'package' or 'class' the rest of the line can be any number of space separated class/package names. Users of Batik can also get the 'ImportInfo' class and add additional classes/packages if they choose to. > > So perhaps the best solution is to make RhinoInterpreter (or maybe > > Interpreters in general, via InterpreterPool?) configurable as to > > whether it should import java.lang classes automatically. The file read can be adjusted by the property 'org.apache.batik.script.imports'. Also people can always replace the script.txt file if they want to. > > There's an argument to making Squiggle > > configure its JSVGCanvas not to import the whole java.lang package, to > > avoid incompatibilities with scripts that would work in other UAs, but > > I'd be happy either way there. I didn't do this but squiggle could easily add java.lang as an import package to the ImportInfo. I did add class java.lang.System since that is fairly useful. Comments?
