> 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). At the moment, there are standalone SVG files in > samples/ that rely on java.lang being imported. I suspect that there > are many users of Batik who create/use documents with such a dependency, > too.
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... ;-) > 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. A JSVGCanvas > would import by default, for compatibility with those writing their own > applications using Batik. 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. Those who want to embed a JSVGCanvas in > an applet can configure it not to import java.lang. > > Thoughts? IMO this would be the best solution also. Allowing to disable the java.lang binding would be ideal for standard SVG content which is not relying or targeted to Batik in particular, potentially saving from ECMAScript variable collisions with java.lang class names and/or methods. :-) Not sure where can I help further (apart from the sample rework offer above), given my limited Java and Batik expertize, but ideas would be welcome (if these ideas proceed, naturally)... ;-) Regards, Helder --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
