Description

The selectOneRadio component requires that all radio buttons be grouped
together. This is very inflexible when creating user interfaces. Many times I
have encountered screens where I need multiple radio buttons in the same group,
but each radio button exists in a separate area of the screen. This can be done
in HTML easily, but not with JSF's default component set.

I've read that Apache MyFaces has created a component to solve this issue, and
so has Sun's Woodstock component set. Please standardize this fundamental
component in JSF 2.0 so that all implementations come with it.

Very early in the development of JSF 2.0, the EG decided we didn't have enough
resources to add new components and that, since components are extensible
anyway, our time would be better spent working on the top five features of 1.
making components easier to develop 2. having first class ajax support for
custom components 3. reducing the configuration burden 4. providing better error
handling and developer experience 5. providing for better interoperability
between 3rd party jsf components.

Ed Burns
added a comment - 10/Sep/08 8:27 AM Very early in the development of JSF 2.0, the EG decided we didn't have enough
resources to add new components and that, since components are extensible
anyway, our time would be better spent working on the top five features of 1.
making components easier to develop 2. having first class ajax support for
custom components 3. reducing the configuration burden 4. providing better error
handling and developer experience 5. providing for better interoperability
between 3rd party jsf components.

From my experience, this is the only missing component that maps directly to
HTML. I think this is different from adding fun and useful new components.

In my web apps that don't use sophisticated components such as calendars, I
prefer to use the basic h:* input components so that I don't have to force
hundreds of KB downloads on my users. I style with my own CSS. Since JSF
doesn't offer a radio button component where I can specify the html group name
as an attribute, I have to introduce hundreds of KB download of CSS and
JavaScript to my users by adding a component suite.

rdelaplante
added a comment - 10/Sep/08 8:50 AM From my experience, this is the only missing component that maps directly to
HTML. I think this is different from adding fun and useful new components.
In my web apps that don't use sophisticated components such as calendars, I
prefer to use the basic h:* input components so that I don't have to force
hundreds of KB downloads on my users. I style with my own CSS. Since JSF
doesn't offer a radio button component where I can specify the html group name
as an attribute, I have to introduce hundreds of KB download of CSS and
JavaScript to my users by adding a component suite.

This was most noticeable when creating a slim UI for mobile web browsers. If I
wanted to create a UI such as the one in the attached screenshot, mobile users
(smart phones on slow networks) would have to wait 2+ minutes while the
component suite's CSS and JavaScript would download. If JSF had a built in
radio button component that maps to HTML, then this wouldn't be a problem.

rdelaplante
added a comment - 10/Sep/08 8:56 AM This was most noticeable when creating a slim UI for mobile web browsers. If I
wanted to create a UI such as the one in the attached screenshot, mobile users
(smart phones on slow networks) would have to wait 2+ minutes while the
component suite's CSS and JavaScript would download. If JSF had a built in
radio button component that maps to HTML, then this wouldn't be a problem.

I have found a solution for the problem outlined in this ticket without
requiring the addition of a new component. I noticed that issue #229 has added
two new attributes to selectManyCheckbox. All that is missing from
selectOneRadio is a name attribute.

The name attribute is what makes the Woodstock Component Suite's radio button
usable for me, because it lets me have control of the screen layout as shown in
the attached screenshot. If you can add a name attribute to the 2.0 spec that
would be really great!

rdelaplante
added a comment - 17/Sep/08 5:36 PM I have found a solution for the problem outlined in this ticket without
requiring the addition of a new component. I noticed that issue #229 has added
two new attributes to selectManyCheckbox. All that is missing from
selectOneRadio is a name attribute.
<h:selectOneRadio id="notifyOff" value="OFF" name="notifyType"/>
<h:selectOneRadio id="notifyEmail" value="EMAIL" name="notifyType"/>
<h:selectOneRadio id="notifySMS" value="SMS" name="notifyType"/>
The name attribute is what makes the Woodstock Component Suite's radio button
usable for me, because it lets me have control of the screen layout as shown in
the attached screenshot. If you can add a name attribute to the 2.0 spec that
would be really great!

I like how the Trinidad and IceFaces radio button works. Essentially what they've done is extend the existing h:selectOneRadio and added a new layout constant value called "spread" which tells it to not render itself. Then they created a new t:radio component that renders a single radio button and its label wherever you place it. The t:radio has a "for" attribute that points back to the main selectOneRadio, and an "index" attribute that tells it which of the select items to output. It works with JSF's built-in AJAX and I love it. My only issue is that I can't use it in a ui:repeat loop, but I suspect that is a JSF spec issue related to findComponent. I'd also like to be able to choose if the label is rendered to the left or right of the radio button, or not render the label at all.

rdelaplante
added a comment - 20/Apr/12 9:57 PM I like how the Trinidad and IceFaces radio button works. Essentially what they've done is extend the existing h:selectOneRadio and added a new layout constant value called "spread" which tells it to not render itself. Then they created a new t:radio component that renders a single radio button and its label wherever you place it. The t:radio has a "for" attribute that points back to the main selectOneRadio, and an "index" attribute that tells it which of the select items to output. It works with JSF's built-in AJAX and I love it. My only issue is that I can't use it in a ui:repeat loop, but I suspect that is a JSF spec issue related to findComponent. I'd also like to be able to choose if the label is rendered to the left or right of the radio button, or not render the label at all.
<t:selectOneRadio id="upgradesRadio" layout="spread" value="#
{model.upgradeSelection}
">
<f:selectItems value="#
{model.availableUpgrades}
" var="upgrade" itemLabel="#
{upgrade.description}
"/>
<f:ajax/>
</t:selectOneRadio>
... custom HTML layout ...
<t:radio for="upgradesRadio" index="0"/>
... custom HTML layout ...
<t:radio for="upgradesRadio" index="1"/>

Please PLEASE get this done in JSF 2.3, we've been waiting way too long for this. With a perfect solution in Trinidad that works well with the existing h:selectOneRadio design, I don' understand why this keeps getting left undone release after release. Search Google for people using JSF and radio buttons and you'll find a lot of misery.

rdelaplante
added a comment - 30/Aug/13 6:22 PM Please PLEASE get this done in JSF 2.3, we've been waiting way too long for this. With a perfect solution in Trinidad that works well with the existing h:selectOneRadio design, I don' understand why this keeps getting left undone release after release. Search Google for people using JSF and radio buttons and you'll find a lot of misery.

I was working with the t:radio component from Trinidad recently and discovered an inflexibility. It always renders a label with the radio button and so I had difficulty implementing the layout and wrapping dictated by a web designer. Also, they wanted part of the label text to have different font styling. I was unable to embed any kind of HTML tags in the label text loaded from the backing bean (such as a span or div) because it always escapes the label text.

If you implement this feature in JSF 2.3 (please do!), it would be nice to have the option to output just the radio button without the label, and also the option to not escape the text in the label.

rdelaplante
added a comment - 11/Jul/14 3:10 AM I was working with the t:radio component from Trinidad recently and discovered an inflexibility. It always renders a label with the radio button and so I had difficulty implementing the layout and wrapping dictated by a web designer. Also, they wanted part of the label text to have different font styling. I was unable to embed any kind of HTML tags in the label text loaded from the backing bean (such as a span or div) because it always escapes the label text.
If you implement this feature in JSF 2.3 (please do!), it would be nice to have the option to output just the radio button without the label, and also the option to not escape the text in the label.