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: Bauke Scholtz <balusc_at_gmail.com>
Date: Sun, 27 Sep 2015 19:20:22 +0200

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
>>>> >> >>
>>>> >> >>
>>>> >> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>