I've been experimenting in JSF for about three months now.
I've been working on a simple web app that searches for whatever the user types in an inputText field, then displays a new page of search results. The web app is modeled after a JSF book example I've read.
The JSF examples in the book I'm reading make JSF look really simple, there aren't any Servlets being used in the sense of specifically processing a doPost or doing anything specifically with the request and response objects, nor any filters, etc. The examples just seem to let the JSF framework take care of everything. All you get is this nice little "type something, click here" example and you end up not knowing what is really going on in the background.
Then I decided I would put a command link on the error page that would reload the main search page with a new session. That seemed like the right thing to do, but then there is still the user who clicks on the browser Back button instead of the server side link I provide to get back to the main search page. I can only control so much.
From here I thought why not just output the error message on the main page. However, now I have to deal with a server roundtrip back to the search form just to display an error message and then figure out what to do with the session variables. Is that the right approach?
Most of the examples of websites I've seen with respect to JSPs or Java Server Faces framework, use a progression of pages (navigation rules) to get to some point, like a register user, shopping cart, or login.
What is the right pattern for this? Output the error message on the main search form using AJAX? Or the way I had it with a server side link back to the search form from the error page and let the user figure out what is wrong if/when they click the browser Back button instead and try to search again? Or something else?
Usually, if an item is invalid, I display if on the form on which it's entered so that the user can correct and resubmit. Which means that the form is redisplayed, and that's the default navigation option anyway.
You can construct an outputText object on your input form to display an error message (if present).
Or you can use the JSF messages element, which is useful if JSF itself might have things to say as well or if you like the extra display options that that tag provides. Since I don't like adding any more JSF-specific code than I must to my backing beans, I use an external JSFUtilities class to hold the (JSF-specific) code that displays the messages, so that the backing bean just calls JSFUtils.addInfoMessage, JSFUtils.addErrorMessage and so forth. JSFUtils is also how I abstract access to the HTTP Request, Session and User identity objects.
Customer surveys are for companies who didn't pay proper attention to begin with.