- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Wed, 01 Dec 2004 13:10:26 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: www-svg@w3.org
At 02:31 PM 12/1/2004 -0600, Boris Zbarsky wrote: >Peter Sorotokin wrote: >>>I want to dynamically execute the script at http://foo at runtime. >>>Using language-dependent mechanisms in ECMAScript I have to somehow load >>>the data into a string (dealing with character encodings in the process) >>>and then call eval() on it? >>Yes. Use URIRequest and eval. > >And if I want to execute ECMAScript from Java or vice versa or either of >those from some other language that has easy access to the DOM but can't >easily evaluate the script string? It looked to me like SVG was trying to >really support Java and ECMAScript on an equal footing; was I wrong? We do support both Java and ECMAScript, but we don't try to define Java <-> ECMAScript interaction; it is much, bigger issue (and it falls outside of our mandate as well). >(Not to mention issues like trying to execute a JavaScript 1.2 script from >inside JavaScript 1.3 and so forth... eval really does not cut it there). I have made a proposal for API for this in the WG; that was deemed to be too corner of a case. Besides if you really want to do it, you'd want to get a result back in many cases, so API is much better approach. >>> Using a <script> node, I just set the src attribute and insert the node. >>I think this usage is a hack. > >Very well. Provide an alternate solution to the use cases this solves, >then? URIRequest and eval really don't cut it there. > >>URIRequest and eval works just as well for that. > >It does not, for the reason described above. It should be solved by APIs. >>Yes, I saw it; this implies that script element has some sort of a hidden >>state that has to be managed it some way. I'd rather not introduce it. > >Again, feel free to propose other solutions to these common use cases... WG does not consider this to be a common case. And, if you really want to program in *both* Java and ECMAScript you need to define a way for them to interact that goes way beyond inserting script element: you need to define, basically, how their object models interact. It is possible to define a simple API that allows you to execute a script to a particular script engine - even that would be much better than inserting script element (because you can get back the result and because you have well-defined execution point). Peter >-Boris
Received on Wednesday, 1 December 2004 21:10:33 UTC