You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Sven Meier (JIRA)" <ji...@apache.org> on 2017/03/29 09:20:41 UTC

[jira] [Created] (WICKET-6348) extract #onSelectionChange() from choices to behavior

Sven Meier created WICKET-6348:
----------------------------------

             Summary: extract #onSelectionChange() from choices to behavior
                 Key: WICKET-6348
                 URL: https://issues.apache.org/jira/browse/WICKET-6348
             Project: Wicket
          Issue Type: Improvement
          Components: wicket
    Affects Versions: 8.0.0-M4
            Reporter: Sven Meier
            Assignee: Sven Meier
            Priority: Minor


Several choice components support notification via normal HTTP request when their value changes in the browser:

- DropDownChoice
- RadioChoice
- CheckGroup/Check
- RadioGroup/Radio

I'd propose to move support for this feature into a new behavior.
This has the following advantages:

- having to override #wantOnSelectionChangedNotifications() for #onSelectionChanged() to be triggered wasn't very intuitive anyway
- we minimize the API of these components
- we can simplify these components by removing from them this non-core concern (a legacy from the pre-Ajax era)
- to use the feature users can add a behavior instead to have a notification triggered on *that* behavior (similar to AjaxFormComponentUpdatingBehavior/AjaxFormChoiceComponentUpdatingBehavior)

I reused IFormSubmitter (for SubmitLink too) so we can now simplify Form:
- no need for the hidden field "_hf_0" (the form's action is changed instead)
- no need for #dispatchEvent()
- #getJsForInterfaceUrl() (now #getJsForListenerUrl()) is greatly simplified



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)