These are excellent questions, which I've answered below.
Some of you have suggested the Barracuda (formerly Rocks) event model,
which I'm looking into. You can read more about it at
http://xmlc.enhydra.org/EventHandler/.
Ted Husted wrote:
> Could the model be extended to optionally log events as they are fired,
> for debugging?
It could, but you could implement a listener that logged events without
extending the event model.
> Could the listeners be loaded via a configuraton file, like Struts
> actions?
They could, and in most cases, they probably should.
> Could a ACTION_PERFORM be added to completely supercede the current
> control flow?
Augment, yes. Supercede, no.
Basically, the way this works is that Struts, meaning, for the moment,
ActionServlet, fires events when it does something interesting. I used the
Action.perform method for something interesting -- the action servlet fires
events to actions just before, and immediately after the servlet calls
Action.perform for every action. Those actions fire events to register
listeners.
You can think of Struts as a garden hose. The water running through the
hose represents Struts events, such as actions being told to perform. I
want to poke holes in that hose, so that developers can siphon those
events.
> In the Form Resubmission example:
>
> Are the "sensitive" forms essential those that should only be submitted
> once per session (if at all)?
No. Sensitive forms are forms with sensitive actions. In the example, the
form in
Figure 2 is a sensitive form because it's action is new-account-action.
That
action is sensitive to form resubmissions.
Every sensitive action must be submitted by a sensitive form for the
form resubmission example to work.
> Could this handle the common occurence of a payment form being
> submitted more than once, resulting in multiple payments?
That's exactly what the form resubmission example does, other than
providing
a simple example of how you'd use the proposed delegation event model.
david
