Understanding the the View and Mediators.

Almog's Avatar


02 Sep, 2010 03:21 PM

Hi I'm a new user to Robotlegs trying to better understand everything so far been reading and testing out a number of things really liking it I do have a couple simple questions.

Whats a best practices to have my event listeners and there functions inside the view or component class? or should all event listeners be inside the mediator?

If all the events relating to a specific view are in the that view which makes sense how does the mediator listen to them, do I need to dispatch an event to the mediator which then would dispatch another event to the framework or another mediator. This seems a little overhead on performance.

Can I work events from other class or frameworks like FLARManger or does everything need to be custom events?

  1. 1 Posted by Omer Hassan on 03 Sep, 2010 02:56 PM

    Omer Hassan's Avatar

    Hi Almog,

    I must say that I am a new user of robotlegs too but I think I have the answers to your questions.

    Mediators should register and define all event listeners related to their views.

    The view shouldn't dispatch events to a mediator; mediator is supposed to know everything about the view but I assume the view isn't supposed to be aware of mediator's existence.

    You can dispatch and listen to all sorts of events - not just custom events. For example, you can make your mediator listen to click events dispatched by its view.

  2. 2 Posted by Stray on 03 Sep, 2010 03:27 PM

    Stray's Avatar

    Hi Omer,

    I'm not sure that the mediator is supposed to know everything about the view. Personally I use signals between the view and the mediator to avoid exposing properties that the mediator has no business knowing about - though there's not a 'right' way, and as mediators are framework glue not designed to be decoupled, a degree of view-mediator coupling is fine.

    Where it gets sticky is if your view has 3 buttons - for example a login screen might have 3 buttons: Submit / Cancel / Forgot password

    You can expose these buttons, and then in the mediator you can listen for a click on each button. And, if the submit button really starts a process which requires the username and password field data, then you could expose these fields, or add public methods to get their contents...

    But I think using a signal, where you can dispatch the username & password in that signal, is preferable.

    However, it's fine also for the view to dispatch events that the mediator can listen for. If i didn't want to use signals I would be more likely to dispatch a LoginPanelSubmitEvent from the view than to expose view internals. This doesn't have to be a framework event - I'd say it's preferable if it isn't, and you could then use the data on it to create the framework's LoginSubmitEvent and dispatch that onto the framework eventDispatcher. This keeps your view development separate from your application logic development, so you can reuse that view with a totally different app in future.

    You're absolutely correct that the view shouldn't have a clue that the mediator exists. I'm pretty sure that views are inherently self-centered and should only care about themselves and their children.

    I hope this is helpful,


  3. 3 Posted by Omer Hassan on 03 Sep, 2010 03:45 PM

    Omer Hassan's Avatar

    You made a good point about reusability, Stray. It convinces me that it is usually better for views to dispatch specialized events rather than the mediators having to look too deep inside the view. But as I type this, I just started wondering, if the view is dispatching a specialized event, the mediator's work will be greatly reduced, often to nothing but passing that event on so that a command registered with that event can get fired. But then again, totally depends on your application. View dispatching custom events doesn't always have to do whole of the mediator's job.

  4. 4 Posted by Almog on 04 Sep, 2010 10:34 AM

    Almog's Avatar

    Hi Omer and Stray,
    This is exactly what I'm trying to understand both of you made some great points.

    When I think of it would prefer that the mediator would be in charge of the events in the view however trying to work with FlarManger this isn't really possible and I have run into a number of issues.

    So the other option would be to have the view dispatch an custom event or use Singles, using singles which is adding another framework seems a bit of extra overhead when it's not required.

    Dispatch a custom event to the mediator is great, but this makes me ask why I need my mediator. My view is already doing all my event handling why not send it straight to a command. At the end of the day you don't want to dispatch to many events and it seems that mediator doesn't really do anything.

    Here is my event counts per option, (one event/button)
    If the view is in charge of the event and sends it to the mediator - I have 5 events.
    If I'm using singles - 7 events
    Mediator does the event handling - 2 events
    View to command - events

  5. 5 Posted by Arturo on 04 Sep, 2010 11:37 AM

    Arturo's Avatar

    Just adding my two cents.
    "Best Practices" is what best fits you, and your project. There really isn't ONE solution and ONE way to do things the "right" way. Build things in a way that make sense to you and your projects, and not necessarily to follow one specific pattern. The "right" way is the way that get's things done.
    Don't use an IOC framework because that's how you should do it, use it because it helps you accomplish your goals. You don't have to use mediators in RL. You can certainly follow a PM approach if you like, or do all the framework talk from the view if you like. Mediators and Presentation Models allow you to decouple your View from the logic, but they take an extra step, is it worth it? Also Flex 4 has a built in alternative to accomplish the same goal, "skins".

    My question to you is, how often do you reuse your views? If the view you are working on has a reasonable chance of getting reused, then mediators and PMs make sense. If you wish to leave a trail of how things are tied together, then mediators make sense, but be aware that they are an extra, possibly unnecessary extra step. Mediators have a particular benefit (depending on your point of view) they certainly do allow you to depend less on binding. Binding makes sense in many situations , but it's not ideal for everything.

    What you choose depends on you, your team, and your project.

  6. 6 Posted by Almog on 04 Sep, 2010 11:42 AM

    Almog's Avatar

    Currently I'm looking at using singles, I'm starting to see the befits for this even with extra overhead. I will test out the performance and see how it with my current applications.

    As for best practices I'm not sure I agree with your approach yes at the end of what works for you is good however I believe each project needs to have a certain type of MVC.

  7. 7 Posted by Arturo on 04 Sep, 2010 02:27 PM

    Arturo's Avatar

    Yeah, I'm going to have to take a better look at singles.

    My point wasn't against MVC. It's against following anything for the sake of following because it's the way that it's "supposed" to be done. You, are not a machine, you have the ability to create, think, imagine, compare, evaluate, judge, and my point is that you should use those abilities freely.

    MVC isn't for everything. You would probably not want to use and MVC concept on the server side if the client is expecting a synchronous response.

    My point was, ask for alternate options and "WHY" they like it, and YOU be the judge of what is best for you and for your projects. "Best" is subjective.

    All of the "smartest" people in the world have been wrong at some point in time, or some of their thoughts don't apply everywhere, or for eternity.

    MVC's main benefit is decoupling, but that does come at a price, it does tend to obfuscate an application. An MVC application is much more difficult for someone new to the project to follow. Robotlegs does help reduce the level of obfuscation with it's context and mediator files, they give you a clue, but more work is required to create them. There is no free lunch, and most certainly there is no "Best" for everything.

    Don't forget what your main goal is: get work done.

    Here is a short note from Kellan Elliott-McCrea from Flickr

    In other words, use whatever helps you get things done.

  8. 8 Posted by Stray on 05 Sep, 2010 12:34 PM

    Stray's Avatar

    It's 'signals' rather than 'singles' - but by either name AS3Signals are worth checking out :)

    The beauty of signals is that they help you maintain appropriate relationships (knowledge, and influence) between your views and your framework.

    If you expose your buttons to the mediator then the mediator can (in theory) move them, fade them, rotate them, scale them... when all the mediator needs to do is react appropriately to the event: 'the user did this action'. If you listen for clicks on the whole view, but then check the event for target type or name to find out which button was clicked, your mediator needs to know details that are unimportant to the work it has to do.

    Signals allow you to expose exactly the thing the mediator needs to know, with - for example - saveClickedSignal, cancelClickedSignal, deleteClickedSignal etc.

    Most of the time a simple, unextended, signal is sufficient.

    As Arturo says, there's no one-size-fits-all solution. Your priorities will depend on the project but also on yourself.

    Personally I use TDD for everything - even seemingly banal things - and I like a large number of small, very, very well defined classes. The reason for this is that I run a team and a small business, I'm on support retainer to a couple of clients, and I have a teenage kid and a dog. The occasions when I get more than 20 minutes of uninterrupted concentration are fairly rare! So I need a programming style and workflow that chops my work up into tiny bites, so that I can actually 'complete' a unit of work within a 20 minute window.

    You might have a totally different workflow and that would change your requirements. We'd like to think that there's a 'best practice' but really it's best for you that counts (as long as your absence from the project wouldn't completely kill it - other people have to be able to make some sense of your work too).

    The beauty of Robotlegs is that it's so flexible - you can use it how you need to.


  9. 9 Posted by Almog on 05 Sep, 2010 02:35 PM

    Almog's Avatar

    Thanks, Stray made some great points and yes I miss spell a lot. I can say so far my experience with RobotLegs has been really good for that same reasons it's doesn't lock you down and is very flexible one thing that I didn't like about PureMVC is that it does lock you down.


  10. Almog closed this discussion on 06 Sep, 2010 04:44 AM.

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