Hi,
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> wrote:
> Thanks for the update Bauke, excellent work!
>
> Josh Juneau
> juneau001_at_gmail.com
> http://jj-blogger.blogspot.com
> 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> 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/brow
>> se/JAVASERVERFACES_SPEC_PUBLIC-329
>> Impl is done as per 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=392
>> 914&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> 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> 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
>>>>
>>>> * 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/reso
>>>> urces/jsfcentralpodcasts/
>>>> * Sign up for the JSFCentral Newsletter: http://oi.vresp.co
>>>> m/?fid=ac048d0e17
>>>>
>>>> On Mon, Sep 28, 2015 at 1:39 PM, Edward Burns <edward.burns_at_oracle.com>
>>>> wrote:
>>>>
>>>>> >>>>> On Mon, 28 Sep 2015 13:55:21 +0300, Cagatay Civici <
>>>>> 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 | office: +1 407 458 0017
>>>>> | 28 Business days til JavaOne 2015
>>>>> | 43 Business days til DOAG 2015
>>>>>
>>>>
>>>>
>>>
>>
>