[
https://issues.apache.org/jira/browse/WICKET-6348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17164187#comment-17164187
]
Martin Tzvetanov Grigorov commented on WICKET-6348:
---------------------------------------------------
{quote}Doesn't
[https://cwiki.apache.org/confluence/display/WICKET/DropDownChoice+Examples]
still have the previous behavior?
{quote}
The Wiki is maintained by the community, not just by the team. You are welcome
to help!
{quote}And the migration guide, wicket examples, Wicket Guide, have those also
been updated?
{quote}
Yes, we keep it up-to-date. But again you are always welcome to send a Pull
Request with improvements:
[https://github.com/apache/wicket/tree/master/wicket-user-guide]
{quote}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).
{quote}
The old tree is still available at
[https://github.com/wicketstuff/wicket1.5-tree]. It has been replaced 5-6 years
ago. You are right about TreeModelProvider, it still uses Swing APIs, but since
no one complained (until today) we didn't bother (as you recommend - we do not
make unneeded changes).
{quote}Dropping of AbstractValidator - not mentioned that I could find in the
migration docs
{quote}
Which migration docs you have checked ? I'm asking because it seems you didn't
check the migration doc for Wicket 8.x about
wantOnSelectionChangedNotifications.
To help you out:
[https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-(M4)IBehaviorinterfacerefactoredtoabstractclassBehavior]
{quote}his change here (WICKET-6348) which was not requested by your customers,
the community. It is documented here as onSelectionChanged() but is actually
onUpdate().
{quote}
We (Wicket developers) are also users of Wicket, so we are customers
{quote}Slow down the rate of change to what is absolutely required
{quote}
Every change comes from users' feedback and/or personal needs. If it is not
needed by *you* this doesn't mean no one else needs it!
{quote}Spend less time coding and more time documenting
{quote}
Spend less time ranting, more time reading the documentation!
{quote}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.
{quote}
Wicket's user guide has been extracted from ComSysto's guide (Andrea Del Bene's
work) several years ago and many new topics have been added since then.
In general I would like to thank you for spending your time writing this
feedback!
Just one note: be better prepared next time and a little bit more polite!
Most of the people who work on open source projects do this in their spare
time.
This does not mean that their work is less professional than paid workers. IMO
most of the time it is even the opposite!
When you don't know how to do something (coding something new or migrating
code) it is better to ask than to attack (by saying things which are not quite
true). Maybe this is not what you meant but this is how it looks like.
Good luck!
P.S. I guess you will have more questions in the (near) future - please ask
them in [[email protected]|mailto:[email protected]]
([https://wicket.apache.org/help/email.html#user]) ! As I recently said in
https://issues.apache.org/jira/browse/WICKET-6804 - JIRA is not the best place
for such conversations.
> 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)
