+1, I agree that it should become the default behavior, with an opportunity to opt out. I also agree with disabling by default if it is back ported.
Josh Juneau
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
> On Dec 8, 2016, at 9:00 AM, Neil Griffin <neil.griffin_at_portletfaces.org> wrote:
>
> +1 to make it the default behavior in 2.3 with a global config param to disable it.
>
> I still recommend that this be backported to the 2.2 / 2.1 API source. In the backport case, it could be disabled by default, with a global com.sun.faces/org.apache.myfaces config param to enable it.
>
>> On Dec 7, 2016, at 10:05 PM, Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
>>
>> 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/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
>>
>>
>>
>