Model-view-presenters and user-interactions involving separate dialogs

Question

I have a UI form written using model-view-presenter that has, among other things, a listbox containing a number of different domain objects. The form also contains an add/update button which pulls up a dialog allowing the user to add/update a domain object.

The domain-object form is general and is used to gather basic information, like the name of the object. It's essentially a humble dialog that collects information and dispatches an event with said information when the form is closed successfully allowing the domain object to be added or updated accordingly.

To clarify a bit more, I'm unsure in a number of different areas:

• Is there a standard interaction model or are there standard interaction patterns for use between UIs when using MVP?
• Should the responsibility for displaying any required forms or dialogs lie with the presenter, view, or neither?
• Does the fact that I'm using a humble dialog for the information gathering violate "tell, don't ask" and make things harder than needed?
• Is the answer UI specific and, if so, what questions would guide me to a good answer?

Other notes:

• It feels like the responsibility for displaying required forms and dialogs lies more with the view than with the presenter, as other views could use alternative means to gather that information -- the presenter only needs be appropriately alerted.
• I'm more interested in the related patterns and practices than in technical details.
• In the spirit of low coupling, I typically use message passing between forms and components.

Answer 1

I haven't worked with MVP, but I have worked with MVVM which I'm told is similiar. In MVVM the code to show and hide dialog is done in the ViewModel (Presenter)

I'm not sure how closely related MVP is with MVVM in terms of UI, but here's an example using MVVM:

You select an item in a dropdown and hit Edit

This executes a command on the ViewModel which determines which EditableObject to show, and sets the EditingObject property to that object.

If the EditingObject is a ViewModel, it would contain its own Save/Close Commands. Otherwise, the ViewModel sets other properties of type ICommand to what the Save/Close Commands would be.

The UI has something listening to that EditingObject property so when it changes, it throws up the popup containing the EditingObject info. Popup buttons such as Save/Close are either bound to the EditingObject's Save/Close commands or the main ViewModel's Save/Close commands depending on how your objects are built.