Coming back to enabling/disabling JSF 2.3 specific features, the
<faces-config version> attribute should be used as a global flag.
Developers who'd like to use JSF 2.3 in JSF 2.2 backwards compatibility
mode could simply keep it to version="2.2". That's at least how it's
supposed to be used (and has worked for all previous JSF versions and in
all other Java EE APIs).
Cheers, B
On Wed, Dec 7, 2016 at 10:24 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> Hi,
>
> I can understand that, but IMO it should be done the other way round: use
> the flag to disable it. The default behavior should be the leading behavior
> in all cases (the same applies to other 2.3 things like enabling CDI
> resolver chain, by the way). If developers already take much effort to
> upgrade to JSF 2.3, it should be a negligible effort to update web.xml to
> disable JSF 2.3 specific features.
>
> As to the <h:selectBooleanCheckbox required="true"> misbehavior, this
> solution would fix https://java.net/jira/browse/JAVASERVERFACES_SPEC_
> PUBLIC-1289.
>
> Cheers, B
>
> On Wed, Dec 7, 2016 at 5:49 AM, Edward Burns <edward.burns_at_oracle.com>
> wrote:
>
>> >>>>> On Tue, 06 Dec 2016 07:08:51 +0000, Bauke Scholtz <balusc_at_gmail.com>
>> said:
>>
>> B> Hi,
>> B> For menus, radios and manycheckboxes, nothing will change as well. For
>> B> booleancheckbox, it will fix the unintuitive behavior of a
>> required=true to
>> B> not have any effect.
>>
>> Thanks for all the discussion on this. I'm very hesitant to make any
>> changes to something as fundamental as UIInput validation without an
>> opt-in, at this point in the JSF spec lifecycle. There are too many
>> products and libraries that depend on it to consider such a change
>> without very careful consideration.
>>
>> I'll consider it, but at this point I am strongly in favor of putting
>> this behind an opt in flag.
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>>
>
>