MyFaces Tomahawk
  1. MyFaces Tomahawk
  2. TOMAHAWK-1551

f:ajax doesn't work in t:selectOneRadio layout="spread"

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.10
    • Fix Version/s: 1.1.11
    • Component/s: selectOneRadio / radio
    • Labels:
      None
    • Environment:
      Mojarra 2.0.3, Tomcat 6.0.29, Eclipse 3.6, Windows XP

      Description

      The f:ajax doesn't work in t:selectOneRadio layout="spread". Judging the HTML source, it incorrectly obtains the client ID of t:selectOneRadio instead of the one of the t:radio (or just "this") as first argument of the ajax function. This is been used in document.getElementById() which in turns returns null/undefinied and breaks the ajax function.

      XHTML source:
      <t:selectOneRadio id="item" value="#

      {bean.item}

      " layout="spread">
      <f:selectItems value="#

      {bean.items}

      " />
      <f:ajax event="click" />
      </t:selectOneRadio>
      <t:radio for="item" index="0" />
      <t:radio for="item" index="1" />

      Generated HTML source (labels omitted):
      <input id="form:item:0" type="radio" name="form:item" value="item1" onclick="mojarra.ab('form:item',event,'click',0,0)" />
      <input id="form:item:1" type="radio" name="form:item" value="item2" onclick="mojarra.ab('form:item',event,'click',0,0)" />

      Expected HTML source (labels omitted):
      <input id="form:item:0" type="radio" name="form:item" value="item1" onclick="mojarra.ab('form:item:0',event,'click',0,0)" />
      <input id="form:item:1" type="radio" name="form:item" value="item2" onclick="mojarra.ab('form:item:1',event,'click',0,0)" />
      OR
      <input id="form:item:0" type="radio" name="form:item" value="item1" onclick="mojarra.ab(this,event,'click',0,0)" />
      <input id="form:item:1" type="radio" name="form:item" value="item2" onclick="mojarra.ab(this,event,'click',0,0)" />

        Issue Links

          Activity

          Hide
          Werner Punz added a comment -

          Ok this seems to be a bug, but just for the sake of quickly posting a workaround, you always can use a direct jsf.ajax.request call on the javascript side itself to work around this problem.

          Show
          Werner Punz added a comment - Ok this seems to be a bug, but just for the sake of quickly posting a workaround, you always can use a direct jsf.ajax.request call on the javascript side itself to work around this problem.
          Hide
          Leonardo Uribe added a comment -

          I checked it and it was found the following interesting thoughts:

          • There is no methods on HtmlRendererUtils that allows apply a client behavior that is on a component to another component. The first thing to do is add proper method on that class.
          • Here is clear the f:ajax should be rendered by t:radio. What is not evident, is the sourceId sent should exists on the view. In this case, t:selectOneRadio has no html counterpart, but t:radio does.
          • The id currently rendered by t:radio is not the id of t:radio, instead is a 'logical' id that has sense in t:selectOneRadio with other layouts different to "spread". But in this case what we need is render the "name" of the input radio with the clientId of the associated t:selectOneRadio, and the id of the t:radio, even if this one is generated, because the associated label requires it. The "logical" id does not work well because there is no real component instance and operations that relies on correct "decode" operations fails (think about on f:ajax listener="..." ).
          • A "decode" operation over a t:radio should pass this component instead the associated t:selectOneRadio, even if the client behavior belongs to t.selectOneRadio, because the one who generates the even is t:radio.
          • There is no way to continue using the code that calls parent HtmlRadioRendererBase.renderRadio from HtmlRadioRenderer. t:radio needs special rendering to solve issues like this one and TOMAHAWK-939.

          I'll investigate more about this issue and commit a solution soon.

          Show
          Leonardo Uribe added a comment - I checked it and it was found the following interesting thoughts: There is no methods on HtmlRendererUtils that allows apply a client behavior that is on a component to another component. The first thing to do is add proper method on that class. Here is clear the f:ajax should be rendered by t:radio. What is not evident, is the sourceId sent should exists on the view. In this case, t:selectOneRadio has no html counterpart, but t:radio does. The id currently rendered by t:radio is not the id of t:radio, instead is a 'logical' id that has sense in t:selectOneRadio with other layouts different to "spread". But in this case what we need is render the "name" of the input radio with the clientId of the associated t:selectOneRadio, and the id of the t:radio, even if this one is generated, because the associated label requires it. The "logical" id does not work well because there is no real component instance and operations that relies on correct "decode" operations fails (think about on f:ajax listener="..." ). A "decode" operation over a t:radio should pass this component instead the associated t:selectOneRadio, even if the client behavior belongs to t.selectOneRadio, because the one who generates the even is t:radio. There is no way to continue using the code that calls parent HtmlRadioRendererBase.renderRadio from HtmlRadioRenderer. t:radio needs special rendering to solve issues like this one and TOMAHAWK-939 . I'll investigate more about this issue and commit a solution soon.
          Hide
          Leonardo Uribe added a comment -

          Added renderLogicalId to give the chance to render the logical id instead t:radio id (just for backward compatibility).

          Show
          Leonardo Uribe added a comment - Added renderLogicalId to give the chance to render the logical id instead t:radio id (just for backward compatibility).

            People

            • Assignee:
              Leonardo Uribe
              Reporter:
              Bauke Scholtz
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development