Requesting data from mediator (instead of injecting model)

Aaron Hardy's Avatar

Aaron Hardy

19 Feb, 2011 07:14 PM

I suppose this one is mainly addressed to Stray since I want to discuss his approach mentioned here ( and on Twitter but it's definitely open to anyone. I wanted to ask it here in case the discussion could help anyone else as well. More details are on the mentioned thread but just as a recap, here's the general flow I want to discuss:

(1) A model's data gets set. (2) A view is created and added to the stage. (3) The view's mediator is created and needs to get the current data off the model to feed it into the view. (4) Rather than injecting the model into the mediator (creating some coupling), the mediator dispatches an event requesting the data. (5) A command is executing and dispatches a separate event with the data from the model. (6) The mediator receives the event and feeds the data from it into to the view.

This works, but I just want to get a more detailed view of your conventions to see if I can improve mine at all. It seems there are three events types here for a single event class:

WidgetEvent.WIDGET_CHANGED (dispatched from the model)
WidgetEvent.WIDGET_REQUEST (dispatched from the mediator)
WidgetEvent.WIDGET_RESPONSE (dispatched from the command)

The payload would be the widget object.

In my mediator's onRegister() I register a listener for WIDGET_CHANGED and WIDGET_RESPONSE. I use the same handler function for both types that takes the data and feeds it into the view. The handler function also checks to see if the type is WIDGET_RESPONSE and, if so, removes the listener mapping for WIDGET_RESPONSE since we only need/want to hear it once.

Do you have any ideas for simplifying this or maybe some good naming conventions? I'd love to hear them.

  1. Support Staff 1 Posted by Stray on 19 Feb, 2011 07:35 PM

    Stray's Avatar

    Hi Aaron,

    this is pretty much exactly as I do it - except my naming convention is WIDGET_DATA_REQUESTED / WIDGET_DATA_SUPPLIED.

    But yes, this is exactly the 'request / response' pattern that I bang on about :)

    The relaxedEventMap utility does away with the need for this approach by keeping a history of events that have fired. When you add a handler the relaxedEventMap first checks if it already has an instance of that event - if it does then it runs the handler immediately, supplying the most recent instance of that event.

    Obviously you have to tell it which events you'd like to 'time shift' in this way, but after that it's just like using the normal event map really.

    I like both approaches - the extra workload (relative to injecting the model) in each case is relatively similar (tiny).

    I should put a disclaimer here that the rest of the robotlegs team are more pragmatic than me about mediator injection. I think binding to events/vos in mediators pays rewards in terms of keeping your approach consistent and your individual mediator classes really simple. Others think it's a PIA :)

    My philosophy is that writing events, relay Commands and mediator handlers that just use the view API is the kind of code we can do in our sleep (and if we have a good IDE then it does 90% of the work). It's very low-overhead and unlikely to ever end up costing you a day in debugging, and it really helps you focus on decoupling.

    In over a year of writing robotlegs code daily I've yet to regret using this pattern, and I have got some regrets about the (early) occasions when I injected the model into my mediator.

    I recently refactored that out of some of the oldest code in our app because I needed to add this specific view earlier in the app startup process (or do a very complex workaround for layering reasons). Of course everything blew up because the model wasn't ready at the point at which the view hit the stage. Events let you decouple from the order-of-things as well as the API. Win!


  2. 2 Posted by Aaron Hardy on 19 Feb, 2011 08:08 PM

    Aaron Hardy's Avatar

    Thanks Stray. Your input is always appreciated and you're a great community contributor.

    In my experience, I've found it awkward to both watch for a WIDGET_CHANGED from the event dispatcher and feed my initial data from the model. I've felt like I've been saying, "My mediator isn't tied to the origin of the data because I'm using events--woohoo!...but...not really because I'm pulling my initial data off model X."

    Honestly I'm still in the process of warming up to the idea because it's somewhat more tedious at first but I feel like it's probably worthwhile for larger projects.

    Thanks again!

  3. Aaron Hardy closed this discussion on 19 Feb, 2011 08:09 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac