View Full Version : BaseEvent/AppEvent type

11 Jun 2008, 5:33 AM
Why is the type of a Event Integer? The use of enum would be type safe and is also comparable.


11 Jun 2008, 1:33 PM
The enum is only good if you know all possible values. The base event and app events need to support both library events and application defined events, therefore, the enum would not work.

11 Jun 2008, 10:27 PM
You could write your own enum with a int getType() and a AppEvent subclass like this :

public class MyEvent<Data> extends AppEvent<Data>
private final MyEnum enumType;

public MyEvent(MyEnum type) {
this(type, null);

public MyEvent(MyEnum type, Data data) {
this.data = data;
this.enumType = type;

public MyEnum getEnumType(){
return enumType;

11 Jun 2008, 11:25 PM
Please look at the code listed below. It uses the Enum as type of an Event. The advantage of using Enum here is that I can't declare the same type of event for different events. As an example I am building a large web application which exists of multiple modules which are not only built by me. With the use of an Integer there can be two events (INIT and UPDATE) assigned to the same Integer value. This won't give an error when the modules are put together but gives you unexpected results. In my opinion it also improves the easiness of developing the Ext GWT library.

Of course I could write my own class and I did for the project. But I think using the Enum type would improve the Ext GWT library. That’s why I posted it in open discussion.

public class Event {

private final Enum<?> type;

public Event(Enum<?> type) {
this.type = type;

public Enum<?> getEventType() {
return type;

public enum Events {

public enum AppEvents {

public class EventUse {

public EventUse() {
new Event(Events.ONCLICK);
new Event(AppEvents.INIT);

12 Jun 2008, 12:51 AM
+1 ! Good idea !! =D>
I didn't know about the Enum inheritance ! It would be really nice to replace the BaseEvent type attribute with an Enum<?>.

12 Jun 2008, 1:50 AM
+1 Mmmm me like em too

12 Jun 2008, 4:57 AM

12 Jun 2008, 6:05 AM
I like this as well. We will have to provide GWT event enums, and then translate the native GWT int types.

Have any of you seen the new proposed event system that is going to be in the GWT incubator project?


So I think we have 4 choices:

1. Do nothing
2. Update to Enum design
3. Update to Enum design, and update again when new GWT code once available
4. Update to GWT design once code is available

What do you all think?

12 Jun 2008, 12:15 PM
option 3 unless 4 is going to happen "anytime real soon"

12 Jun 2008, 10:34 PM
Wow, I didn't realize that BaseEvent was closely related to the GWT Event. Darell, do you have some idea on when will the new event system come into GWT ? I guess we'd have to wait for months so I'd be in favour of option 3.

13 Jun 2008, 12:17 AM
I think option 3 is the best option because it can take a long time before the new event system is implemented in GWT. Besides that an important qeustion would be if you gonna change your entire event system to work with the new GWT event system or just build an wrapper so the event system that you have can communicate with the new GWT event system?

15 Jun 2008, 10:40 PM
By the way, Darell, there are still public fields in BaseEvent and AppEvent ;)

18 Jun 2008, 4:44 AM
Actually, for a more type-safe solution, I think we should write an AppEvent subclass for every AppEvent type we want to handle in our application and then rely on neither Integer nor Enum. One thing is missing with the Enum solution : an enum cannot be parameterized and so we cannot mention the event data type. With a subclass, we get it :

public class EditCustomerAppEvent extends AppEvent<EditCustomerAppEventData>{
}But I wonder about performance. If we rely on polymorphism, in handleEvent method, I think we have to test with instanceof keyword, right ? I guess this is translated to typeof in Javascript (instead of integer equality), can this be a performance issue ?

Thoughts ?

18 Jun 2008, 5:40 AM
Another interesting fact is that, as far as I know, AppEvent instances are only used in Controller/View/Dispatcher/MvcEvent. It seems that AppEvent is NEVER used as a sub-BaseEvent. I think it could (and probably should because I don't think Darell want us to be able to fire AppEvents to Components, am I wrong, Darell?) be a top class and be completely independent of all the BaseEvent/GWT event stuff.

If I'm not mistaking, IMHO, the int type attribute could then be replaced by an Enum one. Or, as I said in my previous post, it could be simply deleted and we could rely on the real type of the object instead of a fake type attribute (I guess this second option is more robust).

25 Jun 2008, 11:10 PM
The enum is only good if you know all possible values. The base event and app events need to support both library events and application defined events, therefore, the enum would not work.

Do app events really need to support library events ?

31 Jul 2008, 4:55 AM
Darell, what did you decide on that point ?

31 Jul 2008, 8:39 AM
I like the idea of using enums within the event system. The event and listener design will not be changed in 1.0, however, changes may be made in 2.0.

31 Jul 2008, 11:29 PM
Ok. Thanks.