All objects in the model are exposed to the Viewinstance, so the success view XHTML
page can now easily display the recommended book, as shown in Listing 6-48.Listing 6-48.XHTML for Recommended Book Title<body>Welcome, ${person.name}! You chose ${person.favoriteProgrammingLanguage}
as your favorite programming language. Therefore, we can recommend you
check out ${suggestedBook}.</body>Redirect After Submit Pattern
There is a common problem with the way we are handling the display of the confirmation
page, which needs to be fixed. The success view is rendered in the same request as the initial
POST, leaving the browser in a state with the ability to replay the form submit. In other words,
after the success view is shown, the user can simply reload the page, resubmitting the form.
This can lead to inconsistencies, with the best-case scenario of a confused user and a worst-
case scenario of multiple identical Personinstances being saved into the database.
Any form that alters data in persistence, or performs any type of potentially destructive
operation, is at risk of being resubmitted. Multiple solutions exist that can ensure that the user
must view the form before submitting, thus preventing double submissions. We will cover one
of the most common solutions, the Redirect After Submit pattern, in the next example. This
pattern simply redirects the user to the success view instead of internally forwarding the
request. The redirect forces the browser to obtain a new page, and any reloads will now safely
reload the new page instead of the form page.■CautionA client redirect is not the same as a RequestDispatcher.forward()or RequestDispatcher.
include().These two methods internally redirect a request to another handler inside the servlet container.
A client redirect instructs the client to issue another GET request.This pattern is implemented via browser redirects, which are initiated from the server and
are built into the HTTP protocol. This means this technique can be used independent of the
view technologies used. To initiate a client redirect, the server will send a 302 response code
(or 303 if HTTP/1.1 only) plus a Location:header to the client. The HTTP response code 302
indicates that a resource^4 has temporarily moved or that the browser should look elsewhere
for the resource. When the browser encounters a 302, it will look for a Location:header to
indicate where the resource can now be found.164 CHAPTER 6 ■THE CONTROLLER MENAGERIE
- More accurately, that the representation of the resource has moved.