myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: 1.2 TLD compatibility
Date Tue, 01 May 2007 00:20:54 GMT
On 4/30/07, Tim McConnell <tim.mcconne@gmail.com> 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

Mime
View raw message