(3.0.0.RC) Broke ComboBox API regarding Handler/Event inheritance

[kenhwallis]

Your release notes do not indicate that you changed the inheritance classes of the SelectionHandler and SelectionEvent. In Beta4, these were the Google classes. In RC, they are now Sencha GXT classes but without extending the original Google equivalents.

Your premiss presented was that all Sencha widgets would work with the Google event and handler classes.

The change you have made breaks client implementation code.

[WesleyMoy]

This is a topic that has already undergone some discussion here in the forums. See http://www.sencha.com/forum/showthread.php?p=772620.

In short, we are often limited by the amount of information that a GWT event can carry. When the amount of information simply isn't enough, we replace that event with one of our own making. There's no good way around this, and you'll see in the thread linked above that we've changed the approach that we will be taking in the next release. Instead of using our own event with the same descriptive name that GWT uses, we're using a different event altogether that does extend the existing GWT events.

[kenhwallis]

During 3.0 testing there have been multiple threads discussing the faulty implementations involving the ComboBox and the failure to implement behaviours expected by users. The thread you mention identifies a new event to be thrown but does not state that the existing one will be discontinued or significantly altered. Further, as I stated, the release notes do not state the change to the API introduced in the RC.

By bypassing the GWT events, you break code inheritance and the very Object Oriented Programming intention.

As stated previously, http://www.sencha.com/forum/showthre...ng-as-expected..., Sencha should implement the ComboBox using the expected functionality, should only change the API with proper disclosure & community consent, and should follow OOP best practices for class inheritance especially when the same class name is reused.