[
https://issues.apache.org/jira/browse/WICKET-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Bille Jensen updated WICKET-452:
--------------------------------------
Fix Version/s: (was: 1.3.1)
1.3.2
> AjaxFormComponentUpdatingBehavior.onError forces dummy override of abstract
> onUpdate
> ------------------------------------------------------------------------------------
>
> Key: WICKET-452
> URL: https://issues.apache.org/jira/browse/WICKET-452
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.0-beta1, 2.0 branch (discontinued)
> Reporter: Carlos Pita
> Assignee: Matej Knopp
> Priority: Minor
> Fix For: 1.3.2
>
>
> As of wicket 1.3, the onUpdate event of AjaxFormComponentUpdatingBehavior is
> not called upon validation errors anymore. Instead onError is invoked, both
> for exceptions thrown during event execution and for form component
> validation errors.
> protected abstract void onUpdate(AjaxRequestTarget target);
> protected void onError(AjaxRequestTarget target, RuntimeException e) {...}
> So for ajax validaton I would have to override onError instead, but that
> would be a bit laborious as it's necessary to override the abstract onUpdate
> too; and there is no need of that exception parameter either (which for
> validation purposes will always be null).
> Imo it would be better if I don't have to "dummy out" the abstract onUpdate
> every time just to keep the compiler happy. And maybe if the extra onError
> parameter is not exposed to the event.
> What do you think about an empty default implementation for onUpdate and an
> overload for onError that just takes the target?, these changes would be
> handy for the usual ajax-validation task:
> protected void onUpdate(AjaxRequestTarget target) { }
> protected void onError(AjaxRequestTarget target) { } <-- maybe
> onValidationError?
> protected void onError(AjaxRequestTarget target, RuntimeException e) {
> throw e;
> }
> Notice that for the trunk branch everything said above applies ditto but the
> situation is even worse because onError has private access.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
