You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Josh Canfield (JIRA)" <ji...@apache.org> on 2011/08/26 18:42:29 UTC
[jira] [Created] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
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
[jira] [Closed] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Canfield closed TAP5-1621.
-------------------------------
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Resolved] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Canfield resolved TAP5-1621.
---------------------------------
Resolution: Fixed
Fix Version/s: 5.3
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Resolved] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Canfield resolved TAP5-1621.
---------------------------------
Resolution: Fixed
Fix Version/s: 5.3
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101732#comment-13101732 ]
Hudson commented on TAP5-1621:
------------------------------
Integrated in tapestry-trunk-freestyle #514 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/514/])
TAP5-1621 - Fixed Object[] -> Boolean
joshcanfield : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167386
Files :
* /tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/services/TapestryIOCModule.java
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101959#comment-13101959 ]
Hudson commented on TAP5-1621:
------------------------------
Integrated in tapestry-trunk-freestyle #515 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/515/])
TAP5-1621 - Fixed test
joshcanfield : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167447
Files :
* /tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/internal/services/TypeCoercerImplTest.java
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101732#comment-13101732 ]
Hudson commented on TAP5-1621:
------------------------------
Integrated in tapestry-trunk-freestyle #514 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/514/])
TAP5-1621 - Fixed Object[] -> Boolean
joshcanfield : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167386
Files :
* /tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/services/TapestryIOCModule.java
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Assigned] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Canfield reassigned TAP5-1621:
-----------------------------------
Assignee: Josh Canfield
> 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
> Assignee: 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101959#comment-13101959 ]
Hudson commented on TAP5-1621:
------------------------------
Integrated in tapestry-trunk-freestyle #515 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/515/])
TAP5-1621 - Fixed test
joshcanfield : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167447
Files :
* /tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/internal/services/TypeCoercerImplTest.java
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101498#comment-13101498 ]
Hudson commented on TAP5-1621:
------------------------------
Integrated in tapestry-trunk-freestyle #513 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/513/])
TAP5-1621 - TypeCoercer change: replaced Long -> Boolean with Number -> Boolean. Added Object -> Boolean
joshcanfield : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167289
Files :
* /tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/services/TapestryIOCModule.java
* /tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/internal/services/TypeCoercerImplTest.java
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Assigned] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Canfield reassigned TAP5-1621:
-----------------------------------
Assignee: Josh Canfield
> 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
> Assignee: 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101498#comment-13101498 ]
Hudson commented on TAP5-1621:
------------------------------
Integrated in tapestry-trunk-freestyle #513 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/513/])
TAP5-1621 - TypeCoercer change: replaced Long -> Boolean with Number -> Boolean. Added Object -> Boolean
joshcanfield : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167289
Files :
* /tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/services/TapestryIOCModule.java
* /tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/internal/services/TypeCoercerImplTest.java
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101326#comment-13101326 ]
Josh Canfield commented on TAP5-1621:
-------------------------------------
Need to update the diagram to represent the change. http://tapestry.apache.org/typecoercer-service.html
> 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
> Assignee: 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
[jira] [Closed] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Canfield closed TAP5-1621.
-------------------------------
> 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
> Assignee: Josh Canfield
> Fix For: 5.3
>
>
> 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
[jira] [Commented] (TAP5-1621) TypeCoercer currently uses Object ->
String and String -> Boolean, there should be a direct coercion from Object
-> Boolean for performance.
Posted by "Josh Canfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101326#comment-13101326 ]
Josh Canfield commented on TAP5-1621:
-------------------------------------
Need to update the diagram to represent the change. http://tapestry.apache.org/typecoercer-service.html
> 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
> Assignee: 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