If you read my series on GWT dependency injection (parts: first, second and third), maybe you remember that, in part 3, I mentioned how convenient would be to reduce the boilerplate required to define events in GWT. I also mentioned how elegant I find the event definition in CDI. Wouldn’t it be nice to have a lightweight event model like that in GWT?
Let’s see first how an event is defined and handled in CDI:
public class CDISample {
@Inject
private Event<String> event;
public void handler(@Observes String payload) {
System.out.println(payload);
}
public static void main(String[] args) {
event.fire("Hello event world!");
}
}
As you can grasp from the code, to define a new type of event in CDI it is enough to define an injected field of the parametrized class Event and the CDI container will do all the wiring for us. The parametrized type of the event defines its payload type by mean of the type parameter. To listen to the event, we just need to define a method that receives a parameter of the event payload type and annotate it with “@Observes”.
While exactly this is maybe not doable in GWT (at least not yet), what about something like this?:
public class GWTSample {
@Inject
private SampleEvent event;
public void execute() {
event.dispatchTo(new Handler<String>() {
public void onEvent(String payload) {
Window.alert(payload);
}
});
event.fire("Hello event world!");
}
public interface SampleEvent extends Event<String> {
}
}
While I can agree with you that it is not as elegant as the events approach in CDI, it is (IMO) a big improvement compared with, for instance, the ping / pong event definition in the demo application of my GIN series (source code
here):
public class PingEvent extends GwtEvent<Handler> {
public static Type<Handler> TYPE = new Type<Handler>();
@Override
public Type<Handler> getAssociatedType() {
return TYPE;
}
@Override
protected void dispatch(Handler handler) {
handler.onEvent(this);
}
public interface Handler extends EventHandler {
void onEvent(PingEvent event);
}
}
With the new approach, the resulting “PingEvent” would look like this:
public interface PingEvent extends Event<Void> {}
If you are wondering why not to avoid defining the “PingEvent” class itself, two are the reasons:
- First, the events have the same payload type (Void in this case), and therefore we need explicit types to distinguish the ping event from the pong event. This also happens in CDI where we would define explicit payload types instead.
- Second, in this implementation we will be using GWT’s deferred binding and, during the code generation phase, we need to know the parametrized type. Because of Java generics limitations, for this last it is necessary to define a new parametrized type which captures the payload type in its type parameter (wrapper).
Did I convince you? If I did, let’s go on and see how to use deferred binding and dependency injection to achieve it.
Letting GWT generate the boilerplate
Deferred binding in GWT is a really powerful feature implemented in the GWT compiler to substitute class implementations depending in environment properties like the user agent. This way, while the developer has the illusion of using the same classes independently of the browser, the deferred binding mechanism allows to select the adequate implementation for each browser.
Far from being static, deferred binding allows to generate code on the fly by mean of a generator class. This happens when the developer invokes the “GWT.create()” method on an interface. For the operation to succeed, a generator for the interface must exist. This will be invoked during GWT compilation time and its result (one or more Java classes) will be compiled and linked into the resulting JS application.
To configure which generator should be used for which interface, it is necessary to add a new “generate-with” entry in the GWT module descriptor. In the case of the demo application, the following code has been added to the “PingPong.gwt.xml” file:
...
<generate-with class="com.canoo.gwt.events.server.eventsfwk.EventGenerator">
<when-type-assignable class="com.canoo.gwt.events.client.eventsfwk.Event"/>
</generate-with>
...
The contents of the “Event” and “EventGenerator” classes are the following:
public interface Event<T> {
public void fire(T payload);
public void dispatchTo(Handler<T> callback);
public interface Handler<T> {
public void onEvent(T payload);
}
}
public class EventGenerator extends Generator {
private static final String EVENT_IMPL = "EventImpl";
private static final CodeTemplate GWT_SIMPLE_EVENT_TEMPLATE = new GwtSimpleEventTemplate();
private static final CodeTemplate EVENT_IMPL_TEMPLATE = new EventImplTemplate();
@Override
public String generate(TreeLogger treeLogger, GeneratorContext generatorContext, String typeName) throws UnableToCompleteException {
TypeOracle typeOracle = generatorContext.getTypeOracle();
JClassType parentEventType = typeOracle.findType(Event.class.getName());
JClassType eventType = typeOracle.findType(typeName);
JClassType payloadType = findPayloadType(eventType, parentEventType);
String gwtSimpleEventImplName = generateGwtSimpleEvent(treeLogger, generatorContext, eventType, payloadType);
String eventImplTypeName = generateEventImpl(treeLogger, generatorContext, eventType, payloadType, gwtSimpleEventImplName);
return qualifyInGwtEvents(eventImplTypeName);
}
private static JClassType findPayloadType(JClassType eventType, JClassType parentEventType) {
JClassType interfaces[] = eventType.getImplementedInterfaces();
for (JClassType anInterface : interfaces) {
if ((anInterface instanceof JParameterizedType) && (anInterface.getErasedType() == parentEventType.getErasedType())) {
JParameterizedType parametrizedType = (JParameterizedType) anInterface;
return parametrizedType.getTypeArgs()[0];
}
}
throw new IllegalStateException("Payload type not found for: '" + eventType + "'.");
}
private String generateGwtSimpleEvent(TreeLogger treeLogger, GeneratorContext generatorContext, JClassType eventType, JClassType payloadType) {
String gwtSimpleEventImplName = getGwtSimpleEventImplName(eventType);
PrintWriter gwtSimpleEventPrintWriter = generatorContext.tryCreate(treeLogger, getEventsPackageName(), gwtSimpleEventImplName);
GWT_SIMPLE_EVENT_TEMPLATE.generate(gwtSimpleEventPrintWriter, getEventsPackageName(), gwtSimpleEventImplName, payloadType.getName());
generatorContext.commit(treeLogger, gwtSimpleEventPrintWriter);
return gwtSimpleEventImplName;
}
private String generateEventImpl(TreeLogger treeLogger, GeneratorContext generatorContext, JClassType eventType, JClassType payloadType, String gwtSimpleEventImplName) {
String eventImplTypeName = getEventImplTypeName(eventType);
String eventTypeName = getEventTypeName(eventType);
PrintWriter eventPrintWriter = generatorContext.tryCreate(treeLogger, getEventsPackageName(), eventImplTypeName);
EVENT_IMPL_TEMPLATE.generate(eventPrintWriter, getEventsPackageName(), eventType.getQualifiedSourceName(), eventImplTypeName, eventTypeName, gwtSimpleEventImplName, payloadType.getName());
generatorContext.commit(treeLogger, eventPrintWriter);
return eventImplTypeName;
}
... (some methods omitted)
While the “Event” class contains the interface definition for our events and lives in the “client” package of our GWT application, the “EventGenerator” is a GWT specific class that resides in the “server” package of our GWT application. In order to compile the code, we will need to add a new dependency to our project: “gwt-dev-<version>.jar”.
This generator class, by mean of some templates included in the source code, generates the boilerplate classes and saves us the tedious work of writing these classes. If you want to see this in detail, please refer to the “eventsfwk” packages in the client and server part of the application (source code here).
Using GIN to bring everything together
Following what I mentioned until now, it seems that if we define an interface extending the “Event” interface (ex: “SampleEvent”) and we use the generator to generate and wire the code by mean of “GWT.create(SampleEvent.class)”, we should be able to use the result as shown in the “GWTSample” execute method. Not really.
One piece that is missing in the puzzle is which event bus should the underlying GWT events use. We could create an own one without loosing functionality but a better thing that we can do is to provide an injection point and provide a mechanism to make our events participate in the application’s dependency injection context and use the application’s event bus instead of an own instance.
To achieve this, we have created a GIN module in the “eventsfwk” package:
public class EventsModule extends AbstractGinModule {
@Override
protected void configure() {
requestStaticInjection(GwtSimpleEvent.class);
}
}
This module should be installed in the application’s dependency context and it will inject an static field in the “GwtSimpleEvent” class which is the event bus used for our improved events. To install it in our application, the injection module has been modified like this (note the line “install(EventsModule.class);”):
@GinModules(Module.class)
public interface Injector extends Ginjector {
public static class Module extends AbstractGinModule {
@Override
protected void configure() {
bind(EventBus.class).to(SimpleEventBus.class).in(Singleton.class);
install(new EventsModule());
install(new GinFactoryModuleBuilder().build(Factory.class));
bindConstant().annotatedWith(named("PingText")).to("Ping");
... (code omitted)
}
This means that, when the dependency injection module is initialized at the beginning of the application execution, the previously configured event bus will be statically injected in the “GwtSimpleEvent” class used by all the generated event classes.
I can not read minds, but maybe you are also wondering why the event fields annotated with “@Inject” get generated and injected. All in all, we don’t call anywhere “GWT.create()” to use the generator class.
Well, we are not doing it but GIN does. Whenever GIN finds a dependency (something annotated with “@Inject”) and that dependency has not explicitly been configured (bound in the GIN modules), GIN invokes “GWT.create()” as fallback strategy. This simple mechanism allows us to generate and inject our event in only one step.
Wow! This post has been “hardcore” GWT, don’t you think? Maybe even too “hardcore”. Please, just let me know if you like it and what do you think about the approach.
See you in a future post!
The source code for the initial version of the application can be downloaded here. The final version here. To see any of the applications working, unzip the corresponding file, change to the folder where the Maven pom file is stored and type the command: “mvn clean gwt:run”. After the GWT “Development mode” application starts, click on the “Launch Default Browser” button.
Comments Off | 
General, Groovy, JavaOne | 
Permalink
Posted by Dierk
