• SurfMan (unregistered) in reply to Stefan W.
    Stefan W.:
    Carburizer:
    I don't know Java, but the coder might have thought of ...
    You don't know Java and you don't know javascript. This here is javascript. Java != Javascript - or to speak more on topic: eval (Java != Javascript) == true.
    Just keep your stinky javascripts off my lawn :-)
  • (cs) in reply to Matt Burgess
    Matt Burgess:
    document.getElementById has been available a long time, but is iffily implemented in IE up to and including IE6. Specifically, IE will actually retrieve the NAME rather than the ID.

    In fact, it is up to and including IE7. Having just tested this with your code, I can say that IE7 gets the element with the name "name" rather than the one with the id "name".

    It is a problem, though anyone who actually feels the need to give an element a name equal to another element's id should probably stop and make very sure he really needs to do that.

  • Martin (unregistered) in reply to zzzxtreme
    zzzxtreme:
    not only that eval in js is 'global'

    No, eval's execution context is the current one. You might be thinking about setTimeout or setInterval.

  • (cs)

    ... I don't even.. I...

    WTF!

  • Porpus (unregistered) in reply to Cloak
    Cloak:
    Pilum:
    Another big WTF is using document.all to access an element.

    getElementById works only since IE6.

    Yeah, I am tired of these DOM nazis like Pilum. These kind of people love to "deprecate" (or at least criticize) something that has worked for years. They take something like HTML / JavaScript and write some stupid standard for it years after the fact. Then, with the stroke of a pen, all of our code is rendered "non-compliant" years after it was written.

    The height of absurdity is that VS.NET verifies ASPX markup against some kind of XHTML "standard." All of the ASP tags fail this check, and the compiler generates bogus "errors." Some HTML-compliant markup that is not XHTML-compliant fails also. Of course, everything still WORKS fine.

    Maybe there is a special little section in Hell for these people who write phony standards.

  • Edward Royce (unregistered)

    Hmmm.

    I'd suggest that there be a special section of Hell reserved for:

    1. The people who designed Javascript to begin with.

    2. The people who think having a vendor specific implementation of Javascript is a good thing.

    3. The people responsible for not implementing Javascript and the DOM as a plugin.

    The thing I hate most about developing for web apps is dealing with browser variations. Which I why I try to do back-end stuff rather than browser oriented work.

  • geckoX (unregistered) in reply to Cloak
    Cloak:
    Pilum:
    Another big WTF is using document.all to access an element.

    getElementById works only since IE6.

    That's why most people now do this for backwards compatibility in a standard js include file, which allows all subsequent DOM access to be written to the standard, but still work with older browsers with a dom, and degrades gracefully for others.

    if( !document.getElementById && document.all )
{
	document.getElementById = function( id )
	{
		return( document.all[id] );
	}
}
else if( !document.getElementById && !document.all )
{
	document.getElementById = function( id )
	{
		return( null );
	}
}
  • mjj (unregistered) in reply to s0be

    What else would the eval() function be for if you werent supposed to use it to run the code?

  • (cs) in reply to vt_mruhlin
    vt_mruhlin:
    Zygo:
       companyName = unescape(companyName);
   if (window.opener){
      jStr1 = "window.opener.document.all.IcompanyName.value = trimString(unescape(companyName))"

    OK, I've never written a line of Javascript in my life, but isn't that unescaping companyName twice (thus requiring companyName to look like "Smith & Wesson" or "Coca%252DCola")? Or are the two companyName variables in different scope or something?

    Asymmetrical escaping and unescaping always makes me reach for the nearest loaded firearm.

    You're looking at it backwards. escape("Coca-Cola") would return "Coca%2DCola", thus escape(escape("Coca-Cola")) would give "Coca%252DCola"

    Unescape reverses the process. So if it was originally "Coca%2DCola", unescaping the first time will change it into "Coca-Cola", and the second time will do nothing.

    You may have heard of code red and nimda. This was the original source of the first major worms and spambots - IIS5 had dozens of places where it would do this twice, which let someone input nicely double-escaped text, let it get through the first phase of validation, and then get unescaped one more time to become a hijack.

    Double-escaping and unescaping is usually a bad idea, it's quite easy to forget to escape twice or unescape twice, letting trash into the page.

  • Matt Burgess (unregistered) in reply to mjj
    mjj:
    What else would the eval() function be for if you werent supposed to use it to run the code?

    There is a difference between what you can do... and what you SHOULD do.

    Coldfusion, for example, uses EVAL quite routinely to get around limitations in the language itself. But good PHP developers avoid it like the plague, and in many shops it's banned outright.

    The question you have to ask yourself when using eval() to do something is... is there a better way to do this?

    The answer, of course, is yes.

  • Jonathan Franzone (unregistered)

    Perhaps they were trying to write cross-browser code... or at least code that would not break in non-IE browsers. document.all is an IE only construct, so maybe he got some errors in Mozilla based browsers and figured he'd just to a try/catch with an eval to prevent errors.?

    Other than that... it looks completely stupid.

  • brillyfresh (unregistered) in reply to Porpus
    Porpus:
    Cloak:
    Pilum:
    Another big WTF is using document.all to access an element.

    getElementById works only since IE6.

    Yeah, I am tired of these DOM nazis like Pilum. These kind of people love to "deprecate" (or at least criticize) something that has worked for years. They take something like HTML / JavaScript and write some stupid standard for it years after the fact. Then, with the stroke of a pen, all of our code is rendered "non-compliant" years after it was written.

    does that make w3c "dom nazis" as well?

    document.getElementById() has been a method of DOM since Level 1 HTML spec (http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html, 1998), and in core spec since Level 2 (http://www.w3.org/TR/DOM-Level-2-Core/core.html, 2000), while document.all is just as proprietary and non-standard, and virtually obsolete, as document.layers, and unless you and/or your clients use IE4 or NS4, you don't need either

    if you do web dev, especially DOM scripting, you would almost immediately see the importance for having w3c standards and recommendations just from this example alone

    Porpus:
    The height of absurdity is that VS.NET verifies ASPX markup against some kind of XHTML "standard." All of the ASP tags fail this check, and the compiler generates bogus "errors." Some HTML-compliant markup that is not XHTML-compliant fails also. Of course, everything still WORKS fine.

    not sure what version of VS.NET you're using, but my built-in validator in VS 2005 doesn't trip up on server controls ... and html/xhtml validation is only useful after the page is rendered anyway; are you trying to validate the page file itself while still on the server?

    as for your XHTML "standard": http://www.w3.org/TR/xhtml1/

    frankly, i'm surprised you even pay attention to xhtml validation, and i'd be even more surprised if you even actively validate your pages

    Porpus:
    Maybe there is a special little section in Hell for these people who write phony standards.

    seriously, learn about w3c, who they are, why they and their "phony standards" are important ... otherwise stick to codebehind and .NET, and leave client side web dev for real web devs ;)

    wow, talk about wtf ... i sincerely hope you're just trolling, because if you aren't, you're just creating the mess that us real web devs eventually have to clean up ... that's our hell

  • eval(myass) (unregistered)

    My guess is this is obfuscation to get around ad blockers. See also: document.write("<SCR" + "IPT>[...]");

  • David Schwartz (unregistered) in reply to durnurd

    "[W]hat's the point of assert(0 == 1) in a language that supports throw?"

    There could be a couple of reasons, depending on the specifics. First, the 'assert' may be easier to modify in a debug build to log the file name and line number. Second, the code may not use exceptions anywhere else and handling them just for debug seems a bit odd. Third, the 'assert' may do some other processing and then call 'throw' anyway, so if you want the additional processing, calling 'assert' may be to your advantage.

    Lastly, 'assert' clearly identifies it as debugging code, whereas 'throw' does not. This may permit certain type of optimization or evaluation bypassing in a release build. Obviously, bypassing evaluation won't help much for '0 == 1', but that might explain a general habit of using 'assert' instead of 'throw'.

Leave a comment on “Eval This!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article