Stephen,
This is *awesome*. I recently picked GWT back up...but I couldn't *stand*
digging these glorified ditches called Events (and all their gorp) and
Handlers.
I've just started playing with it and look forward to working with @GwtEvent
and @GwtDispatch.
Thanks!
--
You received this
And that could easily be resolved by keeping all your types in the
same place:
EventTypes.PLACE_CHANGE
EventTypes.VALUE_CHANGE
Could this pattern also be enhanced with a sense of payload?
something like the following:
public class GenericEventP extends GwtEventGenericEvent.Handler {
public
It is a bit of a nuisance maintaining two java files for each event.
I agree that GWT events involve a lot of boilerplate.
My approach was to write an annotation processor (native Eclipse/javac
support) where you just write a spec:
@GenEvent
public class CalendarChangeRequestEventSpec {
public class GenericEvent extends GwtEventGenericEvent.Handler {
This is very tangential, but all the talk about a generic event made
me think of a paper a colleague of mine linked me to about potential
design patterns for UI listeners in Scala:
On 28 juin, 17:50, Paul Schwarz paulsschw...@gmail.com wrote:
Thanks Phil, though what would this look like in this case?
The design of the GwtEvent and TYPE being static is actually very
powerful in its elegant simplicity. A call to the constructor of
GwtEvent.Type() actually causes an int
Another simple trick I use when I need multiple events that have the
same payload and handler methods, is to not declare the TYPE as a
static member of the event. Instead I declare it elsewhere (anywhere
really) and pass it to the event's constructor. Really simple, but can
dramatically cut down
Thanks for the crits Thomas, I've learned something from this: keeping
handlers together in a given class. That's quite neat because really
what I was driving at is not so much optimising output of the GWT
compiler, but more cutting down on the cognitive load on the developer
and time it takes
Thanks Phil, though what would this look like in this case?
The design of the GwtEvent and TYPE being static is actually very
powerful in its elegant simplicity. A call to the constructor of
GwtEvent.Type() actually causes an int to be incremented and this
becomes the hashCode ID of this event
When using the EventBus, for each event type in your system you will
create a Class (a GwtEvent) and an Interface (the corresponding
EventHandler).
It is a bit of a nuisance maintaining two java files for each event.
So I propose to simplify it by having one abstract event class and
then ONLY ONE
A few comments
On 27 juin, 13:53, Paul Schwarz paulsschw...@gmail.com wrote:
When using the EventBus, for each event type in your system you will
create a Class (a GwtEvent) and an Interface (the corresponding
EventHandler).
It is a bit of a nuisance maintaining two java files for each
10 matches
Mail list logo
