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);

Not:

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:

http://www.w3.org/TR/xml-events/Overview.html#section-listener-element

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:

<h:commandButton>
<f:ajax event="foo"/>
</h:commandButton>

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:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1138

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.)

Andy

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!

regards,

Martin

On 5/27/09, Roger Kitain <Roger.Kitain@sun.com> 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)...

-roger

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.

Andy

-Dan

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

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

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
week,
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.