GXT Beta 4: Changes to SelectionChangedListener

[flow]

Hi Darrell,

why is it that the former existing interface SelectionChangedListener is now replaced by the concrete class SelectionChangedListener (which implements the interface Listener<SelectionChangedEvent<ModelData>>)?
Until now, my views implemented the Interface SelectionChangedListener to react on any changes (let's say in tables), which was IMO quite convenient. Or was this the wrong approach? What's the idea behind it?

Thanks for clarification,
Flo~

[flow]

My other approach would be to let the View implement Listener<SelectionChangedEvent<M>>. But unfortunatelly, the StoreBinder expexts an instance of the SelectionChangedListener!

  
public void addSelectionChangedListener(SelectionChangedListener listener) {
    addListener(Events.SelectionChange, listener);
  }

I suggest to change the signature of the method to something like

  public void addSelectionChangedListener(Listener<SelectionChangedEvent<M>> listener) {
    addListener(Events.SelectionChange, listener);
  }

[jraue]

I am considering changing my Implementations of SelectionChangedListener<M> to inner classes that extend SelectionChangedListener, but IMHO this is not as nice as it was before. Are there any best practices on how to solve this best? Darell, maybe you can provide us with insight on why this has been changed and what are its advantages?

Thanks a lot in advance,
Joachim

[Grandiosa]

+1

At least the SelectionChangedListener should be made abstract so my IDE can automatically create a body for the anonymous class.

[flow]

Any new opinions about the discussion "SelectionChangedListener"?