Re: How to simplify your GwtEvent classes and have fun doing it!

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 GenericEvent<P> extends GwtEvent<GenericEvent.Handler> {
public interface Handler extends EventHandler {
void handleEvent(P payload);
}
private final P payload
private final Type<Handler> type;
public GenericEvent(Type<Handler> type, P payload) {
this.type = type;
this.payload = payload;
}
@Override
public Type<Handler> getAssociatedType() {
return type;
}
@Override
protected void dispatch(Handler handler) {
handler.handleEvent(payload);
}
}

I think the only difference would be

eventBus.fireEvent(new GenericEvent<AbitraryObject>(MY_EVENT_TYPE,
object);

The only danger here is that you might get into defining payload
objects the same as you would define event objects outside of this
pattern, but at least they would be isolated from the event handling
semantics. I would also probably enhance eventBus with a method so I
could do the following:

eventBus.fireEvent(MY_EVENT_TYPE, object);

Of course, this is all very theoretical. I don't even know if my code
will compile.

On Jun 29, 9:13 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> 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 to be incremented and this
> > becomes the hashCode "ID" of this event type, and hence assigning that
> > to final static variable (TYPE) give a sort of mapping architecture
> > where GwtEvent implementations are mapped to int IDs and that's how
> > the event bus knows which event has been fired.
>
> > So I'm interested to know what you mean by passing in the TYPE from
> > elsewhere, because you'd have to be careful not to construct two
> > GwtEvent.Type()s to represent a given event type. I'm sure you know
> > this, but for the benefit of others who may try to fiddle with the
> > mechanism and then wonder why their events aren't caught.
>
> I suppose:
> public class GenericEvent extends GwtEvent<GenericEvent.Handler> {
>    public interface Handler extends EventHandler {
>       void handleEvent(GenericEvent event);
>    }
>
>    private final Type<Handler> type;
>
>    public GenericEvent(Type<Handler> type) {
>       this.type = type;
>    }
>
>    @Override
>    public Type<Handler> getAssociatedType() {
>       return type;
>    }
>
>    @Override
>    protected void dispatch(Handler handler) {
>       handler.handleEvent(this);
>    }
>
> }
>
> ...
>
> public static final Type<GenericEvent.Handler> MY_EVENT_TYPE = new
> Type<GenericEvent.Handler>();
>
> ...
>
> eventBus.addHandler(MY_EVENT_TYPE, new Handler() {
>    public void handleEvent(GenericEvent event) {
>       ...
>    }
>
> });
>
> ...
>
> eventBus.fireEvent(new GenericEvent(MY_EVENT_TYPE));
>
> Sure, there's the risk of defining 2 MY_EVENT_TYPE for the same
> "logical" event, but not much more than the risk of defining 2
> GwtEvent.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.