[
https://issues.apache.org/jira/browse/TAP5-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061483#comment-13061483
]
Robert Zeigler commented on TAP5-1549:
--------------------------------------
I could check in my test if you want. It's a simple component with a parameter
named "value" that just prints the value to the page. The component supplies a
defaultValue method that throws a Runtime exception. Then there's a page that
contains the component and explicitly binds the value parameter. In the
current trunk, without my fix (or your code refactoring), you hit the runtime
exception, even though the value parameter is explicitly bound by the page
because the defaultValue method is needlessly evaluated.
> 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
