[
https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091870#comment-13091870
]
Josh Canfield commented on TAP5-1621:
-------------------------------------
A workaround is to add the following coercions to your AppModule.
public static void contributeTypeCoercer(Configuration<CoercionTuple>
configuration) {
/**
* Prevent toString() conversion to get to boolean
*/
configuration.add(CoercionTuple.create(Object.class, Boolean.class,
new Coercion<Object, Boolean>() {
public Boolean coerce(Object input) {
return input != null;
}
}));
/**
* Number -> Boolean - make sure that Object -> Boolean isn't used!
*/
configuration.add(CoercionTuple.create(Number.class, Boolean.class,
new Coercion<Number, Boolean>() {
public Boolean coerce(Number input) {
return input.byteValue() != 0;
}
}));
}
> TypeCoercer currently uses Object -> String and String -> Boolean, there
> should be a direct coercion from Object -> Boolean for <t:if/> performance.
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1621
> URL: https://issues.apache.org/jira/browse/TAP5-1621
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Josh Canfield
>
> An issue was raised in this thread:
> http://tapestry.1045711.n5.nabble.com/Null-check-property-expression-syntax-td4726386.html
> Describing the problem where:
> <t:if test="MyObject">
> causes MyObject to be coerced to a String before being coerced to a Boolean.
> For some objects this may be an expensive operation, and the common case (how
> often is the Entity you are editing on a page actually null?)
> Adding an explicit Object -> Boolean coercion will remove the need for the
> Object -> String coercion.
> A Number -> Boolean coercion is also required to prevent Integer -> Boolean
> from choosing the Object -> Boolean as a match (currently it goes Integer ->
> Long -> Boolean)
> At this point the only known issue is that any POJO that depends on the fact
> that returning "false" from toString will cause the Object -> String ->
> Boolean to return false will be broken. This seems like an unlikely case and
> can be worked around by providing a specific TypeCoercion for that object.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
