[
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
"FormComponentUpdatingBehavior".
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)
- can be used for text components too
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 FormComponentUpdatingBehavior() {
protected void onSelectionChanged() {
// do something, page will be rerendered;
}
});
{code}
was:
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}
Summary: New FormComponentUpdatingBehavior to replace
wantOnSelectionChangedNotifications() (was: extract #onSelectionChange() from
choices to behavior)
> New FormComponentUpdatingBehavior to replace
> wantOnSelectionChangedNotifications()
> ----------------------------------------------------------------------------------
>
> 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
> "FormComponentUpdatingBehavior".
> 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)
> - can be used for text components too
> 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 FormComponentUpdatingBehavior() {
> protected void onSelectionChanged() {
> // do something, page will be rerendered;
> }
> });
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
