[ https://issues.apache.org/jira/browse/WICKET-6348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163634#comment-17163634 ]
john tal commented on WICKET-6348: ---------------------------------- 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)