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

[Jim Driscoll]

On 8/12/09 3:33 PM, Andy Schwartz wrote:
> 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.

While we're are notifying them of the value changing, we're also 
notifying them when the value hasn't changed at all.  I thought this was 
a significant enough deviation from the intent of the spec (though not 
the letter), that it was worth mentioning.  But it sounds like this is 
what everyone is used to, anyway.

I've also recently read that the other possible solution, calling blur 
on the onclick event, seems to be bugged in IE6.  Sigh.   So it looks 
like this is the best we're going to get.

When we finally decide not to support IE6, we can always revisit - as 
you say, the spec is deliberately unclear here, so it's open for refinement.

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