Is Eval Evil for Ajax Responses
Larry
I have seen numerous postings about eval() and its evils on this forum.
However, one of our developers is using it in the following way,
which seems like a great use of it.
Page makes Ajax request to ASP.Net web service. Web service does some
data lookup and builds a string representation of a Javascript array
which is then returned to the client. In the ajax callback, call to
eval on the returned string and voila, instant populated data
structure.
Another way to do this would be to pass back xml and walk the xml dom
in the callback, populating an array as you go.
Either way you have to do roughly the same amount of work on the server
(perhaps slightly less with no xml).
I am not worried about the compilation of the eval'd string. Our tests
have been lightning fast. Is the biggest danger in this case x-browser
issues?
Thanks,
Larry
Jim Ley
>I am not worried about the compilation of the eval'd string. Our tests
>have been lightning fast. Is the biggest danger in this case x-browser
>issues?
No, this is a perfectly fine reason to use eval.
personally I use
new Function("return "+str)();
but either way it's a sensible approach, much more sensible than an
XML document.
One other alternative is iframe's and regular script elements rather
than xmlhttp methods.
Jim,
Dr John Stockton
Nov 2005 15:54:51, seen in news:comp.lang.javascript, Jim Ley
<j...@jibbering.com> posted :
>On 16 Nov 2005 07:51:59 -0800, "Larry" <lpo...@gmail.com> wrote:
>
>>I am not worried about the compilation of the eval'd string. Our tests
>>have been lightning fast. Is the biggest danger in this case x-browser
>>issues?
>
>No, this is a perfectly fine reason to use eval.
>
>personally I use
>
>new Function("return "+str)();
>
>but either way it's a sensible approach, much more sensible than an
>XML document.
Is yours worth adding to the newsgroup FAQ section?
Presumably it can be misused in the same way as native eval.
It does have the disadvantages of being less obvious to a reader of the
code, and longer; how about
function EVAL(str) { return new Function("return "+str)() }
To the OP : FAQ 4.40 indicates your usage as being sound.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
RobG
VK
Larry wrote:
> Hi there:
>
> I have seen numerous postings about eval() and its evils on this forum.
> However, one of our developers is using it in the following way,
> which seems like a great use of it.
>
> Page makes Ajax request to ASP.Net web service. Web service does some
> data lookup and builds a string representation of a Javascript array
> which is then returned to the client. In the ajax callback, call to
> eval on the returned string and voila, instant populated data
> structure.
This is a perfect use of eval() and yes, it is very fast. The whole
idea of JSON (which is what you're actually doing) is based on eval()
and on its speed *equal* to the regular code parsing between
<script></script> tags.
I'm finding <http://www.jibbering.com/faq/#FAQ4_40> as well as "Eval is
Evil" slogan more as polemic exclamations of some historical buttle we
are not aware of. IMHO at the very least JSON should be mentioned in
4.40 as a sample of a legal use of eval(). ?
A real misuse of eval() I may think of is in retrieving object
references like:
var ref = eval("document."+formName); // etc.
Not because it will not work ar will be slower - but just because it's
programmatically ugly and unnecessary.
aundro
> A real misuse of eval() I may think of is in retrieving object
> references like:
> var ref = eval("document."+formName); // etc.
> Not because it will not work ar will be slower - but just because it's
> programmatically ugly and unnecessary.
I personally tend to think of the whole "Eval is Evil" thing as a
contamination from the Lisp languages. (not that I find lisp
contaminating in a bad way, it would be the absolute opposite: I
always code in Common Lisp (CL) as much as I can; it's my language of
choice!)
The use of eval in CL is often regarded as bad practice because you
rarely have to eval *yourself* some code.
On the other hand, there are very handy functions, like 'load' that
loads a (compiled) file (evaluating all it contains),
or 'read-from-string' to which you pass a string and whose primary
return value is.. an object!
The latter is not really the same as eval, as it expects a 'readable'
representation of an object, and does not evaluate it's argument
(that is: (read-from-string "(print \"Hello there\")" will _not_ print
"Hello there", but rather return a list containing the symbol 'print,
and the string "Hello there").
Still, even though 'read-from-string' does not evaluate it's argument,
a parallel can be established between:
(read-from-string "#(1 2 3)") ==> an array containing 1, 2 and 3
eval("[1 2 3]") ==> an array containing 1, 2 and 3
See my point?
In many cases, it seems we are using eval in JS just as we would be
using read-from-string in CL, so I don't think Eval really is that
Evil.
Arnaud
aundro
> eval("[1 2 3]") ==> an array containing 1, 2 and 3
eval("[1, 2, 3]")
of course ;)
Arnaud
Evertjan.
> (read-from-string "#(1 2 3)") ==> an array containing 1, 2 and 3
> eval("[1 2 3]") ==> an array containing 1, 2 and 3
>
> See my point?
> In many cases, it seems we are using eval in JS just as we would be
> using read-from-string in CL, so I don't think Eval really is that
> Evil.
>
a = eval('[1 2 3]')
that is not JS.
If you want to transform such string, what's wrong with:
a = '1 2 3'.split(' ')
Yes, eval is certainly evil.
--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)
Evertjan.
a = eval("[1, 2, 3]")
??
Still, the below way is simpler,
not using an extra instance of the JS-engine.
This especially important in a long loop.
a = '1,2,3'.split(',')
aundro
> aundro wrote on 17 nov 2005 in comp.lang.javascript:
> a = eval('[1 2 3]')
> that is not JS.
Yes, sorry bout that :)
>
> If you want to transform such string, what's wrong with:
> a = '1 2 3'.split(' ')
>
That is in case you absolutely know the objects you expect, and their
format, for a particular request.
What if you want one single 'request point' (that is: a function that
performs the XmlHTTPRequest, for example) that you can call for many
purposes?
For example: the first time, you'd like to fetch an array of
numbers (that's the example above); the second time, invoked from some
other code, you'd like to fetch Objects that represent some
server-side resource...
You could of course return the 'responteText' from that 'request
point', and do the parsing back in the caller's code, but I don't find
that particularly elegant either..
Of course, you still have the 'Function ("return" + str)()' solution.
> Yes, eval is certainly evil.
Do you (or others) have real examples why eval is absolute evil?
Arnaud
VK
Evertjan. wrote:
> a = eval('[1 2 3]')
> that is not JS.
Well, evidently it meant to be:
a = eval('[1,2,3]')
in which case it's a perfectly valid JS code. Programming languages
like human ones: if you have to use several of them at once you can
occasionally mix words and grammar :-)
The code by itself is meaningless though. A direct:
a = [1 2 3]
is of course better.
But we are talking in the context of OP's question related with the
object serialization and how could it be implemented in JavaScript. And
for the object serialization eval() / new Function() is often the only
way.
In reference to this question one can look at:
<http://www.crockford.com/JSON/index.html>
and specially at:
<http://www.crockford.com/JSON/js.html>
P.S. It is very interesting btw that in order to implement his concept,
the author had to accept eval() method and to admit existence of
hashtable and array as two separate programming entities. A perfect
proof that you can *believe* in whatever you want - but in order to
*do* something material you have to accept the materal nature of the
things you are dealing with.
Thomas 'PointedEars' Lahn
> "VK" <school...@yahoo.com> writes:
>> A real misuse of eval() I may think of is in retrieving object
>> references like:
>> var ref = eval("document."+formName); // etc.
>> Not because it will not work ar will be slower - but just because it's
>> programmatically ugly and unnecessary.
>
> I personally tend to think of the whole "Eval is Evil" thing as a
> contamination from the Lisp languages. [...]
An eval-like construct is available in many programming languages,
so I doubt that argument is valid. While LISP (1959) may be one
of the first programming languages, those languages did not all
follow the LISP approach.
It is generally bad practice to have source code evaluated through
a subprocess if the same result can be obtained in other ways. This
regards code quality in general (see "debugging") and especially
code security (see "code injection").
PointedEars
VK
Thomas 'PointedEars' Lahn wrote:
> It is generally bad practice to have source code evaluated through
> a subprocess if the same result can be obtained in other ways. This
> regards code quality in general (see "debugging") and especially
> code security (see "code injection").
OP posting is called: "Is Eval Evil for Ajax Responses" (not "Is Eval
Evil In My Code").
Could we stay a bit closer to the topic?
Evertjan.
>> Yes, eval is certainly evil.
>
> Do you (or others) have real examples why eval is absolute evil?
Please do not change my words, I did not say "absolute".
The evil is in the extra calling of an instance of the JS engine.
In a loop, this can be prohibitive.
The evil is in the use, where it is not necessary.
[and in this forum, giving a bad example to the newbies]
s = "[1, 2, 3]"
a = eval(s)
this use is accepable to me, but for the notion that defining an array from
a string with [] is really the way to do.
and even then a regex could do the same:
s = "[1, 2, 3]"
a = s.replace(/[\[\] ]/g,'').split(',')
longer in code, but no engine trouble.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> It is generally bad practice to have source code evaluated through
>> a subprocess if the same result can be obtained in other ways. This
>> regards code quality in general (see "debugging") and especially
>> code security (see "code injection").
>
> OP posting is called: "Is Eval Evil for Ajax Responses" (not "Is Eval
> Evil In My Code").
And I did not refer to the OP's posting but to aundro's statement.
> Could we stay a bit closer to the topic?
This is a discussion medium, not a support forum. When will you get that?
> <http://www.jibbering.com/faq/#FAQ2_3> :-)
Irrelevant regarding your note.
PointedEars
aundro
> s = "[1, 2, 3]"
> a = eval(s)
>
> this use is accepable to me, but for the notion that defining an array from
> a string with [] is really the way to do.
In this case, where you know the format of the string you evaluate,
it's not very appropriate to use eval, I think.
Actually, I was thinking of creating objects whose
properties/structure you can't 'guess' on the client-side; those can be
pretty complex. In that case, using an eval might probably become more
efficient than parsing strings.
> and even then a regex could do the same:
>
> s = "[1, 2, 3]"
> a = s.replace(/[\[\] ]/g,'').split(',')
Agreed, but then again you know the structure before parsing (in this case,
you know it's a flat array).
Arnaud
Evertjan.
>> s = "[1, 2, 3]"
>> a = s.replace(/[\[\] ]/g,'').split(',')
>
> Agreed, but then again you know the structure before parsing (in this
> case, you know it's a flat array).
>
Then again, if you don't know the structure,
how could you be sure it will eval to an array?
I think you always have to know the structure or possible structures.
If you don't, as with unvalidated clientside input, you would have to
validate first [or do a try.. catch every time]
aundro
> aundro wrote on 17 nov 2005 in comp.lang.javascript:
>
>>> s = "[1, 2, 3]"
>>> a = s.replace(/[\[\] ]/g,'').split(',')
>>
>> Agreed, but then again you know the structure before parsing (in this
>> case, you know it's a flat array).
>>
>
> Then again, if you don't know the structure,
> how could you be sure it will eval to an array?
Precisely: for more complex cases than arrays eval() might, I think,
be more efficient. Perhaps an example would be appropriate :)
What I'm thinking of is a tree, for example.
Let's say the server return this kind of string:
"{value : 'top', nodes : [
{value : 'x00', nodes : [
{<deeper, deeper structure>}]},
{value : 'x01', nodes : [
{<again, deeper, deeper structure...>}]}]}"
Then, you'd have to do a rather complex parsing yourself, and then
build 'node' objects, setting their properties, setting up a tree
... while eval() would make this straightforward.
That's why I actually compared some uses of eval() to Common Lisp's
read-from-string: in order to _build objects_. (probably I didn't make
that clear, sorry)
I personally rarely send code to be eval'd, that has any other
effect than creating objects.
>
> I think you always have to know the structure or possible
> structures.
In this case, I know the structure.
Yet, it can be very tedious (and very inefficient) to parse, I
guess. Am I mistaken, here?
Arnaud
Evertjan.
Tedious and inefficient programming yes, that is a valid point.
Inefficient executing no, IMHO.
However, discouraging eval() in this NG is a valid, as most of the users
that are influenced by it are the newbies, I hope.
Lasse Reichstein Nielsen
> JRS: In article <437b55cb....@news.individual.net>, dated Wed, 16
> Nov 2005 15:54:51, seen in news:comp.lang.javascript, Jim Ley
> <j...@jibbering.com> posted :
>>new Function("return "+str)();
>
> Is yours worth adding to the newsgroup FAQ section?
>
> Presumably it can be misused in the same way as native eval.
Pretty much. It has only one difference, perhaps advantage, compared
to eval: The evaluation does not happen in the current scope.
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Douglas Crockford
Using eval on JSON text is one of the very few instances where it is
good to use eval.
The security issue depends on how much you trust the server. If you
are getting data from the same server that issued the page, then using
eval is no less secure than the html it vended.
If you are getting data from a potentially dangerous server that could
steal cookies or send messages to your server as you, then you must
not use eval. You can use JSON.parse instead, which would be safe.
matty
Larry wrote:
> Hi there:
>
> I have seen numerous postings about eval() and its evils on this forum.
> However, one of our developers is using it in the following way,
> which seems like a great use of it.
Google Earth uses eval to execute a (large) piece of javascript code
that is returned from the XMLHttpRequest. It's great and works wonders.
Google is Evil though :)
Jasen Betts
>
> Google Earth uses eval to execute a (large) piece of javascript code
> that is returned from the XMLHttpRequest. It's great and works wonders.
> Google is Evil though :)
>
Hmm what's evil about it? it can't do anything this way that it couldn't
do with regular html and javascript.
It seems more efficient to parse javascript and interpret it than to parse
XML and interpret that using interpreted javascript.
Bye.
Jasen
Matt Silberstein
<a...@remove.the.a.in.ionicsoft.com> in
<87fypvi...@paddy.ionicsoft.com> wrote:
[snip]
>Actually, I was thinking of creating objects whose
>properties/structure you can't 'guess' on the client-side; those can be
>pretty complex. In that case, using an eval might probably become more
>efficient than parsing strings.
Isn't one of the points of XML that the data self-describes? That is,
by getting an XML response and then parsing as such you figure out the
structure. This allows a consistent approach to a variety of data
structures and allows "none" (which probably means minimal) changes to
the client side if the data structure is changed on the server side.
(I am coming at this with a large programming background, but little
specific experience with these technologies. I will have insights that
are both interesting and new. Unfortunately the new insights won't be
interesting and the interesting insights won't be new.)
[snip]
--
Matt Silberstein
Do something today about the Darfur Genocide
http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org
"Darfur: A Genocide We can Stop"
Jasen Betts
> Isn't one of the points of XML that the data self-describes? That is,
> by getting an XML response and then parsing as such you figure out the
> structure. This allows a consistent approach to a variety of data
> structures and allows "none" (which probably means minimal) changes to
> the client side if the data structure is changed on the server side.
Only if the tags are recognisable and intelligible to the client
application.
> (I am coming at this with a large programming background, but little
> specific experience with these technologies. I will have insights that
> are both interesting and new. Unfortunately the new insights won't be
> interesting and the interesting insights won't be new.)
XML is mainly a neat way to store structured data in flat files.
Bye.
Jasen