[
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, 3:00 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 (WICKET-6348) which was not requested by your customers,
the community. It is documented here as onSelectionChanged() but is actually
onUpdate().
I'm mentioning only some of the pain points I've run into. It has become a
major effort 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 Dashorst 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, 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 effort 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 Dashorst in 2016 has helped me out.
https://events.static.linuxfound.org/sites/events/files/slides/Whats%20up%20with%20Wicket%208%20and%20Java%208.pdf
> 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)
