Using eval for contents retrieved with XMLHttpRequest()

[knocte]

Hello.

I have always thought that the eval() function was very flexible and
useful. If I use it, I can define functions at runtime!!

However, I have found a case where eval() does not work properly. It
works, for example, when invoking functions (alert('hello')), but not
for defining functions.

The case occurs when retrieving the javascript code with
XMLHttpRequest(). It fails on Mozilla/Firefox and IE!

I will quote the code:

<script>
function RequestDocument(sURL, bAsync) {
var oXmlRequest;



/* branch for native XMLHttpRequest object */
if (window.XMLHttpRequest) {
oXmlRequest = new XMLHttpRequest();
oXmlRequest.open("GET", sURL, bAsync);
oXmlRequest.send(null);
}
/* branch for IE/Windows ActiveX version */
else if (window.ActiveXObject) {
oXmlRequest = new ActiveXObject("Microsoft.XMLHTTP");
oXmlRequest.open("GET", sURL, bAsync);
oXmlRequest.send();
}

return oXmlRequest;
}

function EvalScriptFile(oDocument){
if (oDocument){

/* only if status shows "loaded" */
if (oDocument.readyState == 4) {

/* only if "OK" */
if (oDocument.status == 200) {
eval(oDocument.responseText);
}
else if (oDocument.status == 404) {
alert("File not found");
}
}
}
}

function LoadScriptFile(sURL){
var oScriptFileRequest = RequestDocument(sURL,false);
EvalScriptFile(oScriptFileRequest);
}











//this works:
eval("alert('hello');function test(){ alert('test'); };");
test();

//but, if I put on a file (called mylib.js and located at the same
//dir as this file on the web server), the following contents:
// alert('hello2');
// function test2(){ alert('test2'); };
//
LoadScriptFile("mylib.js");
test2();
//the first alert is called (hello2)! but debugger says
//that test2 is not defined!
// what happens??
</script>


Do anybody know why?? Thanks in advance.

Regards,

Andrew

--

 

[Vladdy]

Hello.

I have always thought that the eval() function was very flexible and
useful. If I use it, I can define functions at runtime!!

However, I have found a case where eval() does not work properly. It
works, for example, when invoking functions (alert('hello')), but not
for defining functions.

The case occurs when retrieving the javascript code with
XMLHttpRequest(). It fails on Mozilla/Firefox and IE!

I will quote the code:

<script>
function RequestDocument(sURL, bAsync) {
var oXmlRequest;



/* branch for native XMLHttpRequest object */
if (window.XMLHttpRequest) {
oXmlRequest = new XMLHttpRequest();
oXmlRequest.open("GET", sURL, bAsync);
oXmlRequest.send(null);
}
/* branch for IE/Windows ActiveX version */
else if (window.ActiveXObject) {
oXmlRequest = new ActiveXObject("Microsoft.XMLHTTP");
oXmlRequest.open("GET", sURL, bAsync);
oXmlRequest.send();
}

return oXmlRequest;
}

function EvalScriptFile(oDocument){
if (oDocument){

/* only if status shows "loaded" */
if (oDocument.readyState == 4) {

/* only if "OK" */
if (oDocument.status == 200) {
eval(oDocument.responseText);
}
else if (oDocument.status == 404) {
alert("File not found");
}
}
}
}

function LoadScriptFile(sURL){
var oScriptFileRequest = RequestDocument(sURL,false);
EvalScriptFile(oScriptFileRequest);
}











//this works:
eval("alert('hello');function test(){ alert('test'); };");
test();

//but, if I put on a file (called mylib.js and located at the same
//dir as this file on the web server), the following contents:
// alert('hello2');
// function test2(){ alert('test2'); };
//
LoadScriptFile("mylib.js");
test2();
//the first alert is called (hello2)! but debugger says
//that test2 is not defined!
// what happens??
</script>


Do anybody know why?? Thanks in advance.

Regards,

Andrew

Why would you use XMLHttpRequest to load a script? Following does an
adequate job and does not require the use of eval

loadScript(fileName)
{ var scr = document.createElement('script');
scr.type = 'text/javascript';
scr.src = fileName;
document.getElementsByTagName('head')[0].appendChild(scr);
}

 

[Don]

However, this sort of logical approach to injecting or inserting
javascript dynamically does NOT work in the latest version of Safari.

 

[Randy Webb]

However, this sort of logical approach to injecting or inserting
javascript dynamically does NOT work in the latest version of Safari.

Does the XMLHTTPRequest object "work" in Safari?
If not, then its a moot point.

 

[Don]

Yes (most of the time).

My errors with Safari have nothing to do with javascript insertion but
getting anything (e.g. HTML) from ASP code using ajax. I keep getting
errors, even after req.readyState == 4 where the req.status is
undefined, the statusText is undefined, and the responseText is null.
My code all works fine with Firefox and Netscape (and IE using the
ActiveX object). The only way I can make the errors go away is by
making the ajax calls synchronous rather than asynchronous, so I have
to check for a Safari browser and set the synch flag appropriately.

As for the dynamic javascript problem, Apple admits (a posting in one
of the Apple groups) that it is different from other browsers in this
way (they saw the js insertion functionality as a security issue) but
still want to do what other browsers are capable of doing.

 

[Lasse Reichstein Nielsen]

I have always thought that the eval() function was very flexible and
useful.

I feel the same way about flamethrowers

If I use it, I can define functions at runtime!!

What can you do with "eval" that you can't do with one or more
function expressions?

Working with syntax at runtime is ... volatile. Just like
flamethrowers

However, I have found a case where eval() does not work properly.

Not according to specification or not as you would want it to work?

It works, for example, when invoking functions (alert('hello')), but
not for defining functions.

.... but you said above that ... ?

The case occurs when retrieving the javascript code with
XMLHttpRequest(). It fails on Mozilla/Firefox and IE!

I will quote the code:

Actual code and platform where it fails, as well as a description of
the error later ... a good error report Keep it up!

Have you tried any other browser?

<script>

Use valid HTML. That way you can be sure that it's not the HTML that
causes your problems. In this case:

function RequestDocument(sURL, bAsync) {
var oXmlRequest;

/* branch for native XMLHttpRequest object */ ....
else if (window.ActiveXObject) {
oXmlRequest = new ActiveXObject("Microsoft.XMLHTTP");
oXmlRequest.open("GET", sURL, bAsync);
oXmlRequest.send();
}

Why not set an onreadystatechange handler to inform you when the
request is done (when asynchroneous)?

Anyway...

function LoadScriptFile(sURL){
var oScriptFileRequest = RequestDocument(sURL,false);
EvalScriptFile(oScriptFileRequest);
} .....
//this works:
eval("alert('hello');function test(){ alert('test'); };");
test();

But does this work?
---
function LoadScriptLiteral() {
eval("alert('hello');function test(){ alert('test'); };");
}
EvalScriptLiteral();
test();
---

It doesn't work, because the content is evaluated in the same scope as
the call to eval. That means that the declaration of test() happens
inside the function LoadScriptLiteral, and can't be seen outside of
it.

You have the same problem, because you call "eval" inside
LoadScriptFile.


One soultion would be to let the script declare its variables as
global variables:

var global = (function(){return this;})();
global.test2 = function() { alert("test2"); }

Not as pretty, but guaranteed to work.

I can't find a better way of doing it right now, but I'll keep
pondering

Good luck!
/L

 

[knocte]

Hello. Thanks for your answer!

Lasse Reichstein Nielsen escribió:

I feel the same way about flamethrowers

Are you saying that I wanted to throw a flame?

What can you do with "eval" that you can't do with one or more
function expressions?

I can run code that comes from an external source, for example.
Hey, I know the disadvantages of eval(), I was just commenting its
advantages.

Working with syntax at runtime is ... volatile. Just like
flamethrowers

I don't understand what you mean.

Not according to specification or not as you would want it to work?

Well, I actually didn't know.

... but you said above that ... ?

Excuse me? :?

Actual code and platform where it fails, as well as a description of
the error later ... a good error report Keep it up!

Well, if I say it fails on Mozilla/Firefox, I think the error is
platform-independent...

Have you tried any other browser?

No. I usually work with Mozilla or Firefox (because they respect
standards) and I do some tests later with IE (for compatibility).

Use valid HTML. That way you can be sure that it's not the HTML that
causes your problems. In this case:
<script type="text/javascript">

Well, thanks for your advice but I think here it is irrevelant; above
all, because I have used this "short" way so as not to paste unnecessary
things to the list. It's just an example.

Why not set an onreadystatechange handler to inform you when the
request is done (when asynchroneous)?

Because I am using synchronous mode in this case. I don't need it.

Anyway...


But does this work?
---
function LoadScriptLiteral() {
eval("alert('hello');function test(){ alert('test'); };");
}
EvalScriptLiteral();
test();
---

It doesn't work, because the content is evaluated in the same scope as
the call to eval. That means that the declaration of test() happens
inside the function LoadScriptLiteral, and can't be seen outside of
it.

You have the same problem, because you call "eval" inside
LoadScriptFile.

Yes, you got it. I doesn't have many experience with
javascript/ecmascript and I thought that, as well as for this language
the scope inside an "if" is the same as the one outside, it would happen
the same with functions, but I was wrong.

One soultion would be to let the script declare its variables as
global variables:

var global = (function(){return this;})();
global.test2 = function() { alert("test2"); }

Not as pretty, but guaranteed to work.

I can't find a better way of doing it right now, but I'll keep
pondering

Good luck!
/L

Hey, I find this way very useful to allow external functions access to
the global scope! Thanks very much for your comments.

Andrew

--

 

[knocte]

Vladdy escribió:

Why would you use XMLHttpRequest to load a script? Following does an
adequate job and does not require the use of eval

loadScript(fileName)
{ var scr = document.createElement('script');
scr.type = 'text/javascript';
scr.src = fileName;
document.getElementsByTagName('head')[0].appendChild(scr);
}

Thanks for your suggestion, but I prefer to use XMLHttpRequest this
time, for many reasons:

- I can control better when the javascript is evaluated, because I don't
delegate this task to the browser.
- I can do it synchronously, so as to wait until the file called is
loaded before loading more javascript code.
- I will be able to use this method even with bad-formed HTML documents
(for example, those without a head tag).

Regards,

Andrew

--

 

[VK]

The case occurs when retrieving the javascript code with

XMLHttpRequest(). It fails on Mozilla/Firefox and IE!

Actually XMLHTTP doesn't stay from "get XML or HTTP or whatever you'll
get in your head". It stays from "get XML data for HTML environment
(browser)". But I'm affraid that all hell broke loose already. Mr.
Knocte is getting his JavaScript this way, someone already tried to get
binary data stream. So soon I guess we'll see XMLHTTP used to download
music, pictures and "Star Wars Episode 3". So shall be it...

 

[Razzbar]

So shall also be many users scratching their heads as their browsers
hang useless, because some cowboy figured that if you put your JS
functions on the server and use a synchronous call, you are guaranteed
they will come a'running ever time, and execute when you want them to,
not before.

 

[knocte]

Razzbar escribió:

So shall also be many users scratching their heads as their browsers
hang useless, because some cowboy figured that if you put your JS
functions on the server and use a synchronous call, you are guaranteed
they will come a'running ever time, and execute when you want them to,
not before.

If JS don't work, my sites fallback to the fact that they don't support
client-side scripting, then many browsers will be supported only because
of this.

Regards,

knocte

--

 

[knocte]

VK escribió:

Actually XMLHTTP doesn't stay from "get XML or HTTP or whatever you'll
get in your head". It stays from "get XML data for HTML environment
(browser)". But I'm affraid that all hell broke loose already. Mr.
Knocte is getting his JavaScript this way, someone already tried to get
binary data stream. So soon I guess we'll see XMLHTTP used to download
music, pictures and "Star Wars Episode 3". So shall be it...

Actually, I think the feature should be just called "HttpRequest",
because nothing prevents me for getting anything I want with the Http
protocol using this.

Regards,

knocte

P.S.: Perhaps you should suggest to the responsible for DOM specs to
delete the accessibility to the ".responseText" attribute. That way
you'll be able to dictate how the technologies must be used.

--

 

[VK]

Actually, I think the feature should be just called "HttpRequest",

because nothing prevents me for getting anything I want with
the Http protocol using this.

"Who can stop Hafiz from likening a ladybug to the Padishah"
An old Persian proverbe ;-)

<http://groups-beta.google.com/group...ript+author:VK&rnum=19&hl=en#ba5264709e33894e>