The Core: Action Beans and JSPs - Stripes...and Java Web Development is Fun Again - page 55

How Tags and Attributes Invoke Action Beans

We've used several tags and attributes to invoke methods on
action beans. Here's a summary of what we've seen so far:
Tag and Attribute Invocation on Action Bean

pkg.Name 's default event handler <s:link beanclass="pkg.Name">

<s:link event="eventName"> public Resolution eventName()

Action bean bound to URL

<s:link href="URL">

<s:param name="property "> setProperty(value)

pkg.Name 's default event handler <s:form beanclass="pkg.Name">

Action bean bound to URL <s:form action="URL">

<s:hidden name="property "> setProperty(value)

<s:text name="property "> setProperty(value)

<s:submit name="eventName"> public Resolution eventName()

Update link and get inputs that autopopulate themselves, and before
we know it, the contact form is complete.

3.7 Use a Forward or a Redirect?

After creating, updating, or deleting a contact, we're returning a Redi-
rectResolution to ContactListActionBean instead of a ForwardResolution to
contact_list.jsp . Why? Let's discuss the difference between the two reso-
lutions and how to decide which one to use.

The Redirect-After-Side-Effect Pattern
The first thing to notice is the create, update, and delete operations all
have side effects—they change the state of the data on the server.

Suppose that we returned a ForwardResolution to a contact_list.jsp after
the user has deleted a contact. Looking at Figure 3.14 , on the following
page, we see that the last request is “delete this contact.” The prob-
lem is that if the user clicks the browser's Reload button, the “delete
this contact” request will be sent again, causing an error because the
contact has already been deleted.

In general, it is a bad idea to use a forward after any request that should
not be resubmitted by hitting Reload . Imagine a request that makes a
purchase with the user's credit card. You wouldn't want to repeatedly
charge the credit card!