Uploaded image for project: 'MyFaces Tomahawk'
  1. MyFaces Tomahawk
  2. TOMAHAWK-380

t:Radio not checked correctly with f:selectItem and non-String backing bean property


    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: selectOneRadio / radio
    • Labels:
    • Environment:
      Jboss 4.0.3, EJB3, JBoss Seam, Facelets


      Look at this simple selectOneRadio tag:

      <t:selectOneRadio id="question" value="#

      {haqInput.testme}" layout="spread">
      <f:selectItem itemValue="0" itemLabel="a"/>
      <f:selectItem itemValue="1" itemLabel="b"/>
      <f:selectItem itemValue="2" itemLabel="c"/>
      <f:selectItem itemValue="3" itemLabel="d"/>

      <t:radio for="question" index="0" />
      <t:radio for="question" index="1" />
      <t:radio for="question" index="2" />
      <t:radio for="question" index="3" />


      is an Integer property of the backing bean haqInput.

      If you submit the form to another view and come back to this page (I'm using a next/prev wizard), none of the rendered radio buttons contains
      the "checked" attribute. However, if you remove the "layout=spread" attribute, one of the default radio buttons (the non-t:radio versions) are rendered correctly including the "checked" attribute.

      I have digged into the problem. In Tomahawk's HtmlRadioRenderer.java we read:

      currentValue == null && itemValue == null ||
      currentValue != null && currentValue.equals(itemValue), false);

      However, the equals() check is false since <f:selectItem itemValue="1" itemLabel="b"/> will render the actual itemValue as a String() class,
      but currentValue's class is of type Integer. I have verified this in some debug output I just added to the file:

      20:40:59,583 INFO [STDOUT] itemValue: 3, type java.lang.String
      20:40:59,583 INFO [STDOUT] currentValue: 3, type java.lang.Integer

      I don't know how the standard myfaces version of selectOneRadio checks for equality, so this is probably how you would do this. I just added
      another "|| currentValue != null && currentValue.toString().equals(itemStrValue)" in the condition above, this works for me but is probalby only a back hack.

      Another workaround is probably using a backing bean and f:selectItems, where the itemValue variables are already of type Integer as well. I'm going to try this out now, because the t:inputDate in the latest subversion checkout is broken as well. sigh


        There are no comments yet on this issue.


          • Assignee:
            doegi Alexander Langer
          • Votes:
            1 Vote for this issue
            2 Start watching this issue


            • Created: