jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Re: Re: [JAVASERVERFACES_SPEC_PUBLIC-329] DISCUSSION - Add new single HTML radio button component that isn't bound to a list

From: manfred riem <manfred.riem_at_oracle.com>
Date: Wed, 04 Jan 2017 12:09:03 -0700

Hi Bauke,

I would be very careful with the notion of caching as you do not know
the "shape" of the component tree.

May I ask why do you think you need to cache it?

Thanks!

Kind regards,
Manfred Riem

On 1/4/17, 11:53 AM, Bauke Scholtz wrote:
> 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
> <mailto: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 <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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>