Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast.
About Atomic Object
We design and build world-class software for all sorts of clients.
Atomic Object Contact Us: +1 616 776 6020 contact@atomicobject.comCategories
Stay Connected
3 Comments
Very interesting pattern. Is it possible to get more information on how to handle interaction between MVP triads? Your paper mentions cooridating objects, but how does that work with complex GUIs elements. For example how could drop down menus be handled? Do you wrap the menustrip control in a View? It seems like the model would have to know in advance which menu items and submenus are available.
TIA
Rick…
Rick,
Yes, the Model would need to know in advance which menu items and submenus are available. This is a good thing.
One of the purposes of the Model is to model system state. A View should be as “dumb” as possible. So, let’s walk through a few scenarios. At initialization, the Presenter will receive an initialization event from the View when it’s about to be displayed and in response will query the Model for the list of menu items the View should display. The Presenter will then call a wrapper method on the View to set the drop down menu contents from the list the Model provides. At the time of a UI event, the View will fire an event with an index of the menu item clicked. The Presenter will receive that event and then call a menu handler method in the Model with that index. The Model (having its internal menu item list) knows what menu item to which that index corresponds and will take appropriate action from there – for example, calling a system function and then firing an event that the Presenter will receive causing it in turn to change a View item’s state.
This separates concerns and decouples actions to such a degree that the View is simply that – a view of the system with no logic within it. With this approach, then, we can test under automation all the possible scenarios a user interaction with the View might cause without actually displaying the View’s widgets on-screen. We assume the widgets in the View (provided by someone else) work as expected. Thus, in unit tests, we simply simulate the events a View will fire and verify that the Presenter makes calls on the Model appropriately. Further unit tests verify that the Model works as expected. Further unit tests still verify that the Presenter makes calls on the View when the Model fires events. Generally, there are no unit tests of the View; some form of system testing ensures that everything is “wired up” properly.
You have brought up a very excellent details , regards for the post. “For visions come not to polluted eyes.” by Mary Howitt.