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

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

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Sun, 27 Sep 2015 21:36:42 +0200

Nice approach!

Kind regards,
Arjan Tijms

On Sun, Sep 27, 2015 at 7:20 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> FYI: with JSF 2.2 passthrough elements it's possible to give a custom layout
> to h:selectOneRadio by simply explicitly setting the "name" attribute as
> passthrough attribute. It would override the default value. An example can
> be found in this answer: http://stackoverflow.com/a/7435111/157882
>
> <!-- This makes sure that the submitted value ends up in model. -->
> <f:metadata>
> <f:viewParam name="foo" value="#{bean.selectedFoo}" />
> </f:metadata>
>
> <!-- Just markup them the way you want! -->
> <ul>
> <ui:repeat value="#{bean.availableFoos}" var="availableFoo">
> <li>
> <input type="radio" jsf:id="foo" a:name="foo"
> value="#{availableFoo}">
> <f:passThroughAttribute name="checked" value="#{availableFoo
> eq bean.selectedFoo ? 'checked' : null}" />
> </input>
> </li>
> </ui:repeat>
> </ul>
>
>
> Cheers, B
>
>
> On Tue, Sep 1, 2015 at 4:32 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>>
>> Hi
>>
>> +1, there are good reasons to add this feature to the standard:
>>
>> - Implemented over and over in different component libraries.
>> - Increase flexibility in layout
>>
>> But I have to mention this feature has proven to cause issues with ajax
>> (execute and render multiple components). The problem is each component has
>> different id but the same "group" or in other words the same name attribute.
>> An update over the group involves update each related component. Just
>> something to think about before implement this feature.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2015-08-27 4:37 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>>>
>>> I forgot the ID attribute in case 2, it should of course be
>>> <h:selectOneRadio id="radioId" ... />.
>>>
>>> Cheers, B
>>>
>>> On Thu, Aug 27, 2015 at 11:36 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>>>
>>>> To the point, we need to have a renderer (or perhaps a new component)
>>>> which makes the below cases possible:
>>>>
>>>> 1:
>>>> <h:dataTable value="#{bean.items}" var="item">
>>>> <h:column>
>>>> <h:selectOneRadio group="foo" value="#{bean.selectedItem}"
>>>> itemValue="#{item}" />
>>>> </h:column>
>>>> </h:dataTable>
>>>>
>>>> 2:
>>>> <ui:repeat value="#{bean.items}" var="item">
>>>> <h:outputLabel for="radioId" value="#{item.label}" />
>>>> <h:selectOneRadio group="foo" value="#{bean.selectedItemValue}"
>>>> itemValue="#{item.value}" />
>>>> <br/>
>>>> </ui:repeat>
>>>>
>>>> 3:
>>>> <h:selectOneRadio group="foo" value="#{bean.selectedItem}"
>>>> itemValue="foo" />
>>>> <h:selectOneRadio group="foo" value="#{bean.selectedItem}"
>>>> itemValue="bar" />
>>>> <h:selectOneRadio group="foo" value="#{bean.selectedItem}"
>>>> itemValue="baz" />
>>>>
>>>> The "group" and "itemValue" attributes are new. All it renders is solely
>>>> an <input type="radio"> (no table, no list, no label).
>>>>
>>>> The "group" must be relative to the naming container parent and
>>>> represent the common HTML name. Instead of "group" we could perhaps also use
>>>> a "for" which then refers a common parent component, e.g. for="tableId",
>>>> for="repeatId", for="formId", etc. Only the latter case becomes somewhat
>>>> restrictive.
>>>>
>>>> The "itemValue" speaks for itself. The label is just to be provided by
>>>> <h:outputLabel> the usual way.
>>>>
>>>> Cheers, B
>>>>
>>>> On Tue, Aug 25, 2015 at 12:18 PM, arjan tijms <arjan.tijms_at_gmail.com>
>>>> wrote:
>>>>>
>>>>> On Tue, Aug 25, 2015 at 6:18 AM, Josh Juneau <juneau001_at_gmail.com>
>>>>> wrote:
>>>>> >These trivial
>>>>> > issues with JSF have led to many arguments against using the
>>>>> > framework. The
>>>>> > easier it is made for beginners, the better in my opinion.
>>>>>
>>>>> For beginners especially, but moderately advanced users as well. We've
>>>>> seen this time and again with OmniFaces. Trivial functionality that in
>>>>> essence encapsulates only a few lines of code using the standard JSF
>>>>> API. Yet, users greatly appreciate it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> >
>>>>> > Josh Juneau
>>>>> > juneau001_at_gmail.com
>>>>> > http://jj-blogger.blogspot.com
>>>>> > https://www.apress.com/index.php/author/author/view/id/1866
>>>>> >
>>>>> >
>>>>> > On Wed, Aug 19, 2015 at 1:08 PM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> I agree with Bauke, this has been asked for a lot of times by users.
>>>>> >> I
>>>>> >> had a bunch of personal messages in response to my JSF 2.3 wish list
>>>>> >> asking for exactly this.
>>>>> >>
>>>>> >> Such a component seems to be "basic" enough to be a good candidate
>>>>> >> for
>>>>> >> inclusion in the JSF standard component set.
>>>>> >>
>>>>> >> Kind regards,
>>>>> >> Arjan Tijms
>>>>> >>
>>>>> >> On Wed, Aug 19, 2015 at 7:27 PM, Bauke Scholtz <balusc_at_gmail.com>
>>>>> >> wrote:
>>>>> >> > I vote against. This is one of most common requirements from the
>>>>> >> > community.
>>>>> >> > I'd like to see this to end up in standard component set too. A
>>>>> >> > custom
>>>>> >> > renderer is not trivial to starters, for sure not if you'd like to
>>>>> >> > use
>>>>> >> > it in
>>>>> >> > an repeater component like
>>>>> >> > <h:dataTable><h:column><h:selectOneRadio>
>>>>> >> > and/or
>>>>> >> > if you want to have a separate <h:outputLabel> for each item.
>>>>> >> >
>>>>> >> > Cheers, B
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Wed, Aug 19, 2015 at 7:16 PM, manfred riem
>>>>> >> > <manfred.riem_at_oracle.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> Hi all,
>>>>> >> >>
>>>>> >> >> I like to close this one as "Won't fix" as well as it is fairly
>>>>> >> >> easy to
>>>>> >> >> register your own renderer.
>>>>> >> >>
>>>>> >> >> To introduce a new component for it seems overkill.
>>>>> >> >>
>>>>> >> >> Thoughts?
>>>>> >> >>
>>>>> >> >> Note I like to close the loop on this one before 8/26.
>>>>> >> >>
>>>>> >> >> Thanks!
>>>>> >> >>
>>>>> >> >> Kind regards,
>>>>> >> >> Manfred Riem
>>>>> >> >>
>>>>> >> >>
>>>>> >> >
>>>>> >
>>>>> >
>>>>
>>>>
>>>
>>
>