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.'"
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.
Instead of wading thru 7+ pages of clicking and ads ... Printer Friendly version. You can thank me later.
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. 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.
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
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.
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.
'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
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);
}
Slashdot is currently testing just that among a small group over users. http://slashdot.org/faq/com-mod.shtml#cm120
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.
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` ?
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
not to be such a nerd, but this tutorial is ie-oriented (war!) but anyway, mozilla.org ironically has had the same thing .. only more expanded, with less ads, and for all major browsers (including ies) here: http://developer.mozilla.org/en/docs/AJAX ... for a long time now ...