Home → Problems →

More Flexible Mediation

• Edit

Doug

23 Apr, 2010 09:13 PM

I'm under the assumption that the purpose of having mediators is to detach behavior logic from your views, in the interest making it easier to make changes and swap things out.
I'm having trouble with this though, due to the way mediators are mapped to classes, rather than to instances.
For example, let's say I have a mediator that makes a movieClip spin on mouseover. And let's say I have another one that makes a movieClip change color on mouseover. Both are designed to mediate MovieClips, so how can I have both in operation at the same time?

1. 1 Posted by Doug on 23 Apr, 2010 09:23 PM

   

   To clarify, I'm not suggesting that class-to-class mediation is bad. I'm just wondering if there's a way to do instance-to-class mediation

   • Edit

2. Support Staff 2 Posted by Joel Hooks on 24 Apr, 2010 02:04 PM

   

   Base classes are a tricky thing with any DI. How do you know which base class you are looking to mediate at any given time? How does the DI provider know which MovieClip to provide to a mediator?

   In this case, your two MovieClips would need to be concrete MovieClip class extensions that exhibit the behavior you are referring to.

   I alluded to using a factory of some sort for mediation. This doesn't exist yet, and was just kind of a thought to address this problem. I don't really know how you'd implement it, or if it would even be a good idea ;)

   I will say that in the 3 years I've used the Mediator pattern with Robotlegs and PureMVC before it, I've never run into the issue you describe. Class to Mediator has always been a one-to-one relationship.

   • Edit

3. Support Staff 3 Posted by Shaun Smith on 24 Apr, 2010 07:26 PM

   

   Hi Doug, thanks for the feedback.

   Those sound more like behaviors than mediators. Typically, when using the mediator pattern, views manage their own internal state (including behaviors, be they swappable or otherwise). The mediator is not designed to tack behavior on to arbitrary view components, but rather to act as a "gateway" between the application (the business end) and the view (the presentation layer). Something like this:

   Application <-> Mediator <-> View

   This lets you design an application that is less dependent on its view (and vice versa). "Relevant" view components are linked back into the application by mediators. By "relevant" I mean important to the application from an architectural perspective. For example, if the app is a document editor we might map a mediator to the DocumentEditWindow, and another to the DocumentFileMenu. Mediated views are usually composite components - things like forms, widgets, toolbars, particular view states.

   The way that a particular UI component presents itself and how it behaves (spinning, changing color): these are implementation details of the view tier. You could be using Flex, your own custom UI framework, a game engine, a set of symbols from a SWC library, whatever works best for the project at hand.

   For example, I'm building a web app that targets Flash Player 10 and I've chosen to use Flex 4 for the UI while I focus on the application logic. Flex lets me build my UI components quickly and lay them out easily, but it adds a lot of weight and eats too much CPU for this particular project. When Reflex (or Slider) is ready I'll be able to swap the Flex view components out of my app and switch over. I won't need to change much (if anything) on the application side, and (aside from building and styling the new components) all I'll need to do is point my old mediators to the new components and compile. In the mean time, the Flex UI is fine, and might even be suitable for release - if I get there before any of the new UI frameworks are ready.

   Anyways, all that stuff aside, the current implementation of the automated mediator map is a bit of a compromise between features and performance. Another MediatorMap could be made with a different API and mapping implementation though, one more suited to manual mediation.

   • Edit

4. 4 Posted by Doug McCluer on 25 Apr, 2010 02:50 PM

   

   Thanks Shaun. So in your example, how are you going to point old mediators
   to new views? Are you injecting your views as interfaces? If the Mediators
   aren't handling any display logic, what do they actually do? What does it
   mean to be a "gateway"?

   • Edit

5. Support Staff 5 Posted by Shaun Smith on 26 Apr, 2010 09:09 AM

   

   I haven't bothered writing actual interfaces for my mediated views, but as long as I implement the same API on the new view components and dispatch the same events, it'll be simple to swap. In essence: the mediators document the view's API as far as the application/framework is concerned.

   By "gateway" I mean that a Mediator sits between the application and the view. The Mediator translates application events into operations on the view, and translates view events into operations on the application. The view doesn't need to know about the application, and the application doesn't need to know about the view.

   For example, a view might dispatch the UI event LOGOUT_BUTTON_CLICKED, which the mediator would translate into the framework event LOGOUT_REQUESTED. The LOGOUT_REQUESTED event might be bound to a LogoutCommand. The view doesn't need to know about this command, and neither does the mediator. We have translated a UI specific event (LOGOUT_BUTTON_CLICKED) into an application event (LOGOUT_REQUESTED). After the logout procedure has completed we might dispatch a LOGOUT_COMPLETE event, and any mediators that are interested in this event would respond to it by calling the appropriate methods on their corresponding view components (a view might be told to remove itself, or to change state). The point is that the application doesn't know or care about these views, it doesn't go around telling view components to close or change state, it merely broadcasts the fact that the logout procedure has completed.

   http://wiki.github.com/robotlegs/robotlegs-framework/best-practices...

   • Edit

6. Stray closed this discussion on 16 Feb, 2011 09:04 PM.