tedd wrote:
At 8:20 AM -0400 9/5/07, [EMAIL PROTECTED] wrote:
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.
I'm not sure what you mean, though, by keeping state in the
browser. Here's
essentially what's work for me in the past:P
I read the above as, to take a simple example:
I read your "simple example" and see that you can do it w/wo ajax --
but I don't see the advantage in using ajax other than presentation.
Please correct me if I'm wrong, but isn't ajax (and ahah) only a means
to communicate with the server without causing a refresh? Does ajax
provide something beyond that?
That's exactly what's provided by XHR (what's usually referred to as
ajax) - a means of mini-requests instead of full-page requests. You
still have to maintain a session id and everything when communicating
with the server, but with a well thought out application, you can skip a
lot of the back and forth between the server and hence keep a lot of the
heavy lifting that involves simple client-side interaction on the client.
Ideally we should be molding our requests around usability, which is
what the ubiquity of XHR allows us to finally do. When we build apps
for the web, we tend to mold usability around server requests. It might
make sense to do so after writing web apps for a while, but to users who
aren't as affiliated, waiting for 3 or 4 pages to load to fill out a
form doesn't make very much sense.
For instance, your user wants to register at your site. The user enters
their username, password, address, personal information, etc and
submit. The username is already in use, so the entire form has to be
reloaded, all the previously entered values have to be shown. This is a
large request on the server (check the db for a username, revert to the
last page with posted data, regenerate the template and fill the form
values). With an XHR capable form, as soon as you tab off of the
username field, a smaller request is made to check the username, and the
user knows immediately if they can continue. No reloading of the page,
minimal server request for the one thing needed instead of the whole
thing. Saves bandwidth, but far more importantly, saves the user's time
and patience.
It mostly depends on what you're building. There's generally not much
use for XHR on a blog app, unless you're adding some bells and whistles
that people can use (a poll that won't refresh the page and hence force
the reader to lose their place, for instance). But on a CMS app or
other type of application that requires a good deal of communication
with the server without having to reload an entire page, it can change
the entire way you program.
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
