tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Zeigler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-1549) ParameterWorker forces evaluation of defaultXXX methods, even if the parameter is bound
Date Thu, 07 Jul 2011 01:15:17 GMT

    [ https://issues.apache.org/jira/browse/TAP5-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060974#comment-13060974

Robert Zeigler commented on TAP5-1549:

Heh. I forgot to mark this as "In Progress".  :) I have a working fix for this, I was just
exploring different possibilities because my solution would wind up calling the default method
at least once, any render it was accessed, even if the underlying value didn't change, and
I wasn't happy with that. I'll be curious to see what you come up with.

> ParameterWorker forces evaluation of defaultXXX methods, even if the parameter is bound
> ---------------------------------------------------------------------------------------
>                 Key: TAP5-1549
>                 URL: https://issues.apache.org/jira/browse/TAP5-1549
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.5
>            Reporter: Robert Zeigler
>            Assignee: Howard M. Lewis Ship
> The revised implementation of ParameterWorker evaluates the defaultXXX method regardless
of whether or not the parameter is bound.  This can easily lead to application exceptions,
particularly when the defaultXXX value is computed rather than static.  
> For example, loop's "encoder" parameter attempts to get a ValueEncoder from ValueEncoderSource.
 This will fail if, for instance, the loop's value is a hibernate entity with a multi-column
PK, even if the developer binds a custom ValueEncoder to the parameter to handle the entity.
Admittedly, this case has a workaround: contribute the custom encoder to ValueEncoderSource.
 But that's only one edge case.
> The correct solution is to lazily evaluate defaultXXX methods. 

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message