ICEfaces
  1. ICEfaces
  2. ICE-8221

ace:ajax - disabled attribute not being evaluated

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.BETA1
    • Fix Version/s: 3.1.0.RC1, 3.1
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      All
    • Assignee Priority:
      P2

      Description

      An ace:ajax tag is used for selection of an ace:dataTable row. The disabled attribute is set with a value binding so it can be used dynamically. The attribute is not being evaluated due to:
       - The inclusion of a composite component above the ace:dataTable.
       - The usage of a ui:param tag to defined the bean name used in the value binding expression.

        Issue Links

          Activity

          Arran Mccullough created issue -
          Hide
          Arran Mccullough added a comment -

          Attached test case that shows issue. Goto welcomeICEfaces.jsf to see issue.

          Show
          Arran Mccullough added a comment - Attached test case that shows issue. Goto welcomeICEfaces.jsf to see issue.
          Arran Mccullough made changes -
          Field Original Value New Value
          Attachment Case11294Example.war [ 14521 ]
          Attachment Case11294Example.zip [ 14522 ]
          Arran Mccullough made changes -
          Salesforce Case [5007000000MGorV]
          Ken Fyten made changes -
          Fix Version/s 3.1.0.BETA2 [ 10336 ]
          Fix Version/s 3.1 [ 10312 ]
          Assignee Priority P1
          Security Private [ 10001 ]
          Assignee Mark Collette [ mark.collette ]
          Hide
          Mark Collette added a comment -

          In the test case, immediately above the ace:dataTable, I created two h:outputText components, one using the direct bean EL expression and one using the indirect ui:param EL expression, as the displayed value. Both of these showed the same correct value. So, regular JSF components do the right thing with their regular properties.

          I then repeated this using ace:pushButton and it's value property that comes from UICommand. I also added ace:ajax tags to them with corresponding disabled properties. Again, the value properties rendered correctly for both, but the ace:ajax disabled value was wrong for the indirect ui:param one.

          I had also added much more debug, where the ValueExpression underlying the TagAttribute, for ace:ajax disabled, was both immediately evaluated in construction time, and saved away for render time evaluation, in case that was a factor. No matter when is was evaluated, it had a consistent value.

          So, what we've learned is that this has nothing to do with being in an ace:dataTable, and that regular properties are doing something to compensate for the indirect case that our ace:ajax ones are not. And most bizarrely, saving the ValueExpression, taken from the TagAttribute, did not result in proper EL evaluation, which was a surprise because that's what worked with MethodExpressions for this same scenario in ICE-8180.

          Show
          Mark Collette added a comment - In the test case, immediately above the ace:dataTable, I created two h:outputText components, one using the direct bean EL expression and one using the indirect ui:param EL expression, as the displayed value. Both of these showed the same correct value. So, regular JSF components do the right thing with their regular properties. I then repeated this using ace:pushButton and it's value property that comes from UICommand. I also added ace:ajax tags to them with corresponding disabled properties. Again, the value properties rendered correctly for both, but the ace:ajax disabled value was wrong for the indirect ui:param one. I had also added much more debug, where the ValueExpression underlying the TagAttribute, for ace:ajax disabled, was both immediately evaluated in construction time, and saved away for render time evaluation, in case that was a factor. No matter when is was evaluated, it had a consistent value. So, what we've learned is that this has nothing to do with being in an ace:dataTable, and that regular properties are doing something to compensate for the indirect case that our ace:ajax ones are not. And most bizarrely, saving the ValueExpression, taken from the TagAttribute, did not result in proper EL evaluation, which was a surprise because that's what worked with MethodExpressions for this same scenario in ICE-8180 .
          Ken Fyten made changes -
          Fix Version/s 3.1.0.RC1 [ 10337 ]
          Fix Version/s 3.1.0.BETA2 [ 10336 ]
          Ken Fyten made changes -
          Assignee Priority P1 P2
          Hide
          Mark Collette added a comment -

          It turns out that the test scenario used by ICE-8180 / ICE-8223 was not as full of a scenario as here, and so both the MethodExpressions and ValueExpressions that are derived from the ui:parameter would not work as the ace:ajax listener or disabled properties, no matter how they were constructed or state saved, with ace:ajax operating as a BehaviorHandler. The approach used in ICE-8258 solves this issue.

          Show
          Mark Collette added a comment - It turns out that the test scenario used by ICE-8180 / ICE-8223 was not as full of a scenario as here, and so both the MethodExpressions and ValueExpressions that are derived from the ui:parameter would not work as the ace:ajax listener or disabled properties, no matter how they were constructed or state saved, with ace:ajax operating as a BehaviorHandler. The approach used in ICE-8258 solves this issue.
          Mark Collette made changes -
          Link This issue depends on ICE-8258 [ ICE-8258 ]
          Mark Collette made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Mark Collette made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Security Private [ 10001 ]
          Mark Collette made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Cruz Miraback added a comment -

          Confirmed fixed on icefaces3/trunk revision# 30399.

          Show
          Cruz Miraback added a comment - Confirmed fixed on icefaces3/trunk revision# 30399.
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Mark Collette
              Reporter:
              Arran Mccullough
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: