NYCPHP Meetup

[Mark Armendariz]

tedd wrote:
> At 8:20 AM -0400 9/5/07, bz-gmort at beezifies.com 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.