Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

So How Do You Code an AJAX Web Page? 231

PetManimal writes "Computerworld has a long excerpt from a book by Edmond Woychowsky about how to code Web pages in AJAX. It gives a good explanation of how the technology works, and also has some visuals and code snippets that you can play with. From the article: 'Beyond the XMLHTTP Request object, which has been around for several years as a solution looking for a problem, there is nothing weird needed. Basically, it is how the individual pieces are put together. When they're put together in one way, it is nothing more than a pile of parts; however, when put together in another way, the monster essentially rises from its slab.'"
This discussion has been archived. No new comments can be posted.

So How Do You Code an AJAX Web Page?

Comments Filter:
  • Saving AJAX (Score:5, Insightful)

    by Doc Ruby ( 173196 ) on Friday August 04, 2006 @03:36PM (#15848375) Homepage Journal
    How do I save an AJAX page in a given state, rather than just a state that will be "rebooted" on reload from storage?
  • Huh (Score:5, Insightful)

    by Bogtha ( 906264 ) on Friday August 04, 2006 @03:38PM (#15848383)

    Print version here. [computerworld.com]

    Zero credibility points for trying to put markup in the <title> element and hiding the printable version behind a javascript:void(0) link.

    If you want the technical stuff, skip about a third of the way down. The first third of the article just repeatedly tells you that Ajax is when the page doesn't "blink".

    The code he supplies is crap. For instance:

    <html> <head>

    <framese t rows="100%,*">
    <frame name="visible_frame" src="visible.htm">
    <frame name="hidden_frame" src="hidden.htm">
    <noframes>Frames are required to use this Web site.</noframes>

    Things wrong with even this tiny snippet of code:

    • Invalid.
    • Frames (at the very least, he should have used iframes).
    • Cheesy "fuck off" error message instead of functional equivalent.

    Skimming the rest of the article, I see the following mistakes:

    • Using DOM methods without testing for their existence.
    • Browser detection (which is stupid and wrong [quirksmode.org]).
    • Obtrusive JavaScript embedded in the page with old-fashioned HTML attributes.
    • Non-degradable JavaScript form submission with <button> instead of <submit>.
    • Confusion over what elements and tags are.
    • Internet Explorer-only code without error checking or a fallback.

    If this is a representative sample of the book it is excerpted from, steer well clear of it. The whole approach is poor.

    The best way of producing compatible, accessible Ajax applications is to start with the bare HTML and make that work. Only then do you add the JavaScript, and you do it by enhancing the page, not replacing it. For instance, don't use <button onclick="...">, use a normal <input type="submit"> and hook into the form's submit event. That way:

    • It works when JavaScript is unavailable.
    • It works when there's a problem in your code.
    • It works when you find you can't do something halfway through processing the event (e.g. you find that ActiveX is switched off in Internet Explorer, making XMLHttpRequest unavailable).
  • Re:Saving AJAX (Score:4, Insightful)

    by liquidpele ( 663430 ) on Friday August 04, 2006 @03:49PM (#15848464) Journal
    I have 2 functions: setSVAL(key,value) and setDVAL(option,value) the SVAL calls a php library that simply sets a session variable for the user to some value. This can be used to save settings you want reloaded when the page reloads. The DVAL calls a php library that checks the option, and then inserts the value into a specific section of the database so that the user can save settings there without reloading the page. These seem to work pretty well for me anyways, but others will save all the data into some format as a cookie that can be read by both the server and the javascript which is probably the easier solution for very large apps. My main problem with AJAX: submitting a form without reloading the page! Any easy way to do that?
  • by catbutt ( 469582 ) on Friday August 04, 2006 @03:57PM (#15848512)
    Are you suggesting that it didn't occur to those who created XMLHttpRequest how it might be used?

    I think it was far more a case of it taking a while for someone to make a compelling enough application using it for it to get public acceptance and attention from mainstream developers. And probably a bit of reluctance to go down that path until a large enough percentage of users had a browser that supported it to make it make economic sense to invest in the use of such techniques on a large scale.
  • by IGnatius T Foobar ( 4328 ) on Friday August 04, 2006 @04:05PM (#15848575) Homepage Journal
    Nobody calls XmlHttpRequest() directly anymore. It's too much work, and there are slight differences between browser implementations. Nowadays everyone is using a wrapper library. Prototype [conio.net] is a very common one (it's certainly my favorite) -- abstracts everything into a nice set of functions for you -- you just specify the HTTP call you want to make, and the function you want it to call when the data comes back (because, in case you're not already aware, XmlHttpRequest() returns its data asynchronously).

    The other nice thing you can do with Prototype is to avoid XML parsing altogether by saying "ok, here's the URL I want you to call; it's going to return pre-rendered HTML, and when it does, I want you to stick it in this DIV over here; don't bother me about it" and you can do things like automatically update portions of your page without reloading. You can even have an automatically recurring update, which is very cool for things like tickers, clocks, etc. We used it in our AJAX webmail/calendar system and it really worked well.
  • by richdun ( 672214 ) on Friday August 04, 2006 @04:08PM (#15848591)
    Bandwidth ain't _that_ cheap. A constant connection would be annoying to maintain in spotting wifi, electrical storms, etc.

    I personally prefer web development because of the forced finite life of each state. That sort of back and forth makes data validation, cross-process security, and other things that many web developers ignore very easy to implement. You just have to quit thinking continuously (rimshot please!) and start thinking discretely.
  • by big_a ( 112626 ) on Friday August 04, 2006 @04:10PM (#15848601) Homepage
    One strike against AJAX is that search engines won't be able to see any of your 'dynamic' content. Sure, you can code around it by providing static links to the same content, but it's something to keep in mind.
  • by Anonymous Coward on Friday August 04, 2006 @04:17PM (#15848649)

    Beyond the XMLHTTP Request object, which has been around for several years as a solution looking for a problem...

    Outlook Web Access, genius. That's the problem Microsoft made it to solve.

  • by baadger ( 764884 ) on Friday August 04, 2006 @04:17PM (#15848650)
    Better question, do you really want to be at the server end of a slashdotting consisting of persistent connections?
  • by Chunt620 ( 897724 ) on Friday August 04, 2006 @04:25PM (#15848693)
    Development using Visual Studio has little to do with being a man and alot to do with wanting to complete projects within a reasonable timeframe. As a former PHP-lifer turned Visual Studio lover, I can attest to the fact that Visual Studio WILL cut your time to release numbers significantly/
  • by suggsjc ( 726146 ) on Friday August 04, 2006 @04:28PM (#15848710) Homepage
    The real questions are:
    1. What do we want the web to be?
    2. What role will HTTP play in the answer to #1
    3. If the answer to #2 is fall by the wayside, then who is going to create its succesor?
    4. Then, after the answer to #3 is figured out...do you really want to be at the server end of that connection?
  • by IGnatius T Foobar ( 4328 ) on Friday August 04, 2006 @04:34PM (#15848742) Homepage Journal
    What does that do that this doesn't (other than use a pretty wrapped package)?

    Well, for one thing, where you wrote 16 lines of code, doing the same thing in Prototype would have taken 1 line of code. Isn't that the point of wrapper libraries? To make repetitive, commonly used tasks like this one more convenient? (Not to mention, the 1-line Prototype call would also work in IE5 and FF1.0)

  • by roman_mir ( 125474 ) on Friday August 04, 2006 @05:20PM (#15848981) Homepage Journal
    because, in case you're not already aware, XmlHttpRequest() returns its data asynchronously - that's what you get for not getting into the details of implementation and for always using some libraries to do things for you. It is possible to make synchronous and asynchronous calls with XmlHttpRequest.
  • by God of Lemmings ( 455435 ) on Friday August 04, 2006 @06:02PM (#15849199)
    Hacks to keep a connection alive? Over TCP/IP, a connection based protocol?! No, really?!

    I am not certain that it is time to update the HTTP spec so much as to come up with an
    accompanying spec for connection based browser communication before microsoft does.

    Something similar to xmlHTTPrequest, but something that can maintain a symmetrical
    connection that HTTP is not designed for.

    I dunno, maybe something vaguely like this: (and i stress vaguely)

    <script type="text/javascript">
            var server = new host ("");
            var state = "michigan";
            document.write(" The capital of "+state+" is "+host.recv()+"<br>" );
            document.write(" The population of "+state+" is "+host.recv()+"<br>" );
  • by telbij ( 465356 ) * on Friday August 04, 2006 @06:35PM (#15849369)
    No doubt man! Where's his editor?

    This is worse than half the stuff in my freshman comp class at community college. You don't even have to be a writer to improve this, just cut out half the words. Someone ought to introduce him to the technique of reading his writing out loud.

    Take this gem of a paragraph:

    This leads to the question of how, short of the whole kites and Igor methodology, does one accomplish this unholy task? The answer is that it depends on just how and how far one wants to pursue this course. There are three ways to bring life to an AJAX application, and each has its own advantages and disadvantages. It all depends on just which parts of the AJAX tool set the developers are comfortable with. It also depends on how comfortable you are with excluding certain members of the planet from the application. Yes, I'm talking about those people who are still running Internet Explorer Version 2.0. Fortunately, it isn't my job to issue decrees concerning browser compatibility; however, it is my job to cover how to implement an AJAX application.

    Not only does every sentence sound horrible on its own, but the whole paragraph communicates nothing at all. Well I guess it claims that there are three ways to do AJAX, but that's a pretty useless little factoid if you're not going to say what they are.

    I can't decide whether I'm embarassed for him or inspired to write a book of my own.
  • next.... (Score:3, Insightful)

    by burnin1965 ( 535071 ) on Friday August 04, 2006 @07:00PM (#15849471) Homepage
    After reading through five pages it all ended at "var dom = new ActiveXObject(......"

    No thanks, next book please.

  • Re:Saving AJAX (Score:3, Insightful)

    by misleb ( 129952 ) on Friday August 04, 2006 @07:32PM (#15849622)
    It really depends on just how much you rely on AJAX. If you have just a single page which contains all the possible controls and functionality of your whole app, it can be quite complicated. If you just have a few ajax controls here and there and a unique HTML page for each major section, controls usually get drawn based on some database or session value so it pretty much takes care of itself. Just make sure that your ajax calls modify the screen in exactly the same way that loading the URL for the first time would.

    Where you get into trouble is when you start relying on non HTML "widgets" for controls that are drawn and managed by javascript rather than rendered by the server. I would tend to avoid this unless you have a framework that takes care of all the "state" information for you. Problem is that those frameworks can be pretty heavy and slow.

    The biggest problem with sites that overutilize AJAX is that they are difficult to bookmark. Users often want to bookmark parts of a site or send URLs to friends. If all of your app/site resides in a single page/url, nobody can link into it. This can be a bonus for people who wnat to prevent deep linking, but I think most users benefit from deep linking.

    What it comes down to is: It depends.

    Do you have a particular language/framework/application in mind?

  • by Not The Real Me ( 538784 ) on Saturday August 05, 2006 @01:01AM (#15850843)
    "ATLAS is a cross-browser AJAX framework, and Visual Studio 2005 produces valid, meaningful XHTML."

    More important, will the final product run on a non-Microsoft web server?

Never buy from a rich salesman. -- Goldenstern