Hi
+1
Thanks Ed for reviewing this.
regards,
Leonardo Uribe
2016-12-14 17:39 GMT-05:00 Edward Burns <edward.burns_at_oracle.com>:
> >>>>> On Wed, 30 Nov 2016 08:21:12 +0100, Bauke Scholtz <balusc_at_gmail.com>
> said:
>
> BalusC> Proposal itself looks good
>
> >>>>> On Wed, 30 Nov 2016 10:47:14 +0100, arjan tijms <
> arjan.tijms_at_gmail.com> said:
>
> AT> An "always run validator when required is true" seems okay to me. I did
> AT> spot a small typo in the text, as it currently says:
>
> AT> " If the value of "required" is false, the required attribute is not
> set
> AT> not set"
>
> I've fixed that by editing the JIRA. Thanks.
>
> >>>>> On Wed, 30 Nov 2016 17:32:44 -0500, Neil Griffin <
> neil.griffin_at_portletfaces.org> said:
>
> NG> Q: Would it cause a backward compatibility problem if we simply made
> NG> the following change?
>
> NG> if ((submittedValue == null) && !isRequired()) {
> NG> return;
> NG> }
>
> NG> In other words, is it necessary to introduce the context-param along
> NG> with the fix?
>
> Those of you who have worked with me over the years know that I don't
> like to forcefully advocate for a particular approach, but in this case,
> I feel that such a fundamental change must be guarded by an opt-in.
>
> >>>>> On Wed, 30 Nov 2016 23:50:22 -0500, Leonardo Uribe <
> leonardo.uribe_at_irian.at> said:
>
> LU> Is the change backward compatible with JSF 2.0/2.2 third party
> LU> libraries? Yes, I think so, unless you have a component that does
> LU> not extend from UIInput and implements EditableValueHolder. I prefer
> LU> that compromise to another strange global web config param that will
> LU> break later.
>
> I see your point, but the key word here is "another". We already have
> so many of these that one more isn't going to make a difference. I know
> that's not the best argument, but I'm asking you to accept it.
>
> >>>>> On Thu, 01 Dec 2016 07:30:34 +0000, Bauke Scholtz <balusc_at_gmail.com>
> said:
>
> BalusC> Yes, but this indicaties a bad model. The normal solution would
> BalusC> be to put a @NotNull constraint on the entity or a NOT NULL
> BalusC> constraint on the column.
>
> Please let's constrain the discussion to the original issue, which is
> UIInput field validation.
>
> >>>>> On Fri, 2 Dec 2016 13:28:38 -0500, Neil Griffin <
> neil.griffin_at_portletfaces.org> said:
>
> NG> @Leonardo: +1 I think that you have identified an oversight in the
> NG> Spec language. Also, I agree with you that we should avoid a global
> NG> web config param if possible.
>
> Yes, it is an oversight in the spec language. I judge this oversight is
> adequately addressed by this change:
>
> Modify PDF section 3.5.4 to read:
>
> Spec> *The render-independent property required is a shorthand for the
> Spec> function of a required validator. If the value of this property
> is
> Spec> true, **there is an entry in the request payload corresponding to
> Spec> this component**, and the component has no value, the component
> is
> Spec> marked invalid and a message is added to the FacesContext
> Spec> instance.*
>
> NG> @Leonardo: +1 I think that you are exactly right. If
> NG> required="true", shouldn't the JSF developer be able to rely on the
> NG> PROCESS_VALIDATIONS phase to enforce that? The plain meaning would
> NG> be that the value is *always* required, without qualification or
> NG> exception.
>
> Think about that statement. Now think about all the JSF apps that are
> already out there. We have always maintained that updating to a new JSF
> version will not cause any breaking changes. We need to own that such a
> change is a very low level change and it's quite possible it would have
> unintended consequences.
>
> >>>>> On Mon, 5 Dec 2016 23:33:51 -0500, Leonardo Uribe <
> leonardo.uribe_at_irian.at> said:
>
> LU> So the answer is the change does not cause a backward compatibility
> LU> problem, and based on that the web config parameter is not really
> LU> necessary. Does it work in all cases? I'm not 100% sure, because we
> need
> LU> to check what happens for menu/radio/checkbox, but if that so, apply a
> LU> simple patch with just these lines could be a valid solution.
>
> I'm not so confident in our test suite that knowing that it passes with
> the change in place is enough to know that it will always pass with all
> possible apps. As you said, you're not 100% sure, but if we make the
> change an "opt in" change, we can be 100% sure.
>
> >>>>> On Tue, 06 Dec 2016 07:08:51 +0000, Bauke Scholtz <balusc_at_gmail.com>
> said:
>
> BalusC> For menus, radios and manycheckboxes, nothing will change as
> BalusC> well. For booleancheckbox, it will fix the unintuitive behavior
> BalusC> of a required=true to not have any effect.
>
> Unintuitive, yes, but very long established. I mean, like, twelve years
> ago established.
>
> >>>>> On Wed, 7 Dec 2016 10:24:00 +0100, Bauke Scholtz <balusc_at_gmail.com>
> said:
>
> BalusC> I can understand that, but IMO it should be done the other way
> BalusC> round: use the flag to disable it. The default behavior should
> BalusC> be the leading behavior in all cases (the same applies to other
> BalusC> 2.3 things like enabling CDI resolver chain, by the way).
>
> >>>>> On Wed, 7 Dec 2016 10:28:35 +0100, Bauke Scholtz <balusc_at_gmail.com>
> said:
>
> BalusC> Coming back to enabling/disabling JSF 2.3 specific features, the
> BalusC> <faces-config version> attribute should be used as a global
> BalusC> flag. Developers who'd like to use JSF 2.3 in JSF 2.2 backwards
> BalusC> compatibility mode could simply keep it to version="2.2". That's
> BalusC> at least how it's supposed to be used (and has worked for all
> BalusC> previous JSF versions and in all other Java EE APIs).
>
> This is a larger issue for a separate thread. I'll start that thread now.
>
> BalusC> As to the <h:selectBooleanCheckbox required="true"> misbehavior,
> BalusC> this solution would fix
> BalusC> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1289.
>
> I would think the original proposal for 1433-UIInputRequiredTrue would
> also fix this, right?
>
> >>>>> On Wed, 7 Dec 2016 22:05:06 -0500, Leonardo Uribe <
> leonardo.uribe_at_irian.at> said:
>
> LU> +1 to make it the default behavior, because the expected impact will
> LU> be minimal in my opinion. The flag should be activated (disable) by
> LU> the developer.
>
> >>>>> On Thu, 8 Dec 2016 10:00:40 -0500, Neil Griffin <
> neil.griffin_at_portletfaces.org> said:
>
> NG> +1 to make it the default behavior in 2.3 with a global config param
> NG> to disable it.
>
> >>>>> On Fri, 9 Dec 2016 23:19:29 -0600, Josh Juneau <juneau001_at_gmail.com>
> said:
>
> JJ> +1, I agree that it should become the default behavior, with an
> JJ> opportunity to opt out. I also agree with disabling by default if
> JJ> it is back ported.
>
> You're making it hard guys, but I still have to say -1. It's too
> fundamental to be the default behavior. I'm surprised to see you
> advocating so vociferously for this Neil.
>
> LU> I do not like to add another param like
> LU> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL , but I
> LU> agree it is the most practical solution in this moment.
>
> I'm glad we agree at least on that point!
>
> NG> I still recommend that this be backported to the 2.2 / 2.1 API
> NG> source. In the backport case, it could be disabled by default, with
> NG> a global com.sun.faces/org.apache.myfaces config param to enable it.
>
> >>>>> On Tue, 6 Dec 2016 15:43:27 -0500, Neil Griffin <
> neil.griffin_at_portletfaces.org> said:
>
> NG> If JAVASERVERFACES_SPEC_PUBLIC-1433 is adopted, then would anyone
> NG> object to backporting this to the JSF 2.2 and 2.1 API source? My
> NG> best guess is that it would be necessary to enable it with a
> NG> com.sun.faces/org.apache.myfaces global web config param in 2.2/2.1
> NG> unless we did an MR.
>
> Therefore, I propose we simply provide the same fix I've proposed for
> JSF 2.3 in the existing Mojarra releases, but without introducing the
> symbolic constant ALWAYS_PERFORM_VALIDATION_WHEN_REQUIRED_IS_TRUE. In
> other words, the context-param is there, it has the same name and
> meaning, it's just not in the signatures.
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 37 business days until DevNexus 2017
> | 62 business days until JavaLand 2017
>