Messaging

After a request is processed, typically some sort of message needs to be presented to the user. Validation messages will typically be positioned close by any form elements they're associated with. More generic notifications will appear at a predictable position on each page, with error reports clearly distinguished from informational messages. Messages are only displayed once, and then discarded.

Built-in inter-page message support is an appealing aspect of JSF. Unfortunately, in JSF 1.1, message renderering options are limited (and the Sun RI doesn't provide even the little that's specified) and all messages are lost when navigation redirects to a new URL.

Jon Andersen:

Here is a summary of how Sakai 1.5 solved this problem: 1. Before performing a redirect, save the messages in the session, scoped by the current tool instance. 2. When constructing a FacesContext, first retrieve the messages from the session (again scoped by the current tool instance). This is done in the SakaiFacesContextFactory and in the SakaiViewHandler.

TO DO

• Check the MyFaces implementation of Message to see if it's improved on the Sun RI.
• Look at Jon's approach in Sakai 1.5.

APPROACH

I see two possibilities.

First, to build upon JSF's built-in Message functionality. At the very least this would involve something like the DivMessagesRenderer used in the Berkeley Pilot, and some way to preserve messages across redirects.

Second, to build a simple session-scoped backing bean with methods setMessages(List), getMessages(), and getFormattedMessagesAndClear(). Messages will carry severity levels as in JSF. On each page, if there are messages, then call getFormattedMessagesAndClear(), which writes out the messages as <div>s with appropriate CSS classing, and empties the messages collection. (This won't be request-thread safe. If the instructor is making changes in one browser window while doing what-ifs in another, it's possible that the messages for the first will show up in the second. But I think the possibility of confusion isn't that great.) Vanilla JSF messaging would be reserved for intra-page contexts such as input validation.

The first approach is more JSF-centric and a much better foundation for other tools to build on. I suspect the second approach will be faster to hack out and easier to maintain within the project. We might start with the second and move toward the first after Baseline 2.0 delivery.