Thomas,
I could have used those classes, but I wanted to go in a different
direction.
Having used Java's AWT and Swing from the early days, Event classes
and fireXXX methods have been drilled into my brain as the way events
are done. Both Java and GWT based event busses seems to have followed
this path.
My goal in the first article was to show a different approach. An
approach that uses the same listener interface for both publishing and
listening to events. This makes it clear which methods are called on
observers, eliminates event classes (unless you really want them), and
reduces total lines of code. The second article added features I
don't typically see in most event bus implementations: filtering,
topics, generic listeners, and event-based exception handling.
For the GWT event bus, I wanted the same simple, symmetrical approach
along with the additional features above. What I didn't want was
having to add "public static Type<Handler> TYPE = new
Type<Handler>();", "public Type<Handler> getAssociatedType(){...}",
and "protected void dispatch(final Handler handler){...}". I also
didn't want a bunch of GwtEvent subclasses in my application.
There's nothing wrong with the classes you've asked about, just a
different approach for me -- like strawberry vs vanilla.
Cheers,
Dele
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
