[jsr-314-open] sendAjaxRequest is not defined?

[Dan Allen]

On Thu, May 28, 2009 at 12:51 PM, Andy Schwartz <andy.schwartz at oracle.com>wrote:

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

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.

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)


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

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.


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

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.

-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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090528/74c48b92/attachment.html