Mike Kienenberger wrote:
On 11/16/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Just one action event is possible on each request.
Maybe I'm misunderstanding the question, or maybe I'm misinterpreting
the behavior, but I think any number of action events can fire on each
page submit. This is assuming by "action event" that you mean
something that is an ActionSource/ActionListener/FacesListener.
I'm pretty sure that every component that has registered ActionSources
(however named) will queue up all of these events.
There can definitely be lots of "value change" events as the result of a
single postback.
And I agree that every component implementing ActionSource is going to
check the request params to see whether it should queue an ActionEvent
object.
However you can only click on one submit button or link per form
submission, no matter how fast you are with the mouse :-). Various
components like:
HtmlButtonRendererBase
HtmlLinkRendererBase
HtmlJSCookMenuRenderer
can create and queue an ActionEvent in their decode methods. However
each of these components will cause an immediate submit of the HTML page
as soon as their value is changed on the client side, so AFAIK in
practice only one such component will actually cause an ActionEvent on
the server side. Actually, for links there is is a single hidden field
in the form that is assigned the id of the link actually clicked, so
it's physically impossible for more than one link component to fire its
action.
I guess it's possible for someone to fake an HTML post with request
parameters that indicate that more than button component was clicked
simultaneously (and one link too). However that's not something we need
to care about I think :-)
If I'm wrong here, though, and multiple ActionEvents are possible for a
single postback then I'd be glad to hear about it.
As for the timing, it's based on the order of the components in the
component tree. Each action listener is triggered at the end of
either the apply values phase or the end of the process validations
phase. And the final "action" event of the UICommand is processed at
the invoke application phase.
Agreed. However the order of components in the tree is not a pleasant
thing for user code to have to rely upon. In the case of ActionEvents,
though, I think this is not an issue.
Regards,
Simon
