<div class="gmail_quote">On Thu, May 28, 2009 at 12:51 PM, Andy Schwartz <span dir="ltr"><<a href="mailto:andy.schwartz@oracle.com">andy.schwartz@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Gang -<br>
<br>
Sorry I wasn't able to follow up on this sooner...<br>
<br>
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:<br>
<br>
<blockquote type="cite"> domElement.addEventListener("click",
listener);</blockquote>
<br>
<br>
Not:<br>
<br>
<blockquote type="cite"> domElement.addEventListener("onclick",
listener);</blockquote>
<br>
<br>
I believe that the same approach for ClientBehaviorHolder:<br>
<br>
<br>
<blockquote type="cite">behaviorHolder.addClientBehavior("click",
behavior);</blockquote>
<br>
And by extension <f:ajax>:<br>
<br>
<blockquote type="cite"> <f:ajax event="click"/></blockquote>
<br>
<br>
More closely matches this well-known model.<br>
<br>
Another parallel can be found in the W3C XML Events spec:<br>
<br>
<a href="http://www.w3.org/TR/xml-events/Overview.html#section-listener-element" target="_blank">http://www.w3.org/TR/xml-events/Overview.html#section-listener-element</a><br>
<br>
Where the <listener> has an "event" attribute that specified the
event type (not the on-prefixed attribute name):<br>
<br>
<blockquote type="cite"> <listener event="click" observer="para1"
target="link1" handler="#clicker"/></blockquote>
<br>
Which of course is very similar to the <f:ajax> "event" attribute.<br>
<br>
So I think we've got the right approach in place, or at least, we are
in good company with our current approach.</div></blockquote><div><br>Consistency is good. I can't argue with that. We've just had to wade through such turbulent waters in the past that you do question yourself the first couple of times you work with the events (as I mentioned, attachEvent() in IE requires the on prefix. But we are making a decisive commitment to aligning with standards.<br>
<br>I would love to see the text you just typed in the non-normative background part of the spec (perhaps something as concise as "In choosing event names, we are following well defined standards in JavaScript DOM and W3C XML Events spec by using the literal event name and excluding any prefix such as 'on'."). Then, people will remember that and never second guess again. (Section 3.7.1)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><br>
<br>
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.</div></blockquote><div><br>The importance here is making it well-known. If we come out of the gate with a strong statement that is memorable, it will never become a pain point.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><br>
<br>
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.<br>
<br>
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:<br>
<br>
<blockquote type="cite"> <h:commandButton><br>
<f:ajax event="foo"/><br>
</h:commandButton></blockquote>
<br>
<br>
Mojarra displays the following error message:<br>
<br>
<blockquote type="cite">/home.xhtml @73,33 <f:ajax> Event
attribute could not be determined: foo</blockquote>
<br>
<br>
I have opened the following Mojarra issue to request that we improve
this message:<br>
<br>
<a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1138" target="_blank">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1138</a></div></blockquote><div><br>A good error message is going to avoid a lot of complaining. That's really all I want to avoid. Those nagging complaints that have haunted JSF in the past.<br>
<br>-Dan<br></div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don't hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>
you feel that it did not reach my attention.<br>