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

[Andy Schwartz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090528/46de3dde/attachment.html