tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/83-more-flexible-mediationRobotlegs: Discussion 2013-04-28T10:02:16Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/15273482010-04-23T21:23:07Z2010-04-23T21:23:13ZMore Flexible Mediation<div><p>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</p></div>Dougtag:robotlegs.tenderapp.com,2009-10-18:Comment/15273482010-04-24T14:04:02Z2010-04-24T14:04:02ZMore Flexible Mediation<div><p>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?</p>
<p>In this case, your two MovieClips would need to be concrete
MovieClip class extensions that exhibit the behavior you are
referring to.</p>
<p>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 ;)</p>
<p>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.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/15273482010-04-24T19:26:17Z2010-04-24T19:26:17ZMore Flexible Mediation<div><p>Hi Doug, thanks for the feedback.</p>
<p>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:</p>
<p><code>Application <-> Mediator <-> View</code></p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/15273482010-04-25T14:50:13Z2010-04-25T14:50:13ZMore Flexible Mediation<div><p>Thanks Shaun. So in your example, how are you going to point old
mediators<br>
to new views? Are you injecting your views as interfaces? If the
Mediators<br>
aren't handling any display logic, what do they actually do? What
does it<br>
mean to be a "gateway"?</p></div>Doug McCluertag:robotlegs.tenderapp.com,2009-10-18:Comment/15273482010-04-26T09:09:37Z2010-04-26T09:09:37ZMore Flexible Mediation<div><p>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.</p>
<p>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.</p>
<p>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.</p>
<p><a href=
"http://wiki.github.com/robotlegs/robotlegs-framework/best-practices#mediatorresponsibilities">
http://wiki.github.com/robotlegs/robotlegs-framework/best-practices...</a></p></div>Shaun Smith