javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-329

Add new single HTML radio button component that isn't bound to a list

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      329
    • Status Whiteboard:
      Hide

      cat2 renderkitdoc size_medium importance_small

      Show
      cat2 renderkitdoc size_medium importance_small

      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.

        Activity

        Hide
        rdelaplante added a comment -

        Created an attachment (id=122)
        Example form where this component would be useful

        Show
        rdelaplante added a comment - Created an attachment (id=122) Example form where this component would be useful
        Hide
        Ed Burns added a comment -

        Per 20080827 EG Meeting, push to 2.1

        Show
        Ed Burns added a comment - Per 20080827 EG Meeting, push to 2.1
        Hide
        Ed Burns added a comment -

        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.

        Show
        Ed Burns added a comment - 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.
        Hide
        rdelaplante added a comment -

        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.

        Show
        rdelaplante added a comment - 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.
        Hide
        rdelaplante added a comment -

        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.

        Show
        rdelaplante added a comment - 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.
        Hide
        rdelaplante added a comment -

        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!

        Show
        rdelaplante added a comment - 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!
        Hide
        rdelaplante added a comment -

        I meant to refer to issue #228 instead of #229

        Show
        rdelaplante added a comment - I meant to refer to issue #228 instead of #229
        Show
        rdelaplante added a comment - Here are some examples of how developers have solved this issue: http://webdev2.sun.com/woodstock-tlddocs/webuijsf/radioButton.html http://www.icefaces.org/docs/v1_7_2sp1/tld/ice/radio.html http://myfaces.apache.org/tomahawk-project/tomahawk12/tlddoc/t/radio.html http://software.topcoder.com/catalog/c_component.jsp?comp=26817861&ver=1
        Hide
        Ed Burns added a comment -

        Prepare to delete "spec" subcomponent.

        Show
        Ed Burns added a comment - Prepare to delete "spec" subcomponent.
        Hide
        Ed Burns added a comment -

        Move these to unscheduled because we need to target them correctly. 2.next isn't
        specific enough.

        Show
        Ed Burns added a comment - Move these to unscheduled because we need to target them correctly. 2.next isn't specific enough.
        Hide
        rogerk added a comment -

        cat2

        Show
        rogerk added a comment - cat2
        Hide
        Ed Burns added a comment -

        renderkitdoc

        Show
        Ed Burns added a comment - renderkitdoc
        Hide
        Ed Burns added a comment -

        These are targeted at 2.1.

        Show
        Ed Burns added a comment - These are targeted at 2.1.
        Hide
        sheetalv added a comment -

        triage

        Show
        sheetalv added a comment - triage
        Hide
        Ed Burns added a comment -

        rogerk

        Show
        Ed Burns added a comment - rogerk
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        rdelaplante added a comment -

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

        Show
        rdelaplante added a comment - 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"/>
        Hide
        rdelaplante added a comment -

        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.

        Show
        rdelaplante added a comment - 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.
        Hide
        rdelaplante added a comment -

        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.

        Show
        rdelaplante added a comment - 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.
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Manfred Riem added a comment -

        Setting priority to Critical

        Show
        Manfred Riem added a comment - Setting priority to Critical

          People

          • Assignee:
            Unassigned
            Reporter:
            rdelaplante
          • Votes:
            7 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: