About a month ago, Ian Bicking wrote of a web application pattern concerning status notification. It's a common thing that all of us web developers do - display on a page, usually in a common place, messages like "2 items placed in cart" or "Account Preferences Changed" or anything else along those lines. How it's done varies, but it's usually passed along as an argument to the page being rendered or it's passed along in the REQUEST (ie - as a GET parameter on a redirect). Ian proposes putting these messages in a users SESSION, and removing them immediately after being displayed. I like this. For one thing, it cuts down on the user seeing (or worse, bookmarking) URL's with the message as part of the query string. For another, it causes messages to be displayed regardless of where the user is taken to.
The code in Ian's post shows page headers/components that manipulate the SESSION directly. I don't like doing that, especially in Zope's [excellent] Page Templates. So I opted to make a service object that I can always acquire in Zope, and have it deal with saving and retrieving messages. This allows for application code to send the user messages without knowledge of implementation details, and I could imagine tying it in to a logging framework so that lower level systems and objects could log messages as part of their normal lives, and the higher level web framework would pick up on certain log entries and present them to the user in a unified way.
The Page Messenger service has some other benefits as well. For a while, I've been wanting a way to send messages to all web site visitors - something that might warn of impending maintenance, for example. To add that to my page messenger, all I have to do is add code to the message retrieval interface to look for messages in another location besides the user's session, and the web site will pick up those messages without me having to modify any front end templates.