Main Content

Multiple page web applications - maintaining state - PHP

Archive - Originally posted on "The Horse's Mouth" - 2012-11-10 14:48:35 - Graham Ellis

As you want to do more in an online application, you need to link a series of forms together. There's a limit to how much you can expect your users to enter on one page, and almost inevitably they'll want feedback as they go through a series of steps. So multiple forms is natural, with each encouraging the user onto the next page by positive responses, and questions on subsequent pages which are tuned based on the answers given on earlier pages.

Unfortunatley, the http protocol that's used by browsers to ask for a page off the server is inherrently stateless - in other words, by default there's nothing that's passed from one page to the next which lets the user identify himself - nothing to say "it's me again" ... so if you're not careful, multiple people who are visiting a website at the same time could get their data mixed up.

There are two good mechanisms which are available for maintaining state via a browser / using http.

1. Hidden Fields. If you're running a series of forms, you can pass out from the server data which is to be returned with the next form when it's submitted via a hidden field.

2. Cookies. If you're outputting content via http (it doesn't have to be a form, and indeed it doesn't even have to be HTML), you can pass out a cookie which will be returned by the browser on subsequent requests to the server.

Cookies have the advantage that they only need to be sent out once, and they are returned on each subsequent page. So they avoid the session being lost if your user breaks away from filling an a chain of forms which would happen with a hidden field. However, cookies are stored by the user's computer / on his browser, and some users have concerns about this - especially as cookies attached to certain images (such as adverts) can be used by the advertising host to learn quite widely about the user's browsing habits.

As you run through a session, you're likely to be entering more and more data ... and if you just used hidden fields or cookies to maintain al that state information, your requsts and responses would grow in size. So it's common practise to use a shopping cart or session scheme.

• when a visitor arrives at your application or website WITHOUT a cookie, you allocate him a unique random code and send that out with your response as (typically) a cookie. You also create a disc file or database record, named or keyed using that unique or random code, and into that record or file you store the information to need to retain about your user

• when a visitor arrives WITH a cookie, you read the data from the disc file or database record that's associated with him, secure in the knowledge that it's his data. You process any new data, and you then store the total information so far, ready for his next visit. In theory, you don't need to send out the cookie again .. in practise you may do so, as cookies have a lifetime after which they are deleted, and you're likely to want to start the clock each time your user visits.

The diagram shows in RED the use of a hidden field alone (with the data getting more and more on each cycle), in BLUE a hidden filed and session, ans in GREEN a cookie and session. Much the most commonly used is the Cookie / Session combination - in fact it's already programmed for you into PHP via the $_SESSION superglobal array and functions like session_start.

We cover maintaining state (and the good practise of how to do it) on both our Learning to program in PHP and PHP Programming courses. We cover it in more depth - including design issues, short and long term state, admin login issues and more on our PHP techniques workshop.