tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/1030-mvcs-architecture-when-dealing-with-keyboard-events-on-a-menubarRobotlegs: Discussion 2012-09-14T07:08:37Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/185279952012-09-05T17:51:00Z2012-09-06T11:40:02ZMVCS architecture when dealing with keyboard events on a menubar<div><p>Hey Matt,</p>
<p>First thought I had:</p>
<p>Why don’t you let the View manage its own position on the
screen in response to a keyDown event, and if you need to store the
currActiveItem and the currentPosition in a Model, you can
transport that info using a VO, that would be the payload of the
event dispatched by the View in the keyDown handler, and then
redispatched by the Mediator->Command->Model.</p>
<p>Do you need to get anything other than what the View should
already know, namely its position and currently selected item, from
that Model? Or do you just need to trigger other actions, like
loading other Views corresponding to the selected menu item?<br>
Is the re-positioning of the View really dependent on the
Model’s data?</p>
<p>What if you change your mind and you want to have another layout
for the menu? Would you use another model, having
model.navUp()/model.nav.Down()?</p>
<blockquote>
<p>For now I am just concerned with the menu changing state and not
loading anything.</p>
</blockquote>
<p>Usually, it is better to let Views handle their own visual state
(like the Flex view states, transitions, show/hide, positioning,
etc) internally, and let Models handle application states (the
state of the data). Mediators can inform their Views about changes
in the application’s state, and if need be, the Views can
change their own visual state accordingly. If user interactions
with the View affect its state, the best place to handle this is
the View itself, and then let the application know about what just
happened via events. The View should be pretty self-sufficient and
reusable. What if you decide, or need, to use another framework
providing another micro-architecture?</p>
<p>Maybe you have a good reason to have the flow you’ve
described, and in this case, yes, it’s the correct flow.
You’ll be the one deciding how much View logic you want to
put in your Models and Commands. From our previous discussion I
know that you like Commands very much ;-)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/185279952012-09-06T10:10:26Z2012-09-06T10:10:26ZMVCS architecture when dealing with keyboard events on a menubar<div><p>Thanks Ondina,</p>
<p>I guess what I am doing is letting the controller/model decide a
lot of the logic that renders the view - which means if the view
changes then the model and controllers do too - which is obviously
bad.</p>
<p>The view doesn't need anything else from the model in this case,
so I suppose a model isn't even needed here?</p>
<p>It sounds like I need to move most/all of this logic into the
MenuView and handle it there, and only dispatch application events
when the selected item changes.</p>
<p>Thanks,</p>
<p>Matt</p></div>Matttag:robotlegs.tenderapp.com,2009-10-18:Comment/185279952012-09-06T10:15:44Z2012-09-06T10:15:44ZMVCS architecture when dealing with keyboard events on a menubar<div><p>Can you give me an example of when a MenuModel would be useful?
I'm trying to think of situations where you would actually need to
manipulate the model based on actions in the view.</p></div>Matttag:robotlegs.tenderapp.com,2009-10-18:Comment/185279952012-09-06T11:39:48Z2012-09-06T11:47:59ZMVCS architecture when dealing with keyboard events on a menubar<div><p>You’re welcome, Matt!</p>
<blockquote>
<p>I guess what I am doing is letting the controller/model decide a
lot of the logic that renders the view - which means if the view
changes then the model and controllers do too - which is obviously
bad.</p>
</blockquote>
<p>Your intentions are good:) You’re trying to design your
application following patterns like single responsibility
principle, separation of concerns, loose coupling etc, and
that’s a good thing. Defining the roles and responsibilities
for the different layers of an application is not an easy task!</p>
<p>I don’t know how much you already know about
robotlegs’ MVCS, but even if you know a lot in theory,
looking at examples (with the theory in mind) can be very helpful.
Have you seen the long list of demos, examples, and tutorials on
our forum? Not all of the examples follow the best practices, but
it’s interesting to see how different people use rl and
it’s a good source of inspiration.</p>
<p>Also, Stray’s answers to questions about the roles of
Models, Mediators, and other rl actors are an interesting and
informative read.<br>
Here just a short description of rl actors:</p>
<ul>
<li>Services+Models+VOs =responsible for retrieving data,
manipulating data, persisting data structures</li>
<li>Service = gatekeeper to the outside world, data supplier, data
source</li>
<li>Model = deals with data, data modeler, responsible for
manipulating the application’s states</li>
<li>VO=data carrier class to shuttle typed data across tiers</li>
<li>Controller=Events+Commands= application logic =
application’s behavior= use cases</li>
<li>Commands act upon Models and Services, usually in response to
user interactions with the application</li>
<li>View=user interface</li>
<li>Mediator= intermediate, intermediary between application and
View, wiring the Views to the shared event dispatcher.</li>
</ul>
<p>Services are the intermediaries between an application and the
outside world; Mediators are intermediaries between the application
and the user interface.</p>
<p><strong>Sorry if you already knew all this!!</strong></p>
<blockquote>
<p>The view doesn't need anything else from the model in this case,
so I suppose a model isn't even needed here?</p>
</blockquote>
<p>Yes, I think that too.</p>
<blockquote>
<p>It sounds like I need to move most/all of this logic into the
MenuView and handle it there, and only dispatch application events
when the selected item changes.</p>
</blockquote>
<p>Yep, that’s what I would do.</p>
<blockquote>
<p>Can you give me an example of when a MenuModel would be useful?
I'm trying to think of situations where you would actually need to
manipulate the model based on actions in the view.</p>
</blockquote>
<p>Nothing comes to mind, right offhand. I’ll have to think
about it first. I’ll keep you posted.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/185279952012-09-06T14:22:32Z2012-09-06T14:22:32ZMVCS architecture when dealing with keyboard events on a menubar<div><p><a href=
"https://github.com/joelhooks/robotlegs-examples-AddressBook">https://github.com/joelhooks/robotlegs-examples-AddressBook</a></p>
<p>In ContactsView there is a datagrid. You could have a List or a
Menu instead.<br>
Look at ContactsModel, which is used to set datagrid’s
dataProvider and to manage datagrid’s selectedItem.
ContactsModel dispatches a ContactsModelEvent.SELECTED ,
ContactsTabNavigator opens ContactForm for the selectedItem.<br>
Also, follow the flow for saving or deleting an item, which have an
impact on the ContactsView as well (a bit similar to what you
wanted for your use case, I think)</p>
<p>Expanding on the MenuView without a MenuModel:<br>
A custom event could be all you needed to coordinate something like
loading of Views ( HomeView, Imagesview, UsersView..) in response
to a selected item.<br>
I guess the use case you’ve presented in our first discussion
has something to do with this one, right?<br>
If so, then NavigatorView, that I was using there as an example,
dispatched</p>
<p>NavigatorEvent.NAVIGATION_INDEX_CHANGED,
event.currentTarget.selectedItem</p>
<p>and in NavigatorModel the selectedItem was just the argument
passed to getViewsArray() Bad name, right? Right. And
NavigatorModel should be renamed as well, because it’s not
really related to navigation, but to creating subviews. In that
example NavigatorView’s state is not dependent on
NavigatorModel. NavigatorView is model-less:P</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/185279952012-09-07T14:48:54Z2012-09-07T14:48:54ZMVCS architecture when dealing with keyboard events on a menubar<div><p>Hi Ondina,</p>
<p>Thanks again for the response. I'll check out those example
demos that you've sent. I've been looking at the Mosaic example but
it's quite a different application so not always that useful.</p>
<p>I've built the menu system to use the methods you suggested
above. It feels like a lot of the code is now just in the view but
I suppose that's OK.</p>
<p>Now all the mediator does is dispatch an event to say that the
selection has changed. A command picks this up to change the
scene.</p>
<p>I still have a menu model though, which stores the VOs loaded in
from the service. Not sure it's really needed though as the VOs
could still just live in the view.</p>
<p>Thanks again for the help.</p>
<p>Matt</p></div>Matttag:robotlegs.tenderapp.com,2009-10-18:Comment/185279952012-09-07T15:03:29Z2012-09-07T15:03:29ZMVCS architecture when dealing with keyboard events on a menubar<div><p>No problem, Matt.<br>
The flow you've described sounds about right.<br>
I’m going to close this discussion. You know what to do: come
back with questions about a specific use case (re-open this or
create another discussion)</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.