Hi Bauke,
Please do so it is 100% clear.
Thanks!
Kind regards,
Manfred Riem
On 1/4/17, 10:50 AM, Bauke Scholtz wrote:
> Hi,
>
> It does. Or should I explicitly mention that the else case must call
> super.processValidators()?
>
> Cheers, B
>
> On Tue, Jan 3, 2017 at 10:05 PM, manfred riem <manfred.riem_at_oracle.com
> <mailto:manfred.riem_at_oracle.com>> wrote:
>
> Hi Bauke,
>
> Can you please verify this change stays inline with the master
> contract of processValidators()
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
> On 12/29/16, 11:13 AM, Bauke Scholtz wrote:
>> Hi,
>>
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433
>> <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433>
>> caused an undesired side effect of the current <h:selectOneRadio
>> group> implementation: on a <h:selectOneRadio group="..."
>> required="true">, the required message incorrectly shows up as
>> many times as there are radio buttons of the same group.
>>
>> Therefore I have added UISelectOne#processValidators() method
>> with below API rules to get this right, regardless of 1433.
>>
>> /**
>> * <p class="changed_added_2_3">If {_at_link #getGroup()} is
>> set, and {_at_link #getSubmittedValue()} is empty, and at
>> * least one other component having the same group within a
>> <code>UIForm</code> parent has a non-empty
>> * {_at_link #getSubmittedValue()} or returns <code>true</code>
>> on {_at_link #isLocalValueSet()} or returns
>> * <code>false</code> on {_at_link #isValid()}, then skip
>> validation for current component.</p>
>> */
>>
>>
>> If this needs more clarification, please let me know.
>>
>> Cheers, B
>>
>>
>> On Wed, Sep 28, 2016 at 1:31 PM, Josh Juneau <juneau001_at_gmail.com
>> <mailto:juneau001_at_gmail.com>> wrote:
>>
>> Thanks for the update Bauke, excellent work!
>>
>> Josh Juneau
>> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>> <https://www.apress.com/index.php/author/author/view/id/1866>
>>
>>
>> On Wed, Sep 28, 2016 at 6:08 AM, Bauke Scholtz
>> <balusc_at_gmail.com <mailto:balusc_at_gmail.com>> wrote:
>>
>> Hi,
>>
>> The <h:selectOneRadio group> is finally done. Encode was
>> trivial, but decode was after all tricky if you have to
>> take all possible scenarios into account. Two main tricks
>> were done here: 1) include component's client ID in HTML
>> element value and 2) create a SelectItem wrapper which
>> delegates to the right index of the parent.
>>
>> API is done as per
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329
>> <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329>
>> Impl is done as per
>> https://java.net/jira/browse/JAVASERVERFACES-4188
>> <https://java.net/jira/browse/JAVASERVERFACES-4188>
>>
>> Concrete use cases are shown in this comment:
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329?focusedCommentId=392914&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-392914
>> <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329?focusedCommentId=392914&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-392914>
>>
>> Cheers, B
>>
>> On Mon, Aug 8, 2016 at 11:01 AM, Bauke Scholtz
>> <balusc_at_gmail.com <mailto:balusc_at_gmail.com>> wrote:
>>
>> FYI: I will take this issue on me.
>>
>> Cheers, B
>>
>> On Wed, Sep 30, 2015 at 3:00 PM, Kito Mann
>> <kito.mann_at_virtua.com <mailto:kito.mann_at_virtua.com>>
>> wrote:
>>
>> I like the passthrough approach, but we should
>> really provide a tag too. There are still plenty
>> of people who don't use the pure HTML syntax
>> (especially since it's not supported by
>> third-party component libraries).
>>
>> ___
>>
>> Kito D. Mann | @kito99 | Author, JSF in Action
>> Virtua, Inc. | http://www.virtua.com | JSF/Java
>> EE training and consulting
>> http://www.JSFCentral.com | @jsfcentral
>> +1 203-998-0403 <tel:%2B1%20203-998-0403>
>>
>> * Listen to the Enterprise Java Newscast:
>> _http://
>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>> <http://ww.enterprisejavanews.com>_
>> * JSFCentral Interviews Podcast:
>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>> <http://www.jsfcentral.com/resources/jsfcentralpodcasts/>
>> * Sign up for the JSFCentral Newsletter:
>> http://oi.vresp.com/?fid=ac048d0e17
>> <http://oi.vresp.com/?fid=ac048d0e17>
>>
>> On Mon, Sep 28, 2015 at 1:39 PM, Edward Burns
>> <edward.burns_at_oracle.com
>> <mailto:edward.burns_at_oracle.com>> wrote:
>>
>> >>>>> On Mon, 28 Sep 2015 13:55:21 +0300,
>> Cagatay Civici <cagatay.civici_at_gmail.com
>> <mailto:cagatay.civici_at_gmail.com>> said:
>>
>> CC> I like this approach as well, better than
>> what we have discussed so far.
>> CC> +1,
>>
>> CC> So Bauke, do you propose we dont do
>> anything since it can be already
>> CC> solved with current APIs?
>>
>> I've asked the original poster, Ryan de
>> Laplante, if he's satisfied with
>> this approach.
>>
>> Either way, it's a pretty compelling
>> endorsement of pass through
>> elements and attributes.
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com
>> <mailto:edward.burns_at_oracle.com> | office: +1
>> 407 458 0017 <tel:%2B1%20407%20458%200017>
>> | 28 Business days til JavaOne 2015
>> | 43 Business days til DOAG 2015
>>
>>
>>
>>
>>
>>
>