Hi
BS>> I can understand that, but IMO it should be done the other way round:
use the flag to disable it.
+1 to make it the default behavior, because the expected impact will be
minimal in my opinion.
The flag should be activated (disable) by the developer.
I do not like to add another param like
javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL , but I agree
it is
the most practical solution in this moment.
regards,
Leonardo Uribe
2016-12-07 4:28 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
> 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/brow
>> se/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
>>>
>>
>>
>