:::: MENU ::::

How Robotlegs Keeps me Relaxed with the RelaxedEventMap

While implementing the Robotlegs framework into my first application, I came across a rather common issue: How do I properly manage my views? To give you the basic run-down, my application has a number of different views (menus and various other screens) that need to be shown on the display at different times throughout the application lifecycle. What I wanted was a way to store all of my views, and be able to map events to show a specific view at a given time (ex: a user clicks the logout button in some component, I want the login menu to be shown). Add to this situation the fact dependency injection (while wonderful) has one pretty major flaw: If the object that needs to listen for a particular event is created after the event is dispatched, you end up with a race condition, and the object usually loses (and as such could be shown in an invalid state). For the example of the login menu, let’s say that the use clicks the logout button, the event is fired to trigger a logout command, which then tells the application to display the login menu. This is all well and good unless there is some event that the login menu needs to listen for that gets fired before it is created (ex: The logout Command fires an event to tell the app that the user has logged out and this event contains a message “The users has been logged out successfully” that the login menu is supposed to display). If you’re still managing to follow my confusing-ass example, give yourself a high five!

THE SOLUTION: There is a nice little add-on for Robotlegs called the “RelaxedEventMap.” What this little gem does is give your components a chance to look back in history and pick up events that may have been fired before they were created! So in our example above, if the logout command fired off an event containing the output message, and then fired another event which resulted in the creation and addition of our login menu, if the login menu uses the RelaxedEventMap it will still be able pick up the event containing the message even though it was created after the event was fired.

One lil gotcha: There was one small piece of the ReadMe for RelaxedEventMap that confused me a bit:

“It is also necessary to add a dummy handler to tell the relaxedEventMap to pick up this event. You can do this in your context startup, or in a dedicated bootstrap Command.”

To clarify this a bit more, you will need to add an a listener to the relaxedEventMap for EACH event that you want to be available to components that are instantiated after the event is fired. The “dummy handler” mentioned above will most likely do nothing, so you can use the same method for all of your events if you like, or you can simply use the built-in relaxedEventMap.rememberEvent method which automatically creates a dummy handler for you. Basically, if you want to do something when the event is fired, you map your event to the relaxedEventMap like this:

Otherwise, you just use this method and don’t have to worry about any of the handlers:

I realize that the above may have been a bit confusing, so I highly suggest you browse on over to the Robotlegs site where they have much better documentation about this feature!

UPDATE: Thanks to creynders there is now a port of the RelaxedEventMap in Robotlegs 2!

Robotlegs 1 RelaxedEventMap: https://github.com/Stray/robotlegs-utilities-RelaxedEventMap

Robotlegs 2 RelaxedEventMap: https://github.com/robotlegs/robotlegs-extension-RelaxedEventMap

So, what do you think ?