NYCPHP Meetup

NYPHP.org

[nycphp-talk] AJAX and State

Kenneth Downs ken at secdat.com
Wed Sep 5 09:31:49 EDT 2007


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?

Yes, AJAX provides benefits beyond its simple ability to communicate w/o 
a refresh.

BZ's example is exactly what I've been coding the past week or so, and 
it is far simpler keeping track of things in the browser than on the 
server, particularly with tabbed browsing.

Here is a smaller example.  User has a form up to do a database insert 
-- such as create a new insurance company entry.  They have some 
duplicate information and their save will fail, but they don't know and 
they hit save.  What happens?

-> In non-ajax world, you submit the form.  The data is validated and a 
list of errors is generated.  You regenerate the HTML, populate the form 
with the original values, place the error notices, and send it back. 

-> In the ajax world you do an Ajax submit and get back a JSON object 
that contains an array listing the errors.  The response handler puts up 
a popup telling you there were errors, then it adds the errors next to 
the inputs that have problems and changes their css class to make them 
red (or whatever). 

    - no regenerating the form on the server
    - no re-assigning values (they were never changed)
    - no html processing AT ALL on server, just take the data and run 
the INSERT

Doing this requires that some state be stored in the browser as the 
properties of a global object.  That was the thrust of my original post, 
and bz fleshed out scenarios where it would be used.  Here I've tried to 
give a very specific example of how it changes your coding practices.


>
> Cheers,
>
> tedd
>


-- 
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010




More information about the talk mailing list