I think that the proposal looks fine, but I agree with Bauke's sentiments
as this seems like a fairly non-standard use case.
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Wed, Nov 30, 2016 at 3:47 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> An "always run validator when required is true" seems okay to me. I did
> spot a small typo in the text, as it currently says:
>
> " If the value of "required" is false, the required attribute is not set
> not set"
>
> I assume the second "not set" should not be there.
>
> The example is indeed a little peculiar. I assume the user does this to
> avoid having a separate backing bean with an action method that only calls
> "request.authenticate", but becoming authenticated as a side-effect of
> running validation would probably not pass code review in a lot of places I
> think.
>
> Kind regards,
> Arjan Tijms
>
>
> On Wed, Nov 30, 2016 at 8:21 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>
>> Hi,
>>
>> Proposal itself looks good, but I can't think of any use case where it
>> would be used as a real solution instead of as a workaround to a design
>> problem. You?
>>
>> Cheers, B
>>
>> On Tue, Nov 29, 2016 at 6:15 PM, Edward Burns <edward.burns_at_oracle.com>
>> wrote:
>>
>>> Hello Volunteers,
>>>
>>> Neil Griffin brought this issue to my attention [1] and has been ardently
>>> advocating for it to be addressed in 2.3.
>>>
>>> When you say required="true" on a UIInput component, the validation
>>> must always take place, even when there is no entry in the request
>>> corresponding to that component.
>>>
>>> Background:
>>>
>>> Consider this login page:
>>>
>>> <h:inputText id="userName" required="true"
>>> value="#{backingBean.userName}" />
>>>
>>> <h:inputSecret id="password" required="true"
>>> validator="#{backingBean.validatePassword}"
>>> value="#{backingBean.password}" />
>>>
>>> <h:commandButton action="/views/authenticatedUser.xhtml" />
>>>
>>>
>>> If the postback is hacked such that the userName is present as a request
>>> parameter, but the password is not, the password validator would be
>>> bypassed. If the password validator is used as the entry point to
>>> perform authentication, this could cause problems.
>>>
>>> Now, it must be said that using a validator on a password field as the
>>> entry point to perform authentication is a particular design choice.
>>> This design choice runs a bit counter to the stated purpose of the
>>> validation system, which is to ensure syntactic and some level of
>>> semantic validity of fields. There are other ways to perform
>>> authentication that do not rely on the validation system for this
>>> purpose.
>>>
>>> Nonetheless, we would like to accomodate this use case.
>>>
>>> Proposal:
>>>
>>> For JSF 2.3, I propose the following.
>>>
>>> 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.*
>>>
>>>
>>> Modify the JavaDoc for UIInput.validate(). Modify the first bullet
>>> point to read:
>>>
>>>
>>> Spec> Retrieve the submitted value with getSubmittedValue(). If this
>>> Spec> returns null, and the
>>> Spec> javax.faces.component.UIInput.ALWAYS_PERFORM_VALIDATION_WHEN
>>> _REQUIRED_IS_TRUE
>>> Spec> context-parameter is set to true (ignoring case), examine the
>>> Spec> value of the "required" property. If the value of "required" is
>>> Spec> true, continue as below. If the value of "required" is false, the
>>> Spec> "required" attribute is not set not set, exit without further
>>> Spec> processing. If the context-paramater is not set, or is set to
>>> Spec> false (ignoring case) exit without further processing. (This
>>> Spec> indicates that no value was submitted for this component.)
>>>
>>>
>>> With these changes, the javadoc for UIInput.validateValue() can remain
>>> unchanged.
>>>
>>> ACTION: Please let us know your thoughts about this by COB 2016-12-06.
>>> I really hope you all can accept it as is, but I think the chance for EG
>>> discussion is warranted here.
>>>
>>> Ed
>>>
>>> --
>>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>>>
>>> [1] https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433
>>>
>>
>>
>