NYCPHP Meetup

[Hans Zaunere]

Hi,

Kenneth Downs wrote on Tuesday, September 04, 2007 8:51 AM:
> One thing that seems to have gone unsaid in the praise for Ajax is its
> ability to radically transform how we maintain state.
> 
> The web server session is our basic mechanism for storing information
> between requests.  But it gets clumsier and clumsier to try to
> maintain complex state across many page requests when you use a
> session. Ingenious minds have put their will to the problem and come
> up with workable systems, but all of them are complicated because of
> the nature of the problem.
> 
> That problem, stated here, is simply the problem of tracking what I'll
> call the "context" of a user's session.  Some elements of a session
> are fixed: the user id, the password, a few other things, but almost
> everything that we need to track is always changing.  A basic
> example: a list of search results.  Where do you store it?  When the
> user hits, "NEXT PAGE", how do you know what to do?  If you are using
> a session, what happens if he opens a new window and has two search
> results sets up for two different tables?

We've encountered similar problems, which are especially prevelant in a web
2.0 super-duper-magic type of site (ie, tabbed browsing, draggable modules,
etc).

> 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

-- typical session ID is generated and the browser is cookied, just like
with any other site.  this sets a session for the entire browser - nothing
special here

-- the Javascript code is written to persist the browser's cookie, so it's
requests appear to the server just like any other regular browser request

-- the server is now getting hit with numerous requests - some are the
"whole browser" and some are simply partial requests (Ajax/JS requests).
These requests are typically out of the classic order that you'd expect a
browser to produce, since you can't always assume the timing of the user's
browser.

The Ajax requests hit a certain set of URLs, let's say /Ajax/, on the
server.  The server knows to handle these requests specially, which in
effect creates sub-sessions.  That is to say, for every complex set of Ajax
operations, the server is maintaining it's own sub-set of data.  For
instance, search results and the search criteria, which is attached strictly
to a single module or Ajax part of the page.

---
Hans Zaunere / President / New York PHP
    www.nyphp.org  /  www.nyphp.com