[jsr-314-open] FYI: onchange for radio and checkbox

[Andy Schwartz]

Yep.  I believe that both Trinidad and ADF Faces use this workaround.

> Sadly, this means that we'll now also fire events even when the value
> isn't changed (such as clicking multiple times on the same radio
> button).

I see this behavior in both the Trinidad and ADF Faces demos.

FWIW, this is one of the main reasons why we introduced the logical 
"valueChange" (and "action") client event names: we wanted to abstract 
page authors away from details of the implementation-specific dom 
events.  Rather than having to worry about whether the component's value 
happens to change in response to click/blur/change events (or some 
combination of these), the page author simply asks to be notified when 
the component's value has changed.

Andy



Martin Marinschek wrote:
> Hi Jim,
>
> that is a well-known bug of IE - no way around this. AFAIK, all
> component libraries with AJAX support do it exactly the same way - use
> onclick for radios and checkboxes.
>
> regards,
>
> Martin
>
> On 8/12/09, Jim Driscoll <Jim.Driscoll at sun.com> wrote:
>   
>> Just an FYI.
>>
>> Previously, in Mojarra, the default ajax behavior for components that
>> rendered radio and checkbox was onchange.
>>
>> Unfortunately, this doesn't work in the way any user would expect in IE
>> - the onchange event will not fire until the component loses focus.
>> This makes it pretty much useless, as a user will click on a radio
>> button then wonder why nothing is happening.  Note that all other
>> browsers fire the onchange event when you'd expect - without waiting for
>> a blur event first.
>>
>> So, in the interests of making all browsers behave similarly, I've
>> changed the default behavior to onclick for those components.  Now, when
>> you click on a radio or checkbox, the event will fire immediately.
>> Sadly, this means that we'll now also fire events even when the value
>> isn't changed (such as clicking multiple times on the same radio
>> button).  In general, most application developers shouldn't notice the
>> difference, but it's conceivable that it might trip someone up at some
>> point.    The alternative, adding an onclick="this.blur();", seemed more
>> likely to add problems than a simple change from onchange to onclick.
>>
>> Just wanted to let you know where we stood with this.  As always,
>> comments appreciated.
>>
>> Jim
>>
>>
>>     
>
>
>