W3C home > Mailing lists > Public > www-svg@w3.org > December 2004

Re: inserting script element [Was: LC Comment - Script & Progressive Rendering / Multiple Pages]

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
Message-id: <5.2.0.9.2.20041201125744.032e7e00@mailsj-v1.corp.adobe.com>

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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT