Gang -

Sorry I wasn't able to follow up on this sooner...

The main reason I pushed for using the event type (eg. "click") over the HTML attribute name (eg. "onclick") was that this is consistent with similar technologies, such as DOM event listeners.  When registering a listener via the standard DOM APIs, the event type is identified using the event name (not the "on"-prefixed attribute name).  That is, we specify:

  domElement.addEventListener("click", listener);


  domElement.addEventListener("onclick", listener);

I believe that the same approach for ClientBehaviorHolder:

behaviorHolder.addClientBehavior("click", behavior);

And by extension <f:ajax>:

  <f:ajax event="click"/>

More closely matches this well-known model.

Another parallel can be found in the W3C XML Events spec:

Where the <listener> has an "event" attribute that specified the event type (not the on-prefixed attribute name):

  <listener event="click" observer="para1" target="link1" handler="#clicker"/>

Which of course is very similar to the <f:ajax> "event" attribute.

So I think we've got the right approach in place, or at least, we are in good company with our current approach.

Rather than doubling the # of supported event names, I would like to stick with a single set of events.  People seem to be able to deal with this pattern when using DOM event listeners - think we should be okay with JSF behaviors.  Of course, we can re-evaluate if this does become a pain point.

3rd party components are  free to specify whatever event names they prefer, though for the sake of consistency across component sets I do think it would be beneficial to follow the event name conventions used by the components in the standard HTML renderkit.

One thing that I completely agree with is that we need to provide clear error handling for cases where the page author specifies the wrong name.  Currently, for this invalid event name:

    <f:ajax event="foo"/>

Mojarra displays the following error message:

/home.xhtml @73,33 <f:ajax> Event attribute could not be determined: foo

I have opened the following Mojarra issue to request that we improve this message:

And I have also uploaded a patch which changes the message to:

/home.xhtml @73,33 <f:ajax> 'foo' is not a supported event for
HtmlCommandButton. Please specify one of these supported event names: action,
blur, change, click, dblclick, focus, keydown, keypress, keyup, mousedown,
mousemove, mouseout, mouseover, mouseup, select.

Hopefully this will help get our users headed in the right direction.

(Oh, if one of the Mojarra guys could take a look at my patch and let me know if I can commit it, that would be great.)


Martin Marinschek wrote On 5/27/2009 1:13 AM ET:
If we disallow the on...-syntax, we need to throw an exception if
someone provides us with an on...-value for the attribute - this is
the least we can do for our users!



On 5/27/09, Roger Kitain <> wrote:
I thought one of the reasons was that the "event" f:ajax attribute also
supports "valueChange" (for example) which is not a DOM event ..
I suppose we could change the docs to say that this attribute supports
the standard DOM events in addition to the faces events
"valueChange" (for EditableValueHolders) and "action" (for ActionSource)...


Andy Schwartz wrote:
Dan Allen wrote:
Anyone else on the EG have any thoughts about supporting both
derivations today?
I do, since I was the one who pushed for the current solution.  :-)

Will follow up with my thinking as soon as I get some free cycles here.



Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a
message if
you feel that it did not reach my attention.