Using the Event Hub

Event Hub is useful for blades that want to communicate with each other. It is a publish-subscribe event service, useful to decouple components as the two parties communicate through an interface. This tutorial provides examples of situations in which you might want to use the Event Hub, and shows you how to implement one of them.

There are various situations where you would want to use the Event Hub, such as:

  • Dragging from one blade and dropping in another

  • Logging from multiple blades onto a single "log viewer" blade

  • A "theme selector" blade telling all other blades to render to a new theme

We are going to show you how use the Event Hub to send and receive log messages. For this example, the sending and receiving will take place in the same blade, but the Event Hub works just as well with the sending being handled in one blade, and the receiving in another.

To follow this tutorial, create a new bladeset called eventhub, then create a new blade called hub. In this example, the namespace of our blade will be tutorial.eventhub.hub.

Sending Messages

Actually, the template blade created by BladeRunner already uses the Event Hub to send a message to the "Messages" log console when the button is clicked

base eventhub start

Here’s the code that achieves this in $BLADE_ROOT/src/tutorial/eventhub/hub/ExampleClass.js

tutorial.eventhub.hub.ExampleClass.prototype.buttonClicked = function()
{
     var proxy = caplin.core.ServiceRegistry.getService("caplin.event-service").getProxy
         ("caplin.workbench.model.WorkbenchEventListener", "caplin");
    proxy.logEvent("button clicked", "", {"greeting" : "Hello!"});
}

You can see the code getting the proxy for the caplin.workbench.model.WorkbenchEventListener and calling the method logEvent(). By using an interface, it’s clear which methods are available to call. Note that it passes the event group of "caplin". Event groups exist to allow multiple senders and receivers to use the same interfaces for different types of event. One example of this would be to allow fine-grained logging for all classes. Each class could post messages on its namespaced class name. Receivers could use use a regex to subscribe. Listening to caplin.* would get all log messages for all Caplin classes and not receive messages in other namespaces.

Receiving Messages

For our trivial example let’s create a new class that is a caplin.workbench.model.WorkbenchEventListener. We’re calling it tutorial.eventhub.hub.EventListener

tutorial.eventhub.hub.EventListener = function()
{
    caplin.core.ServiceRegistry.getService("caplin.event-service").subscribe
        ("caplin.workbench.model.WorkbenchEventListener", "caplin.*", this);
};
caplin.implement(tutorial.eventhub.hub.EventListener, caplin.workbench.model.WorkbenchEventListener);

tutorial.eventhub.hub.EventListener.prototype.logEvent = function(sEventName, sDirection, vData)
{
    alert(sEventName);
};

Receivers actually implement the interface. Here, the listener is subscribing to any events with the Event Group of caplin.*. This regex matches the event we registered for logging earlier, so it will catch events from our ExampleClass.

To add a new EventListener to the workbench, add the following line of code in the create() method in $BLADE_ROOT\workbench\src\tutorial\eventhub\hub\workbench*ExampleBladeApplication.js*

this.m_oEventListener = new tutorial.eventhub.hub.EventListener();

After creating a new EventListener in the workbench, clicking on the button gives the following results:

base eventhub finish

Note that our ExampleClass gets the event first, which is why the "messages" console in the screen shot is empty.