tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/737-is-context-menu-a-mediator-or-view-logicRobotlegs: Discussion 2011-12-28T15:22:11Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/118404012011-12-02T15:33:28Z2011-12-02T15:33:28ZIs context menu a mediator or view logic<div><p>I added a context menu to my example project.<br>
And added the context menu logic to the mediator.<br>
Should it be there, or in the the view component of this
mediator?</p>
<p>Here is the class on GitHub:<br>
<a href=
"https://github.com/eliatlas/robotlegs-thumb-gallery/blob/master/ThumbsGallery/src/gallery/view/ThumbsGalleryMediator.as">
https://github.com/eliatlas/robotlegs-thumb-gallery/blob/master/Thu...</a></p></div>Eli Atlastag:robotlegs.tenderapp.com,2009-10-18:Comment/118404012011-12-02T16:05:51Z2011-12-02T16:05:51ZIs context menu a mediator or view logic<div><p>definitely in the view:)<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/118404012011-12-03T18:01:50Z2011-12-03T18:01:52ZIs context menu a mediator or view logic<div><p>Hi Ondina</p>
<p>Thanks for the answer.<br>
Can you explain a bit more?<br>
That's because mediator should contain only the logic related to
the framework itself?</p></div>Eli Atlastag:robotlegs.tenderapp.com,2009-10-18:Comment/118404012011-12-04T15:01:54Z2011-12-04T15:01:54ZIs context menu a mediator or view logic<div><p>Hi Eli,</p>
<p>That’s a complex topic!<br>
“That's because mediator should contain only the logic
related to the framework itself?”</p>
<p>Simply put, if you follow the MVCS pattern as implemented in
robotlegs, the Mediator is considered to be a
<strong>bridge</strong> between a View ( UI Component) and the rest
of your application (other Mediators, Models, Services,
Comands).<br>
If different Views need to communicate with each other
they’ll do it through their Mediators, never directly.<br>
Mediators listen for events dispatched by their Views and relay
them to the rest of the application.<br>
Mediators listen for events dispatched by a Service, or Model or
other Mediators and can access public methods in their Views,
either to set some data coming from a Model or Service, or to let
the view perform some actions.</p>
<p>Application<---shared
eventDispatcher<---Event<---<strong>Mediator</strong><---Event<---View</p>
<p>Application--->shared eventDispatcher
--->Event---><strong>Mediator</strong>--->View.API--->view
actions</p>
<p>Ideally, you just register event listeners in your
Mediator.onRegister() and have handler methods, which either call a
method on the View or re-dispatch an event coming from the View.
Nothing more. Ideally!</p>
<p>This way your <strong>Views are loosely coupled and
reusable</strong> and so will be your Models and Services as
well.</p>
<p>SomeView dispatches a custom event
SomeRequestEvent.LOAD_DATA<br>
SomeMediator re-dispatches the event, which will trigger
SomeCommand.<br>
SomeCommand will call a method on SomeService.
accessResources()<br>
SomeService will either set the result in SomeModel<br>
or will dispatch an event that will trigger a command, that will
set the SomeModel data.<br>
SomeModel will dispatch an event with the data as a payload,
SomeMediator will pick it up and pass the payload to SomeView,
which will set the dataProvider of a List or a DataGrid with the
payload.<br>
Selecting an item from the List will dispatch an event,
SomeMediator will re-dispatch it, AnotherMediator will pick it up
and let AnotherView perform some action depending on the
selectedItem.</p>
<p>I could give you a link to an example, which uses this logic, if
the above isn’t clear enough.</p>
<p>It would take me too long to explain more and I would only
repeat what was already said many times and in much better words
than mines. I would suggest reading:</p>
<ul>
<li>the Best Practices again</li>
<li>tutorials ( for example Joel’s)</li>
<li>posts on this forum where Stray explains in detail the role of
Mediators ( look for loosely coupled, decoupled)</li>
<li>Stray’s and Joel’s Book (<a href=
"http://shop.oreilly.com/product/0636920021216.do">http://shop.oreilly.com/product/0636920021216.do</a>)</li>
<li>and to look at examples (<a href=
"http://knowledge.robotlegs.org/discussions/examples/6-links-to-robotlegs-resources-examples-tutorials">http://knowledge.robotlegs.org/discussions/examples/6-links-to-robo...</a>)</li>
</ul>
<p>You can, of course, ask more questions about this or any other
topic, or if something I said was confusing :)</p>
<p>In your case the ContextMenu belongs to the View (ThumbsGallery)
and also the methods you are now having inside
ThumbsGalleryMediator related to the ContextMenu should reside in
the ThumbsGallery.<br>
If you need the rest of your application to react to
menuItemSelected you can dispatch a custom event in the
view’s handler method:</p>
<p>protected function
menuItemSelected(evt:ContextMenuEvent):void<br>
{</p>
<p>dispatchEvent(new
SomeContextMenuEvent(SomeContextMenuEvent.ITEM_SELECTED,
somePayload);</p>
<p>}</p>
<p>ThumbsGalleryMediator.onRegister() registers a listener for
it:<br>
eventMap.mapListener(_thumbsGalleryMainView,
SomeContextMenuEvent.ITEM_SELECTED, dispatch);<br>
and will re-dispatch SomeContextMenuEvent to the rest of your
application.</p>
<p>Let me know what you think:)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/118404012011-12-26T15:19:25Z2011-12-26T15:19:25ZIs context menu a mediator or view logic<div><p>Thanks Ondina, this is great explanation :)</p></div>Eli Atlastag:robotlegs.tenderapp.com,2009-10-18:Comment/118404012011-12-28T15:22:10Z2011-12-28T15:22:10ZIs context menu a mediator or view logic<div><p>Thanks, Elli:)<br>
I'm glad it was helpful.<br>
Cheers,<br>
Ondina</p></div>Ondina D.F.