Passive View - view specific logic

Question

Let's say I want to implement Passive View design pattern. I have a view which contains a listbox (which I perhaps will swap with listview or something else in the future). Now, with Passive View one should make the view as dumb as possible. Lets say I want to change the selection. I will put the logic for this in the presenter, thus I add a property to the views interface to get and set SelectedIndex property of the view's listbox. But if I in the future want to swap the listbox with a listview I am in trouble, because listview does not have a SelectedIndex property. Do I then implement some logic in the view (essentially making it a little less dumb) something like:

public int SelectedIndex
{
    get
    {
        if (myListView.SelectedIndices.Count > 0)
        {
            return myListView.SelectedIndices[0];
        }
        return -1;
    }
}

Or do I put some kind of adapter between the view and the presenter. What would be the most logical approach?

score 1 · Answer 1 · answered Jun 18 '13 at 15:25

Yes you could do that. UI patterns such as Passive View, MVVM, MVC, MVP are general guidelines (they are not strict rules) on how to separate presentation from the application core logic to get a loosely coupled application that could be maintained and extended with minimum fuss. Now since since using a listview or listbox in your case is specific to the presentation you could put logic in the presentation to handle this without breaking this isolation between the UI and the application core.

score 1 · Accepted Answer · answered Jun 18 '13 at 20:51

1

I think you need to get more abstract. A selected index could be considered too tightly coupled to a particular UI control. Something that, as you correctly point out, the pattern is trying to avoid so that views can be swapped seamlessly. Therefore, I would suggest the view has a property representing what is selected, be that a string or a more complex class, so that the particular view implementation can hide the actual translation from abstract to concrete. This way the presenter only ever deals with something meaningful to it, not the mechanics of a particular UI control.

answered Jun 18 '13 at 20:51

David Osborne

6,436
1
21
35

Indeed that was what I was thinking, my code was too tightly coupled to a particular UI control. Actually what I had in mind was having a textbox as a search field which would update the contents of the listbox/listview. There would be a select/commit button, but the user should also be able to press the arrow keys (with the textbox selected) to change the selection in the list, and then press enter to commit. If I am not to expose selected index or have some logic in the view, what do I do then? Perhaps I should have MoveSelectionDown() and MoveSelectionUp() which the presenter could call? – Roger Saele Jun 19 '13 at 06:50
1

But this would all change if your view used completely different controls? Your presenter should be unaware of any UI specifics. Maybe you should let your presenter's unit tests drive what functionality you put into the presenter and what can remain in the view. Why does your presenter need to change what's selected, doesn't the user do that and then just click something? – David Osborne Jun 19 '13 at 07:39
Yes, the user can click something. But I also wanted the user to be able to only use the keyboard (without tabbing his way around). So when when the view popped up the search box would be selected, the user would then type something to search and the just press the arrows keys (up/down) and then Enter when he had selected what he wanted. All of this would happen with the search box selected. I am leaning towards just having some logic in the view and simply raise an event (which the presenter can subscribe to) to say the user made a selection. – Roger Saele Jun 19 '13 at 08:05
1

I think that's the right approach. It certainly sounds like view-specific logic. – David Osborne Jun 19 '13 at 10:01
One thing, I had understood that one reason for using Passive View was to get the greatest unit test coverage possible. Thus putting view-specific logic in the view would make it difficult to test. [Here](http://thedersen.com/blog/2010/01/15/passive-view-the-way-we-do-it/) is an example of Passive View where the presenter is responsible for updating the view based on things happening in the view. More specifically, for instance, if text in TextBox changes and is empty then disable button. I guess this is view-specific logic and it could obviously easily be implemented in the view itself. – Roger Saele Jun 20 '13 at 12:57
1

Yes, this is true. However, there will always be a need to strike a balance between code that can be tested in the presenter and view-specific logic that you will not be able to unit test easily. The skill is getting this balance to a point you're happy with and where any defects in view-specific code would be easily identified during system/acceptance testing. I always sanity-check this balance by asking myself whether I could replace my presenter with a radically different view type, a command line-based view, for example. – David Osborne Jun 20 '13 at 16:02

Passive View - view specific logic

2 Answers2