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

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.

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.

Confirmed fixed on icefaces3/trunk revision# 30399.