The State Pattern and Web Applications

By Deane Barker • Posted on June 03, 2007

I’ve been doing some reading lately on Design Patterns. I find myself trying to relate the examples to Web applications.

One of the interesting ones is the State Pattern. This says that an application is really just a collection of states, or situations the application might find itself in.

Some examples:

This theory postulates that any application is a Finite State Machine and should never find itself in “the wilderness.” Put another way, at any moment in time, it should be able to clearly define just what it’s doing and how the user is interacting with it. All states should be known.

I find that this one relates to Web application development quite a bit. If you have a large application, and it’s getting complicated, I think it’s easier to examine the app in terms of all the different states it could be in.

Consider an article management system. In relation to an article, you could be in any of the following states:

  1. Viewing an article

  2. Viewing an article’s editing form

  3. Submitting an article

  4. Deleting an article

  5. Confirming the deletion of an article

  6. etc

The idea is to be able to define match all requests up with a defined state. So, how do you do this? As near as I’ve been able to figure, you can identify state by two things:

  1. URL

  2. Request method

So, from the above example, “Viewing an article’s edit form” might be defined by a URL pattern of /articles/[some id]/edit and a request method of GET. “Submitting an article” would be the same URL pattern, but with a request method of POST.

(I imagine there are other things to determine the state. Cookies, session variables, etc. But URL and request method are the two big ones.)

I’ve written a little URL mapper class for this in the past. It lets you define a set of URLs, request methods, and corresponding states. Instantiating the object examines the inbound request and returns the state. How you handle it from there is up to you.

The “official” State Pattern calls for a series of state classes which handle the different states of the application.

ViewingArticle.class

SubmittingArticle.class

etc.

This may be a little complicated for the average app. In a lot of cases, I just use the current state to load a file with the correct procedural code for that state.

In the end, this really helps clarify a large, complicated application because it lets you drill down from the big picture to a series of self-contained states which is much more manageable.

For a particularly large app I was working on 18 months ago, I actually had an spreadsheet listing all the states and their descriptions. It made the app so much simpler. In one place, I had the entire picture, and the goal was to be comprehensive enough that every single known state was on the sheet.

Besides simplicity and clarity, focusing your app through states has a few other benefits:

Some other random notes:

mt.cgi?__mode=view&_type=comment

This defines a state where you’re viewing a comment. I’ve done this on a few apps before too – just pass in a mode argument which defines what’s going on. Bonus points if you re-write it.

This is item #206 in a sequence of 353 items.

You can use your left/right arrow keys or swipe left/right to navigate