[nycphp-talk] AJAX and State
bz-gmort at beezifies.com
Wed Sep 5 09:47:43 EDT 2007
> At 8:20 AM -0400 9/5/07, bz-gmort at beezifies.com wrote:
>> 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.
To do it without Ajax requires you to explicitly create code to track
each individual browser window as the user moves throughout the system
so you can bring them back to where they started from.
Using Ajax, you didn't have to write a line of code since the state was
maintained in the browser window itself.
So it was not having to code for the situation at all due to using Ajax.
Is that an advantage? I don't see it as one, as using Ajax in that
manner introduces other problems. But it is a different way to code and
based on your individual mindset, you might find it easier to think in
terms of letting the browser maintain it's own tracking than in trying
to track every variable yourself.
> 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?
Ajax changes the way you program.
Consider the following:
You have a form with 100 fields of information, 1 of which must be
unique in your database.
A user enters all 100 pieces of data and than submits it(yes, this is
poor form. You should pace the data over multiple input screens so as
not to overwhelm the user. I however deal with the real world where
real clients insist this is the way everyone wants to enter data and
refuse alternate suggestions such as tabs. *shrug*), you check for
uniqueness and generate an error message, as well as having to make sure
to preload every one of those 99 fields in the error form, as well as
prompting for a new unique key. Alternatively, you could prompt for
that one piece of unique data, and than reserve it for that user and
than prompt for the other 99.
If checking after the user enters 100 different fields, they get very
very irate to be asked to enter yet another piece of data.
If you reserve the field for them and they don't complete the
registration, you also need to build a cleanup process or have phantom
records hanging around.
You can check that unique field at the moment they enter it, so they can
pick one at the time. And you can check that field when they try to
submit it and keep them from submitting a non unique value(in case
someone claimed it while they filled in the info). You STILL need to
perform the final submit check, but you reduce user irritation by
minimizing attempts at loading bad data.
Also, the classic Ajax example. Go the newegg.com and start searching
for something. It generates a drop down list dynamically of potential
matches. Without AJAX and with a database of thousands of keywords, you
will need to perform fuzzy searches and deal with users mis-spelling
With Ajax, you can get correct keywords and don't need fuzzy searches.
Ajax allows you to move certain lookups from popup windows, which are
annoying and frequently blocked, to the main window itself.
Imagine you want to select a user from a list of 1000 users. An old way
of doing it could be to list the letters of the Alphabet, and have
clicking on them popup a window with just the users who have a lastname
starting with that letter. Than you select the user and the popup
With Ajax, instead you can do that sort of lookup in the browser itself.
All of this is due to being able to "communicate with the server without
causing a browser refresh" Basically, Ajax can turn traditional client
lite/server heavy applications into client heavy/server lite applications.
This is not always a good thing! It is simply a thing. Whether it is
good or bad depends strongly on your users, your application, and your
needs(I'm not a big Ajax advocate, heck I've only used it in a few apps.)
More information about the talk