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

["Sven Meier (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-6348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sven Meier updated WICKET-6348:
-------------------------------
    Description: 
Several form components support notification via normal HTTP request when their value changes in the browser:

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

I 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
- we minimize the API of these components (the two methods above and #onRequest())
- 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 AjaxFormChoiceComponentUpdatingBehavior)

I reused IFormSubmitter to submit the form (for SubmitLink too) so we can simplify Form now:
- no need for the hidden field "_hf_0", used to transport the actual listener url - the form's action is changed instead
- no need for #dispatchEvent(), used to schedule another request handler that triggers the component
- #getJsForInterfaceUrl() is greatly simplified (renamed to #getJsForListenerUrl() now) 

Migration effort is manageable:

{code}
new CheckBox("id", model) {
	protected boolean wantOnSelectionChangedNotifications() {
		return true;
        }

	protected void onSelectionChanged(Boolean newSelection) {
		// do something, page will be rerendered;
	}
};
{code}

... becomes:

{code}
new CheckBox("id", model)
.add(new SelectionChangedBehavior() {
	protected void onSelectionChanged() {
		// do something, page will be rerendered;
	}
});
{code}

  was:
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


> 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 form components support notification via normal HTTP request when their value changes in the browser:
> - CheckBox
> - DropDownChoice
> - RadioChoice
> - CheckGroup/Check
> - RadioGroup/Radio
> I 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
> - we minimize the API of these components (the two methods above and #onRequest())
> - 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 AjaxFormChoiceComponentUpdatingBehavior)
> I reused IFormSubmitter to submit the form (for SubmitLink too) so we can simplify Form now:
> - no need for the hidden field "_hf_0", used to transport the actual listener url - the form's action is changed instead
> - no need for #dispatchEvent(), used to schedule another request handler that triggers the component
> - #getJsForInterfaceUrl() is greatly simplified (renamed to #getJsForListenerUrl() now) 
> Migration effort is manageable:
> {code}
> new CheckBox("id", model) {
> 	protected boolean wantOnSelectionChangedNotifications() {
> 		return true;
>         }
> 	protected void onSelectionChanged(Boolean newSelection) {
> 		// do something, page will be rerendered;
> 	}
> };
> {code}
> ... becomes:
> {code}
> new CheckBox("id", model)
> .add(new SelectionChangedBehavior() {
> 	protected void onSelectionChanged() {
> 		// do something, page will be rerendered;
> 	}
> });
> {code}



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