passive view and display logic

In MVC and MVP and similar patterns there's often the approach of the "passive view" which is as stupid (contains as few logic) as possible. This should facilitate unit testing and create a clearer separation of view and model.

I know that those patterns come in very different flavours and especially the understanding of MVP seems to differ from article to article. Therefore my question is not "how do i implement this pattern correctly".

I want to improve view and model separation and go for better testability of the application. Therefore i'd like to go for a passive view. But my question is, where 开发者_运维百科would you put logic that is clearly only view related? like a textviewer should scroll the text when the scrollbar is moved. would you put the logic for this into the Presenter? Let's say the textviewer has some extended functionality. like setting markings on textpassages. The logic for this makes clearly sense to be put into the Presenter. However, if it is mixed with all the 'direct' logic of the view (like scrolling the text) the Presenter could become very big, which is also not really a nice design.

So my question is where to put display related logic of a passive view and what functionallity to mix in the Presenter.

Thanks!

---

I'd put scrollbar logic in the presenter if it needs to fetch more data from the model when the user scrolls. Even if not, the view should notify the presenter.

Sometimes the GUI API handles scrolling by itself. If that's the case then all you could do is notify a stub within the presenter (which does nothing). The view has no idea of what's important to the presenter.

The presenter does not have to be a single monolithic class. Preferably, you'd aggregate different objects for different responsibilities. This is actually good from a testing point of view, where you can mock out all the objects that you are not currently testing.