You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "john tal (Jira)" <ji...@apache.org> on 2020/07/23 14:37:00 UTC
[jira] [Comment Edited] (WICKET-6348) New
FormComponentUpdatingBehavior to replace
wantOnSelectionChangedNotifications()
[ https://issues.apache.org/jira/browse/WICKET-6348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163634#comment-17163634 ]
john tal edited comment on WICKET-6348 at 7/23/20, 2:36 PM:
------------------------------------------------------------
Team, how are we documenting this change to the community?
Doesn't [https://cwiki.apache.org/confluence/display/WICKET/DropDownChoice+Examples] still have the previous behavior?
And the migration guide, wicket examples, Wicket Guide, have those also been updated?
https://ci.apache.org/projects/wicket/guide/8.x/single.pdf
As someone upgrading my customers projects from Wicket 1.5 to Wicket 8.8, I am finding the MAJOR changes having been done over time and most are under-documented, some things have simply disappeared with little or no mention.
* Trees - which has now become extremely confusing with ITreeProvider, AbstractTree, IModel<? extends Set<T>> state, really too many choices. I understand a major move was made away from Swing but not completely (e.g. TreeModelProvider).
* Dropping of AbstractValidator - not mentioned that I could find in the migration docs
* This change here which was not requested by your customers, the community
I'm mentioning only some of the pain points I've run into. It has become a major pain/slog to convert code to keep up with Wicket.
I am asking wicket team to please:
* Slow down the rate of change to what is absolutely required
* Spend less time coding and more time documenting
* Find a current Wicket evangelist to write/update a Wicket book. Detailed documentation on the current Wicket is extremely lacking and hurting adoption. http://wicketguide.comsysto.com/ is the best online resource but it cannot keep up with the wicket teams rate of changes.
* I've had to scour the Internet, stackoverflow, etc to get questions answered. This Presentation from Martjin in 2016 has helped me out. https://events.static.linuxfound.org/sites/events/files/slides/Whats%20up%20with%20Wicket%208%20and%20Java%208.pdf
was (Author: bluejaguar):
Team, how are we documenting this change to the community?
Doesn't [https://cwiki.apache.org/confluence/display/WICKET/DropDownChoice+Examples] still have the previous behavior?
And the migration guide and wicket examples, have those also been updated?
As someone upgrading my customers projects from Wicket 1.5 to Wicket 8.8, I am finding the MAJOR changes having been done over time and most are under-documented, some things have simply disappeared with little or no mention.
* Trees - which has now become extremely confusing with ITreeProvider, AbstractTree, IModel<? extends Set<T>> state, really too many choices. I understand a major move was made away from Swing but not completely (e.g. TreeModelProvider).
* Dropping of AbstractValidator - not mentioned that I could find in the migration docs
* This change here which was not requested by your customers, the community
I'm mentioning only some of the pain points I've run into. It has become a major pain/slog to convert code to keep up with Wicket.
I am asking wicket team to please:
* Slow down the rate of change to what is absolutely required
* Spend less time coding and more time documenting
* Find a current Wicket evangelist to write/update a Wicket book. Detailed documentation on the current Wicket is extremely lacking and hurting adoption. http://wicketguide.comsysto.com/ is the best online resource but it cannot keep up with the wicket teams rate of changes.
> 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
> Fix For: 8.0.0-M6
>
>
> 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
(v8.3.4#803005)