Slashdot Mirror


So How Do You Code an AJAX Web Page?

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.'"

56 of 231 comments (clear)

  1. finishing the thought... by User+956 · · Score: 5, Funny

    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.

    --
    The theory of relativity doesn't work right in Arkansas.
    1. Re:finishing the thought... by __aaclcg7560 · · Score: 2, Interesting

      It's a series of tubes.

      You got it all wrong about the tubes, my friend. :P

  2. So How Do You Code an AJAX Web Page? by Anonymous Coward · · Score: 5, Informative

    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.

    1. Re:So How Do You Code an AJAX Web Page? by Chunt620 · · Score: 3, Funny

      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]

    2. Re:So How Do You Code an AJAX Web Page? by Anonymous Coward · · Score: 3, Informative
      Replace "So How Do You Code an AJAX Web Page?" with "So How Do You Code an AJAX Web Page for IE only?" and your comment is correct.
      ATLAS is a cross-browser AJAX framework, and Visual Studio 2005 produces valid, meaningful XHTML.

      Nice troll, though.
    3. Re:So How Do You Code an AJAX Web Page? by vux984 · · Score: 3, Informative

      /shrug

      Visual Studio actually has a pretty solid source code editor, with good syntax highlighting, and its code completion for css properties and html attributes is very good. (And its ability to offer effortless code completion for asp tags, AND user-defined controls is extremely helpful.) Not to mention its real-time "error" checking (improper tag nesting, mismatched tags, etc). It prevents and catches a lot of potential errors as you make them.

      I do agree that doing a lot of work in the gui-designer results in bloated pages that need a ton of work to slim down and make crossplatform friendly. But nobody is forcing you to do that, and really if you know what you are doing you almost never use the visual designer mode. I only use it to drag user-controls onto the page; because in gui-mode it handles the boilerplate to register the tagprefix, etc. I also occasionally use it to create event handlers, because double clicking say a linkbutton in design view will write the boilerplate for the function signature, as well as handle the event wiring.

      Like any tool, Visual Studio can be used effectively or ineffectively. When compared to most other "light tools" I find Visual Studio to be more productive -- sure I can build pages even in notepad but I make fewer typos when using the source code editor in Visual studio.

      (There are other good editors too, don't get me wrong. I'm just saying that visual studio belongs among them.)

    4. Re:So How Do You Code an AJAX Web Page? by Chunt620 · · Score: 2, Insightful

      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/

    5. Re:So How Do You Code an AJAX Web Page? by Anonymous Coward · · Score: 4, Funny

      [insert "trendy" web 2.0 names here]

      shitty

    6. Re:So How Do You Code an AJAX Web Page? by naoursla · · Score: 2, Informative

      You forgot step zero: Download the free version of Visual Studio Express.

      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.

    7. Re:So How Do You Code an AJAX Web Page? by CastrTroy · · Score: 3, Interesting

      Light Tools? What are you talking about. My current copy of Visual Studio is eating up 290 Megs for RAM. I will go with you on your opinion though. VS.Net is a great tool, and probably one of the best editors I've ever seen. The bad part is that it's hidden behind the drag and drop interface that it presents. MS tools get you to focus on the GUI, and don't make you get underneath to understand what's going on. This leads to a lot of programmers who can get their way around VS easily enough, and even write some good programs, but as soon as they need to do something that visual studio didn't expect, they have a really hard time.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    8. Re:So How Do You Code an AJAX Web Page? by Anamanaman · · Score: 3, Funny

      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!

    9. Re:So How Do You Code an AJAX Web Page? by naoursla · · Score: 4, Informative

      I would never describe myself as a graphic artist so I will neither agree nor disagree with you.

      However, for the web impaired here is a direct link for the web developer version only (which you can get to by clicking the big download picture on the right hand side of each product specific page and then clicking "Download" in step 2).

      And as long as I am providing overly simple instructions to trolls, I guess I'll point out that ATLAS does not come installed with Visual Studio. You have to download it from atlas.asp.net (hint: there is a big download icon at the top of the screen).

      And if you would like a demo of how easy it is to create ajax applications with atlas, there is current a video on the front page of someone creating a database backed todo-list application in 18 minutes (the express version of Visual Studio comes with a lightweight database and web server for development. I think you can probably repeat this demo with the free tools).

    10. Re:So How Do You Code an AJAX Web Page? by misleb · · Score: 3, Funny
      It prevents and catches a lot of potential errors as you make them.


      Man, I hate it when I make potential errors. How does VS deal with virtual errors?

      -matthew
      --
      "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
    11. Re:So How Do You Code an AJAX Web Page? by Not+The+Real+Me · · Score: 2, Insightful

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

  3. Printer Friendly by neonprimetime · · Score: 4, Informative

    Instead of wading thru 7+ pages of clicking and ads ... Printer Friendly version. You can thank me later.

  4. HTTP, time to update? by not+already+in+use · · Score: 2, Interesting

    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.

    --
    Similes are like metaphors
    1. Re:HTTP, time to update? by suggsjc · · Score: 3, Interesting

      I can see both sides of the argument, but do you really want a two-way connection through your browser?

      --
      When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
    2. Re:HTTP, time to update? by not+already+in+use · · Score: 2, Informative

      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.

      --
      Similes are like metaphors
    3. Re:HTTP, time to update? by Civil_Disobedient · · Score: 3, Informative

      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 (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, Sun's new open-source enterprise application server, and pay particular attention to NIO socket writes. The performance benefits of NIO over straight IO are astonishing, with the side-benefit that it supports server-push out-of-the-box.

    4. Re:HTTP, time to update? by richdun · · Score: 4, Insightful

      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.

    5. Re:HTTP, time to update? by catbutt · · Score: 2, Interesting

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

    6. Re:HTTP, time to update? by baadger · · Score: 2, Insightful

      Better question, do you really want to be at the server end of a slashdotting consisting of persistent connections?

    7. Re:HTTP, time to update? by suggsjc · · Score: 3, Insightful
      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?
      --
      When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
    8. Re:HTTP, time to update? by God+of+Lemmings · · Score: 2, Insightful

      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 ("192.168.2.3");
              var state = "michigan";
              host.connect();
              host.send("query.php?capitalof="+state);
              document.write(" The capital of "+state+" is "+host.recv()+"<br>" );
              host.send("query.php?populationof="+state);
              document.write(" The population of "+state+" is "+host.recv()+"<br>" );
              host.close();
      </script>

      --
      Non sequitur: Your facts are uncoordinated.
  5. Both Repetitive and Redundant by Stringer+Bell · · Score: 5, Funny

    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

    1. Re:Both Repetitive and Redundant by telbij · · Score: 3, Insightful
      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.
  6. Start by not putting a tag in your title :) tag by dindi · · Score: 4, Funny

    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!

  7. Saving AJAX by Doc+Ruby · · Score: 4, Insightful

    How do I save an AJAX page in a given state, rather than just a state that will be "rebooted" on reload from storage?

    --

    --
    make install -not war

    1. Re:Saving AJAX by crabpeople · · Score: 4, Funny

      prt scr

      --
      I'll just use my special getting high powers one more time...
    2. Re:Saving AJAX by Mateo_LeFou · · Score: 2, Informative

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

      --
      My turnips listen for the soft cry of your love
    3. Re:Saving AJAX by jozeph78 · · Score: 2, Informative
      '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
      });
      }

      --
      Ever done a `man` on `top` ?
    4. Re:Saving AJAX by misleb · · Score: 2, Insightful

      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?

      -matthew

      --
      "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
  8. Huh by Bogtha · · Score: 5, Insightful

    Print version here.

    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).
    • 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).
    --
    Bogtha Bogtha Bogtha
  9. There are much better intros to Ajax by njdj · · Score: 5, Informative

    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 and here

    There is also an interesting library of Javascript/ECMAscript functions to perform common Ajax chores here

    1. Re:There are much better intros to Ajax by supun · · Score: 2, Informative

      I like Sarissa, but have moved onto using Dojo http://dojotoolkit.org/ due to it's friendlyness to JSON. Much easier accessing a returned object that walking the DOM.

      --
      :w!
  10. Use Echo2 by Mock · · Score: 4, Informative

    1. Download Echo2 http://nextapp.com/platform/echo2/echo/
    2. Write AJAX applications like you would a Swing app, never touching HTML or Javascript.
    3. Go outside and play.

    'nuff said.

    1. Re:Use Echo2 by master_p · · Score: 2, Interesting

      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 download an extras library.

      3) the widgets' look and feel is 'black text and white background'. You have to manually specify the visual output for all states of each widget. For example, you have to specify, for the button, the background color, border, font color for each of the disabled, enabled and selected states.

      4) The above is somehow solved with styles provided in XML. But this part of the library is totally undocumented. I mean there is not a single line of documentation of how the XML style files should be. I posted the relevant question in their forum and they said to look at the examples.

      5) The GUI is single-threaded (each connection has its own thread). If you want to add something to a model from another thread, you have to write a task which will be executed in each client's message queue. Which means that you either make new models which are synchronized or each client maintains different model instances for the same data...which means a huge waste of memory.

      6) geometry management is weird, to say the least. Many components do not autosize themselves to the available space of their containers or have weird constraints. You have to use splitpanes for most tasks, but they have some severe drawbacks: panes can not be children of non-panes.

      7) widgets are pretty limited in functionality. For example, there is no way to scroll a text area content to the last line in order to simulate a command prompt window, for example.

      8) there are maybe some weird bugs in it. Some times the communication between browser and server freezes, even if both are on the same machine.

      9) data validation on the client is not existent. You just accept whatever the client sends you.

      Overall, Echo2 is pretty average...the concept of 'all Java' is great and saves you a lot of trouble...but I think Echo2 needs a great deal of work to make it really good.

      What I would like to see is Java bytecodes be translated to ecmascript and run on the client. That would save many hours of coding, as well as make applications much faster and nicer. For example, I would like to write a data validation routine in Java, and I want this routine to be translated to javascript and executed on the client side, thus not needing to get back to the server and bog down the network.

  11. Comment removed by account_deleted · · Score: 3, Insightful

    Comment removed based on user account deletion

  12. Re:I'd post my 20-line AJAX function... by DigitalRaptor · · Score: 2, Funny

    Slashdot isn't anti Web 2.0, it's dissing your code... calling it lame garbage.

    But don't take it personally.

    --
    Lose Weight and Feel Great with Isagenix
  13. Solution looking for a problem? by catbutt · · Score: 2, Insightful

    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.

  14. Nobody calls XmlHttpRequest() directly anymore by IGnatius+T+Foobar · · Score: 4, Insightful

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

    --
    Tired of FB/Google censorship? Visit UNCENSORED!
    1. Re:Nobody calls XmlHttpRequest() directly anymore by richdun · · Score: 3, Informative

      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);
      }

    2. Re:Nobody calls XmlHttpRequest() directly anymore by IGnatius+T+Foobar · · Score: 2, Insightful
      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)

      --
      Tired of FB/Google censorship? Visit UNCENSORED!
    3. Re:Nobody calls XmlHttpRequest() directly anymore by roman_mir · · Score: 2, Insightful

      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.

    4. Re:Nobody calls XmlHttpRequest() directly anymore by leighklotz · · Score: 3, Informative

      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

      The FormFaces 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/

      I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, 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/ -- 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 for IE), native implementations for embedded devices such as cellphones and kiosks (PicoForms, SolidForms, and entire server-side systems using XForms, such as Orbeon Ops, 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.

  15. AJAX and Search Engines by big_a · · Score: 2, Insightful

    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.

  16. Not Magic by MattW · · Score: 2, Informative

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

  17. Re:Well, first things first... by dpreston · · Score: 2, Funny

    Try...

    $ vi <enter>

  18. Cred went to zero in the summary by YU+Nicks+NE+Way · · Score: 2, Interesting
    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.
  19. Oh yeah? by The_REAL_DZA · · Score: 5, Funny
    AJAX is a joke

    Slashdot is a joke

    You are a joke

    Really? Then why doesn't it say "+5 Funny" on my shirt?
    --


    This space intentionally left (almost) blank.
  20. Speaking of AJAX... by Chabil+Ha' · · Score: 5, Interesting

    Why doesn't Slashdot implement it? This would be especially nice for expanding/collapsing in the discussions.

    --
    We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
    1. Re:Speaking of AJAX... by spencer1 · · Score: 5, Informative

      Slashdot is currently testing just that among a small group over users. http://slashdot.org/faq/com-mod.shtml#cm120

  21. Ajax + Risk = Grand Strategy by bryanbrunton · · Score: 3, Interesting

    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/

  22. next.... by burnin1965 · · Score: 2, Insightful

    After reading through five pages it all ended at "var dom = new ActiveXObject(......"

    No thanks, next book please.

  23. Re:Time to put up or shut up by Bogtha · · Score: 2, Informative

    Give us a simple, complete page that uses AJAX and is still compatible with non-AJAX browsers.

    Off the top of my head: Google Suggest. The same page offers enhanced Ajax functionality and still works in Lynx, without any need for two pages or radically different layouts.

    The ways you make Ajax work in a backwards-compatible manner are the same techniques decent JavaScript developers have been using for years. Unfortunately, not a lot of people are aware of JavaScript best practices and the field is still dominated by people who concentrate on making it work in their favourite browser and then bodging it to work elsewhere, rather than starting from a good solid design and enhancing it in a structurally sound manner.

    If you're interested in learning more, I suggest DOM Scripting and the DOM Scripting Task Force website as decent starting points. I haven't read the book, but I've heard a lot of good things about it from people who know what they are talking about.

    --
    Bogtha Bogtha Bogtha
  24. Re:Well, first things first... by Millenniumman · · Score: 3, Funny

    Command line interfaces are for n00bs. I use a magnet to change each byte on my hard drive.

    --
    Stupidity is like nuclear power, it can be used for good or evil. And you don't want to get any on you.