Mike Kienenberger wrote:
On 11/16/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
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.
While it's true that only one UICommand "action" attribute will be
queued, there can be any number of other kinds of actionListeners,
valueChangeListeners, updateActionListeners, MyCustomListeners, and so
on, that will also be queued as action events, all of which will be
executed before the "action" attribute.
But like I said above, maybe I'm just misunderstanding the question.
Yes, I think we're using slightly different terminology
FacesEvent has subclasses ActionEvent and ValueChangeEvent.
f:valueChangeListener creates and registers an instance of
ValueChangeListener, which only responds to ValueChangeEvents and
completely ignores ActionEvents. ValueChangeEvents can be generated by
any component that is a UIInput.
I'm talking specifically about ActionEvent objects *only*, which are
generated by UICommand objects *only*. There can be multiple UICommand
objects in a view (eg multiple buttons) but I believe only one of these
can be activated in a single postback, and hence only one ActionEvent
object will ever get queued at the back end. There can be multiple
listeners for the event, added via f:actionListener,
t:updateActionListener, etc.
Anyway, I'm going to create a JIRA item with suggested documentation for
t:updateActionListener; feel free to comment on that issue if you
think I might have got something wrong.
PS: thanks for your feedback!
Cheers,
Simon
