tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/485-just-learning-need-some-helpRobotlegs: Discussion 2018-10-18T16:35:24Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/60914382011-03-20T08:11:58Z2011-03-20T08:12:46ZJust learning, need some help<div><p>Determining what views will be mediated separately is a bit of
an instinct/experience thing, but mostly depends on use case
requirements.<br>
Personally, I wouldn't mediate each button separately, unless if I
want to reuse one of these buttons in a drag-and-drop style. If for
example there's a "register now" button which you need to use in
various views, the easiest solution is to mediate it
separately.<br>
To me solution 2 sounds as the one I'd choose, since it separates
the menus from the rest of the application and makes them easily
reusable and movable (but that also depends on how the menus are
created obviously)<br>
I'd certainly avoid 3, such "solutions" become messy VERY fast.</p>
<p>As for the transition between views: again this depends on use
case, but I'd let the views be responsible for having transitionIn
and transitionOut methods (using some kind of decorator pattern for
sure) and have a separate TransitionView (with corresponding
mediator) which triggers these transitions.<br>
You shouldn't let the mediators of the to-be-transitioned views
trigger these transitions. Mediators are basically middle-men that
pass framework events and data to views and vice versa.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/60914382011-03-27T02:42:14Z2011-03-27T02:42:16ZJust learning, need some help<div><p>Thanks for the input. I have chosen to go with option 2. I'll
have to brush up on the decorator pattern, but definitely
appreciate the suggestions. A TransitionView with a
TransitionViewMediator makes sense.</p>
<p>Cheers!</p></div>Michael Latzoni