NYCPHP Meetup

[Gary Mort]

tedd wrote:
> 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.

Problems:
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.

With Ajax:
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 
keywords.

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 
closes, using javascript to load the field.

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.)