This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

General JSF page navigation questions

Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

The original design of my web app would navigate to an error.jsp if what the user entered in the textbox was not found. I thought that might be a good solution until I started dealing with the browser Back button and the fact that the session is holding on to a search variable that is no good. I don't want to mess with the Browser, or use JavaScript if possible (not that I can't, I just don't want to if I don't have to).

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?

Saloon Keeper
Posts: 21121
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

A round-trip to the server is essential in any case, since it's server-side code that make the determination as to whether the data is valid. Unless you're using JavaScript for validation, in which case the JavaScript rules apply, not JSF.

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.
You can thank my dental hygienist for my untimely aliveness. So tiny:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!