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:
new CheckBox("id", model) { protected boolean wantOnSelectionChangedNotifications() { return true; } protected void onSelectionChanged(Boolean newSelection) { // do something, page will be rerendered; } };
... becomes:
new CheckBox("id", model) .add(new FormComponentUpdatingBehavior() { protected void onSelectionChanged() { // do something, page will be rerendered; } });
Attachments
Issue Links
- causes
-
WICKET-6642 Form.findSubmittingComponent returns null instead of SubmitLink
- Resolved
- relates to
-
WICKET-6352 Clean-up BaseWicketTester listener invocation/execution
- Open
- mentioned in
-
Page Loading...