http://gwt-code-reviews.appspot.com/646803/diff/1/16 File user/src/com/google/gwt/dom/client/WebSocketCloseHandler.java (right):
http://gwt-code-reviews.appspot.com/646803/diff/1/16#newcode18 user/src/com/google/gwt/dom/client/WebSocketCloseHandler.java:18: import com.google.gwt.event.shared.EventHandler; On 2010/07/01 16:04:46, tbroyer wrote:
This introduces a dependency from dom to event :-(
EventHandler is just a marker interface for any event handlers. Maybe if we aren't going through HandlerManager we don't need it. http://gwt-code-reviews.appspot.com/646803/diff/1/16#newcode22 user/src/com/google/gwt/dom/client/WebSocketCloseHandler.java:22: void onClose(CloseEvent event); On 2010/07/01 17:59:33, markovuksanovic wrote:
I think CloseEvent specifically doesn't buy anything. I also think it
could be
easily modeled by just using nativeEvent but there are 3 other events
- error,
open, message. MessageEvent contains some specific information not
found in
other events.
I think the model with 4 events (even though it might be almost dead
code in the
other 3 events) is much more intuitive and reflects much better the
WebSockets
browser API.
I think the extra hierarchy doesn't buy us much, and it doesn't all optimize away. I think a reasonable compromise would be pure Java interfaces implemented by corresponding JSOs, so you get mockability for testing without extra wrappers. http://gwt-code-reviews.appspot.com/646803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
