This is done by off-loading the creation of DOM elements to the server side, which returns complete constructs that are then injected live through innerHTML. While this method is slightly more verbose than just peddling data across the wire, it's immensely easier to develop.
And especially the ease of development is critical to the success of Ajax. I used the old style of hand-crafting the DOM on the client-side with Ta-da List and was quite disillusioned at the mess of browser differences and the sheer effort it took. Basically, each sliver of Ajax was a project in itself.
With Backpack, though, I've been all over the new Ajax style that Rails affords. And what a difference it makes! It's basically no harder to make something Ajaxed than it is not to, which means that the decision is based on whether its a good fit for the user interface — not on whether we have time to another Ajax project.
We can argue about the name, we can argue old wine on new bottles, but the attention this technique is getting and its integration in frameworks like Rails will rocket its use to the moon and further blur the decision on when you need to go rich and when not to.
I can only agree wholeheartedly. Using Ajax though, 9 times out of 10 when it comes to filling out a firm, is better than not, since you can provide the user/visitor with immediate feedback regarding the validity of the data he/she is putting in the form.
Ajax is old wine in a new bottle, definately, there is no arguing there. What's new and very brightly shining about this is that, like you said, adding Ajax-functionality is barely any more work than not doing so.
Ajax used to be sparse because it's too much work for too little gain, whereas from now on, I predict, it will be used whenever it can and should be, and in the process Ajax and Rails may even become at least a little bit synonymous, in the sense that almost all future Rails apps will have plenty of Ajaxified forms, whereas the rest of the world continues to implement Ajax only when time permits.
"Basically, each sliver of Ajax was a project in itself."
Yeah, that's why it hasn't really been too appealing to us at work yet. As much as we'd like to include it, the idea of hand-crafting DOM-manipulation callbacks for every little thing seemed like a maintenence nightmare. Although we're not developing in Rails (sigh), this model looks really elegant.
Wow. This is really neat. I'm getting ready to do my first project in Rails and yesterday I was thinking "Looks like i'll need to do some user reg stuff", and then this morning I find the Login Generator. So I start thinking "Hmm, this ajax stuff might be complicated" and you release this just in time for me.
Challenge by Danno on March 22, 20:18
One question though: Any analysis of how much the difference in wire speed is between the two methods for arbitrarily complex web apps?
Just thinking about when I'd want to say, "Okay, for Narrow Band user concerns, we're going to do the Ajax on the client."
i agree with going the simpler innerHTML-replacement route. that's how i did a project a while back (in php) and wasn't sure it was the 'best' way to do it, even though it definitely seemed like the simplest way to go. it worked well, so i'm glad to see this becoming the rails way.
Challenge by David Roussel on March 22, 21:57
I don't mean that as a big criticism, but now that everyone has decided on this new term 'AJAX' to represent something we've known about for a long time, let's not dilute the power of the terminology.
David Roussel wrote: "AJAX means something, and it doesn't mean this"
Are you sure Jesse James Garret of Adaptive Path, who coined and defined the term "AJAX", meant to define it that narrowly? I believe that this is exactly the kind of thing Jesse meant when he defined the term, even though we're passing HTML instead of XML.
While this sounds good, I am bit concerned by the use of innerHTML, which is not part of the DOM - I know it is supported by almost all newer browsers, but people should really get used to using nodes instead..
Still pretty cool though - Ajax (hype left aside) is great!
Challenge by Danno on March 22, 22:22
I'd certainly debate that. In my mind, AJAX simply means cool and usefulvery dynamic web... stuff. It's totally a user oriented "technology" therefore it doesn't really matter at all what the transmission method is as long as the end product is freakin' sweet.
The only "downfall" to using innerHtml is that it's only supported in HTML and not in XHTML. But I think more and more people are concluding that XHTML isn't a silver bullet and have been reverting back to HTML.
Thanks for the link on innerHTML compatibility accross browsers.
var newRow = "Hello";
var targetTable = document.getElementById("targetTable");
targetTable.innerHTML = targetTable.innerHTML + newRow;
For me at least, it works in Mozilla/Firefox but always fails in Internet Explorer.
This seems to be an IE bug that is documented on the Web. Can anybody else confirm?
Challenge by Steve Yen on March 23, 16:43
innerHTML is read-only property for tables (and some other elements) in IE.
Also, I was initially put off by the implementations reliance on the non-standard innerHtml property. But the last I checked, XmlHttpRequest isn't a standard either. It's a proprietary MS object that happens to have been cloned in other browsers (much like innerHtml and ContentEditable regions)
Challenge by dodo on June 02, 19:44
It'd be nice to have a way to do: