On 4/30/07, Adam Winer <[EMAIL PROTECTED]> wrote:
On 4/30/07, Tim McConnell <[EMAIL PROTECTED]> wrote: > Hi Adam, thanks very much for reviewing my patches so promptly. Here are my > comments to your comments: > > ADFFACES-475: > - If the method name is immaterial at runtime then the only change for the > companion MYFACES-1599 JIRA would be to update the return value which I've done > with the patch attached to MYFACES-1599. If no one objects I think I should just > close ADFFACES-475.
I've closed it.
> ADFFACES-476: > - I really like that solution. I shall provide you with another patch (assuming > I can discern what the spec components are). I wouldn't hardcode in the plugin what a spec component is, etc. I'd make it a property of the plugin, so that in a pom you could have <idExpressions>false</idExpressions> ... and it would turn it off for that project.
I added <disableIdExpressions> which should do the trick for the spec components.
> ADFFACES-477: > - To be honest I was a bit hesitate to alter the current "CAN_COERCE" check > since I was not fully certain of the implications. If there are none, then it > seems the _CAN_COERCE map can be removed as well since that is the only place it > is used. If that is the case I shall provide you with another patch. I'm not 100% sure of the implications either. :) I'll run some tests and make sure this doesn't break anything obvious.
I did some testing - one thing it immediately broke was the "converter" attribute when set to a String. The code generation was using valueExpression.getValue(null) when isLiteralText() was true, which will trigger a coercion (and failure). The fix is to use getExpressionString(). I've applied that fix to the MyFaces component generator (and the Trinidad as well, of course). But to be more conservative, I've only added Converter and UIComponent to the list of types that can appear in <deferred-value/>. I've also added a <coerceStrings/> plugin configuration setting that can let you turn on java.lang.String coercion per project. -- Adam
BTW, does it matter whether a deferred-value type is java.lang.Boolean or boolean? I figure they're identical in runtime behavior, since null will be coerced to Boolean.FALSE and false (I think). -- Adam
