Hi,
Done:
https://java.net/projects/mojarra/sources/git/revision/bd9a9226de3d8d60cf8fd1b748c94e707c2355df
* ..., then skip validation for current component, else perform
standard
* superclass processing by
<code>super.processValidators(context</code>.</p>
On a related note, Manfred, am I allowed to perform caching in the API
class to save potentially unnecessary component tree visits? Via a private
or public context attribute? Or is this prohibited to the implementation?
Cheers, B
On Wed, Jan 4, 2017 at 6:56 PM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> 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>
> 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 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:com
>>>> ment-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 <%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/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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>