Question

So the chain of events is:

1. The user submits a form.
2. During the processing of the submission, there is a message generated, such as ‘Your record was saved.’
3. The user is redirected to a new page, say the search results.
4. The new page needs to display the message.

So, the question is how to get the message from step 2 to step 3? This is only one simple example…there are many other much more complicated examples.

I am using PHP.

Needs:

• supports multiple messages and need to be formatted on the receiving machine as required
• messages can be added on the same page (such as within step 4)
• messages added from inside any function or object

Some options I have come up with:

• store in a session variable as an array and emptied after each display
• pass as a get or query parameter; can get annoying as you are constantly processing this and have to remember to get it; as it can get long, it could easily go over the max length of the query string
• store in the database on a per session basis (may not always be for a logged in user); this would require an extra insert on each page where they are added, possibly multiple, and an extra select on every page

Currently I have been storing the messages in the session in an array, but I’m wondering if there is a better way. I don’t think the other 2 options above are very good.

Edit: I use 2 functions for the session method: AddStatusMsg() (adds an element to the array) and DisplayStatusMsg() (returns an HTML formatted message and empties the array).

Answer 1

I would recommend AGAINST storing these messages either in the database or in the session, for one simple reason: tabs. (Well, really, the stateless nature of HTTP.)

Think of a person who’s got multiple tabs open of different sections of your website. This person performs some action and while that loads, switches to another tab and clicks on a link. If you’re storing the messages in the session/database and the switched-to tab is a page that can display these messages too, the user has now entered a race condition where depending on which request the server responds to first, the messages may display where they were not intended.

Now, there are some situations where this legitimately might not matter, but it could also be extremely confusing in some cases.

Putting the messages in the request doesn’t have to be as bad as it initially seems. Perhaps you could store all the messages you want to display in the database with a numeric (or, for bonus obfuscation, hash) ID, and pass a list of IDs in the query string. This keeps the query string short, and all you have to do is keep track of what ID corresponds to what message in your code.