Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

So How Do You Code an AJAX Web Page? 231

Posted by Zonk from the hard-work dept.
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? More

So How Do You Code an AJAX Web Page?

Comments Filter:

  • finishing the thought... (Score:5, Funny)

    by User 956 ( 568564 ) on Friday August 04, 2006 @03:18PM (#15848255) Homepage
    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.

    But more importantly, one needs to remember that the internet is not a big truck, that you can dump information on. It's a series of tubes.

  • So How Do You Code an AJAX Web Page? (Score:5, Informative)

    by Anonymous Coward on Friday August 04, 2006 @03:21PM (#15848274)
    1. Open Visual Studio
    2. Download and install the ATLAS framework
    3. Wrap your webpage in an update panel
    4. Add a script manager
    5. Lather, rinse, and repeat

    Seriously...one drag-and-drop and you'll never see another page refresh.
    • That is correct. 10 minutes of work and you too can name your site wixi, plexxy, swiggle, gippy.......[insert "trendy" web 2.0 names here]
    • You forgot step zero: Download the free version of Visual Studio Express [microsoft.com].

      And in the interest of full-disclosure, I recently started working for Microsoft on Visual Studio features directly related to AJAX and ATLAS. So now this post is just ordinary spam instead of a sneaky shill.
    • Shhhhhhhhh

      I have everyone convinced I'm a leet AJAX programmer after I dragged in a single UpdatePanel on my company's internal web app.

      You're going to ruin it for everyone. Keep quiet!
    • 6. Gasp at your bandwidth bills when you realize that you had to include an 84k JS file for a simple "hello world" application.
      7. Spend hours trying to figure out why any custom script files you want to include in your head element once you try to do something non-trivial mysteriously aren't working.

  • Printer Friendly (Score:5, Informative)

    by neonprimetime ( 528653 ) on Friday August 04, 2006 @03:22PM (#15848277)
    Instead of wading thru 7+ pages of clicking and ads ... Printer Friendly version [computerworld.com]. You can thank me later.
  • ...but slashdot keeps blocking it with a "lameness" filter, insisting it's "junk characters". Go figure, I didn't know slashdot was anti-web 2.0!
  • With the growing popularity of AJAX does anyone think it's time to update the HTTP spec? AJAX is cool tech but still hindered by the fact that the client has to initiate every request. Yes, there are ugly hacks to keep a connection alive, but it is exactly that, a hack, and introduces problems of it's own.
    • I can see both sides of the argument, but do you really want a two-way connection through your browser?
      • I assume you are indicating that it may be a security issue on the client side, but I don't see it allowing for any more malicious activity than there already is. The onLoad tag of the body element can fire up an XMLHTTPRequest that gets a response from the server automatically. This would be no different than the server polling the client if such a connection were possible. I think it would be more of a performance issue on the server end, having to host so many live connections.
      • Better question, do you really want to be at the server end of a slashdotting consisting of persistent connections?
        • 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?

    • Re:HTTP, time to update? (Score:4, Informative)

      by Civil_Disobedient ( 261825 ) on Friday August 04, 2006 @03:47PM (#15848456)
      Yes, there are ugly hacks to keep a connection alive, but it is exactly that, a hack, and introduces problems of it's own.

      There are some ugly hacks to allow the server to "push" to the client (embedded flash objects, never-closed-connections, etc.)--mostly encapsulated by the moniker COMET [ajaxian.com] (get it? Ajax... Comet...)

      But if you get to pick your app server, there are some ready-made solutions. The problem with traditional web servers is their IO method. It's not their fault that the HTTP spec is out-of-date, but there are already new developments on the horizon that get around the current limitations. Take a look at GlassFish [java.net], Sun's new open-source enterprise application server, and pay particular attention to NIO [sun.com] socket writes. The performance benefits of NIO over straight IO are astonishing [java.net], with the side-benefit that it supports server-push out-of-the-box.

    • Re:HTTP, time to update? (Score:5, Insightful)

      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.
    • I think the more limiting issue is that it is so hard to do AJAX across domains. XMLHttpRequest doesn't work, nor do hidden iframes. I think no one has put too much thought into what the potential of this is if it could be done.

      However, they appear be building something at Ajaxlets.com [ajaxlets.com] that is supposedly a clean, open source solution to this, by packetizing the data in javascript script urls. Apparently their release is a few days off.

      • I think the more limiting issue is that it is so hard to do AJAX across domains. XMLHttpRequest doesn't work, nor do hidden iframes.

        Not true - there's a trick to get around iframe cross-domain security. You can still see the URIs of the frame. This means that the domain you are attempting to access can supply a special page that calls XMLHttpRequest on your behalf and streams the data to you by updating the fragment identifier.

        It's an awful hack, but it's been wrapped up in an XMLHttpRequest emul [dojotoolkit.org]

    • 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">

  • Both Repetitive and Redundant (Score:5, Funny)

    by Stringer Bell ( 989985 ) on Friday August 04, 2006 @03:35PM (#15848362)

    Woychowsky repeats himself a lot. What's more, he says the same things over and over. In other words, he'll say something, and then re-phrase it with almost exactly the same words.

    As I've mentioned, he seems to keep repeating himself

    • Re:Both Repetitive and Redundant (Score:4, Insightful)

      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.
  • If you are an AJAX coder from the darkside, then this [yahoo.com] is for you.

    Notable quote "Ajax has introduced a huge attack surface"

  • Start by not putting a tag in your title :) tag (Score:5, Funny)

    by dindi ( 78034 ) on Friday August 04, 2006 @03:35PM (#15848366)
    title So how (i) do (/i) you code an AJAX Web page? /title

    Haha, i mean, start ptocessing XML like this with Java and we will have a lot of browsers falling on their asses with exceptions :))))))

    OK I am cruel!

  • 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?

    • Comment removed (Score:4, Insightful)

      by account_deleted ( 4530225 ) on Friday August 04, 2006 @03:49PM (#15848464)
      Comment removed based on user account deletion

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

        by Mateo_LeFou ( 859634 )
        'submitting a form without reloading the page! Any easy way to do that?' I must've misunderstood the question but can't you just do an image submit button with onClick=sendFormStufftoPHPScriptThatDoesWhatever() using the xmlhttpreq object?
        • Comment removed based on user account deletion

        • Re:Saving AJAX (Score:2, Informative)

          by jozeph78 ( 895503 )
          'submitting a form without reloading the page! Any easy way to do that?' I must've misunderstood the question but can't you just do an image submit button with onClick=sendFormStufftoPHPScriptThatDoesWhatever( ) using the xmlhttpreq object?

          Very simple when using prototype javascript library.

          function submitForm(form) {
          new Ajax.Request("comment.php", {
          parameters : Form.serialize(form),
          onSuccess : updateComment
          });
          }

      • Submitting a form is simple, use a post datastring in the object.send() line - and set it to 'post' not 'get' in the open statement.
      • My main problem with AJAX: submitting a form without reloading the page! Any easy way to do that?

        If you're not opposed to using a framework, use Ajax.Updater [aculo.us] from script.aculo.us

      • "My main problem with AJAX: submitting a form without reloading the page! Any easy way to do that?"

        Process form. Send the following header back to the browser:

        # Perl
        print "HTTP/1.0 204 No Content\n\n"; exit(0);

        # php
        <?php
        header("HTTP/1.0 204 No Content");
        ?>

    • Re:Saving AJAX (Score:5, Funny)

      by crabpeople ( 720852 ) on Friday August 04, 2006 @03:49PM (#15848465) Journal
      prt scr

    • How do I save an AJAX page in a given state

      Set up variables as parameters in the URL that hold the state (for bookmarking). If you can control your form values, throw in some hidden fields that hold the info on page load. If the values are empty, the ajax request uses the default, otherwise is preloads your values.

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

      by misleb ( 129952 )
      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 ti
    • Man look at these people go with all these solutions. Parent poster clarified and said as a consumer of a webpage- The viewer! This is a good question and the way I do it is with the Firefox "Web Developer" extension. Then all you have to do is right click, go to Web Developer > View Source > View Generated Source.

  • 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>

    <title>HTMLfs</title>
    </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).
    • There is nothing wrong with the HTML button element (well, except that MSIE doesn't understand completely).

      <button type="submit" onclick="doAjaxStuff(); return false;">submit my input</button>

      works perfectly and is far superior to the lousy <input type="submit" value="submit my input" /> variant.

      • Sorry, I wasn't very clear there. My problem isn't simply with <button> (although <input type="submit"> is better supported by browsers, which is critical, and it submits the wrong data in Internet Explorer as you point out), but rather that practically everybody who uses it uses it instead of the mandatory action attribute on the <form> element - in essence, throwing away the HTML functionality and replacing it with less compatible JavaScript. I've simply never seen anybody use <but

    • 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

      Without knowing really your level of experience in designing dynamic AJAX-driven sites, I can say at least this coment in particular is complete bunk. For one, hooking

      • For one, hooking into the 'onsubmit' form event is a recipie for disaster - the event behaves entirely unpredictably across different browsers. Some allow you to cancel it, some don't, others only in certain situations.

        Which browsers would these be? I find that the submit event can be reliably cancelled if you take into account a) DOM-capable browsers, b) Internet Explorer, and c) other old-fashioned browsers. There's three different ways of cancelling an event, are you sure you aren't forgetting on

  • There are much better intros to Ajax (Score:5, Informative)

    by njdj ( 458173 ) on Friday August 04, 2006 @03:38PM (#15848389)

    The article is very verbose. It has some value, I suppose - it helped me to decide I didn't want to buy the book. There are more concise introductions to Ajax here [www.xul.fr] and here [mozilla.org]

    There is also an interesting library of Javascript/ECMAscript functions to perform common Ajax chores here [sourceforge.net]

  • If your a Java coder Icesoft has a great AJAX framework icefaces [icesoft.com].

  • Use Echo2 (Score:5, Informative)

    by Mock ( 29603 ) on Friday August 04, 2006 @03:46PM (#15848448)
    1. Download Echo2 http://nextapp.com/platform/echo2/echo/ [nextapp.com]
    2. Write AJAX applications like you would a Swing app, never touching HTML or Javascript.
    3. Go outside and play.

    'nuff said.
    • That's pretty cool. Here's their demo [nextapp.com]. After clicking through this, I have to say: for all the mockery of "Web 2.0" around here, there is a HUGE change from 10 years ago (writing static pages in html) to this demo (writing what appear to be fairly normal applications in Java, where supposedly the developer avoids the grab-bag of "web technologies" altogether). I realize the exact choice of when to use a new major version number is somewhat arbitrary, but things really have changed. Too bad it's almost i

    • Re:Use Echo2 (Score:3, Interesting)

      by master_p ( 608214 )
      I have been developing an intranet application with Echo2 for 3 months now. Although the concept is great, it takes a lot (and I mean A LOT) of effort to write the GUI using Echo2:

      1) the Eclipse plugin is shareware. Since the project I am doing is small, no extra expenses were allowed, so I did everything manually.

      2) the widgets are minimal, to say the least. The core library contains very few widgets (button, label, text field, text area, table, grid, row, column, splitpane, windowpane). You have to downlo
  • I'm no expert when it comes to coding up a web page. The page I'm responsible for in my little corner of my organization I just update with straight HTML edits in notepad. I can't vouch for the technical expertise of this author but I for one appreciate technical material that is easy to read and God forbid, a pleasant experience.

    What is AJAX?

    As stated previously, AJAX stands for Asynchronous JavaScript And XML, but what exactly does that mean? Is the developer limited to only those technologies named?

  • Solution looking for a problem? (Score:3, Insightful)

    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.

  • Nobody calls XmlHttpRequest() directly anymore (Score:5, Insightful)

    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.

    • Re:Nobody calls XmlHttpRequest() directly anymore (Score:4, Informative)

      by richdun ( 672214 ) on Friday August 04, 2006 @04:26PM (#15848697)
      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.

      What does that do that this doesn't (other than use a pretty wrapped package)? This is the general form I use for my AJAX requests. If needed, I add some checking to cancel previous requests to the same method or queue successive calls so that the race for responses doesn't screw me up. It seems to work in all browsers I test for (IE6, FF 1.5+, Opera 9+, Safari 2+...and yes, I force my users to use modern browsers).

      if (window.XMLHttpRequest) {
              var oHttpRequest= new XMLHttpRequest();
      }
      else if (window.ActiveXObject) {
                      var oHttpRequest = new ActiveXObject("Microsoft.XMLHTTP");
      }

      function ajaxCall (page,params,responseHolder) {
              oHttpRequest.onreadystatechange=function()
                      if(oHttpRequest.readyState==4) {
                              document.getElementById(responseHolder).innerHTML = oHttpRequest.responseText;
                      }
              }

              oHttpRequest.open("POST",page,true);
              oHttpRequest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
              oHttpRequest.send(params);
      }
      • 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)

        • Isn't that the point of wrapper libraries? To make repetitive, commonly used tasks like this one more convenient?

          Absolutely. I just consider myself still in the learning phase of the AJAX part of my web apps (good with PHP, good with XHTML/CSS, not so great with advanced Javascript), so I like to do some of the common repetitive things so I'm not doing a typical plug and chug job at coding without understanding well what's going on underneath. It's mostly just for my own benefit - I see too many jump into
      • What does that do that this doesn't

        Works with XHTML.

        • Actually, that does work with XHTML if you have the PHP (or whatever) file properly construct the responseText and throw it into a
          as the responseHolder. I mean, it doesn't actually know that it is XHTML, but it still works as such (i.e., applies stylesheets, validates, etc.)
    • 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.

    • Re:Nobody calls XmlHttpRequest() directly anymore (Score:4, Informative)

      by leighklotz ( 192300 ) on Friday August 04, 2006 @05:48PM (#15849122) Homepage
      One good mechanism for getting the XML and asynchronous features but without hand coding JavaScript is to use any of the various XForms implementations. XForms is a W3C standard that defines a mostly script-free way of doing much of stuff people want out of Ajax, and it's done in a declarative way that's friendly to accessibility agents, and easier to deploy onto other devices. I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms [w3.org]

      The FormFaces [formfaces.com] OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.

      Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/ [sourceforge.net]

      I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba [sourceforge.net], another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.

      Another important option is the work that the Mozilla Foundation and IBM are doing to make a native implementation of XForms as an XPI for Firefox and Mozilla. See http://www.mozilla.org/projects/xforms/ [mozilla.org] -- they're now in version 0.6, with 1.0 targeting full XForms 1.0 compliance. Like all other Mozilla extensions, it's a 1-click install, and I think it's about 200KB, so it's not very big, and I hope it gets added to the default build after it reaches 1.0. (It's presently built with the nightlies.)

      There are a number of other implementations, including browser plugins (FormsPlayer [formsplayer.com] for IE), native implementations for embedded devices such as cellphones and kiosks (PicoForms [picoforms.com], SolidForms [sourceforge.net], and entire server-side systems using XForms, such as Orbeon Ops [orbeon.com], so I see an increasingly bright future for using XForms to build dynamic HTML interfaces on top of XML web services and deploy them across a range of devices.

  • AJAX and Search Engines (Score:2, Insightful)

    by big_a ( 112626 )
    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.

  • Not Magic (Score:3, Informative)

    by MattW ( 97290 ) <matt@ender.com> on Friday August 04, 2006 @04:13PM (#15848623) Homepage
    We didn't really even need xmlhttprequest; you could use iframes, too. (And some notable "2.0" apps have)

    Useful bits I've found getting into ajax stuff:

    Dojo Toolkit [dojotoolkit.org], a nifty framework for doing all sorts of good stuff. Of particular note to me was dojo.io.* with its dojo.io.bind() function, which provides a simple, cross-platform compatible way to do an xmlhttprequest, with callback functions for completion and errors, an easy way to post variables, specify a method and caching, etc.

    openrico [openrico.org]. This provides all sorts of fun stuff. The smart stuff starts with declaring $ as a function, which after you get used to it provides a very convenient cross-platform way to access DOM nodes (ie, $('mydiv') or $(divvar)), and has all sorts of canned widgets for effects, like accordian widgets, move&resize, etc... although I've found practical application usually requires a bit more additional work, but their functions help get started.

  • Cred went to zero in the summary (Score:3, Interesting)

    by YU Nicks NE Way ( 129084 ) on Friday August 04, 2006 @04:31PM (#15848723)
    the XMLHTTP Request object, which has been around for several years as a solution looking for a problem, there is nothing weird needed
    OK, so this guy doesn't even know that HttpRequest was added to MSXML to allow OWA 2000 -- you know, the first Ajax client -- to work. SOunds like he's got some technical issues to work through first.

  • Speaking of AJAX... (Score:5, Interesting)

    by Chabil Ha' ( 875116 ) on Friday August 04, 2006 @04:53PM (#15848844)
    Why doesn't Slashdot implement it? This would be especially nice for expanding/collapsing in the discussions.

  • Ajax + Risk = Grand Strategy (Score:4, Interesting)

    by bryanbrunton ( 262081 ) on Friday August 04, 2006 @05:41PM (#15849085)
    I recently published my first Ajax application. It is an online game called Grand Strategy, a close of the well known board game Risk.

    It is by far the most advanced Ajax based implementation of a board game to have ever been written!

    I used Direct Web Remoting (DWR) and the Dojo Toolkit. My javascript talks to my server side java beans directly. It's really the easiest web programming model I have ever seen. I hurts to go back to doing ASPX and PHP pages after this.

    Check it out here:

    http://denizengames.com/grandstrategy/ [denizengames.com]

  • 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.

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close