Separate the queuing from the firing of
the event is the easy part.
Dealing with the two subcategories of
requires one more twist. From what I’ve said so far,
it looks like an
ActionEvent is always processed
at the end of the Apply Request Values phase, but
that’s only appropriate for user interface events.
As you may recall, an
ActionEvent that requires
backend processing must not be handled until the model properties are
updated, i.e., after the Update Model Values phase at the earliest.
Let’s look at some real examples of action handling using the report entry form in the sample application. We start with events that invoke backend logic in this section and look at user interface events in the next.
As you may recall, the report entry form has three fields for entering a date, an expense type and an amount for a report entry, and an Add button. Figure 8-2 shows the form produced by the version of the page we use in this section.
The Add button is a typical example of the most common type of event handling, namely a button that fires an event that requires processing by the application backend. When the user clicks this button, a new entry with the values entered in the fields is added to the current report.
Example 8-1 shows a version of the JSP page where the Add button is bound ...