Hi, I do not know the answer Adam's last question below concerning boolean
versus java.language.Boolean, although I'm interested in the answer. Would
someone else please advise ?? Thanks much.
Tim McConnell
Adam Winer wrote:
On 4/30/07, *Tim McConnell* <[EMAIL PROTECTED]
<mailto:[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.
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.
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.
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
