views:

166

answers:

4

I'm working with the Passive View pattern. The user clicks a new account button. The view delegates responsibility to the presenter using parameterless method calls.

The problem is there are multiple account types so the user needs to pick which one they want to create. How do I resolve this?

  1. Create a new form from the view, get the needed information and expose it as a property so the presenter can retrieve it. (This ignores the notion that the view shouldn't have any logic in it)
  2. Create and use the new form from the presenter. (This ties the presenter directly to a form, ignoring the entire point of MVP)
  3. Create the new form somewhere else and pass it in as a constructor argument to the presenter... or view.
  4. Forget it and add a new button for each account type. (There are a number of account types and this will clutter the UI but so be it.)
  5. I'm going about this the wrong way and need to rethink my design. (If this is the case, an nudge in the the right direction would be appreciated.)
A: 

I'm not an MVP expert but I would handle this by using a delegate to get the account type from the view. The presenter invokes the delegate on the view which opens the "select account type" form and returns the selected account type when the user has selected an account type and closed the form.

Jamie Ide
A: 

I'd probably create another presenter-view pair for getting the account type. Then either

  • your presenter calls the other presenter directly to display the new form or
  • your presenter asks its model for the right account type. The model knows that it should ask somewhere else and invokes the "account type presenter" or even the "account type model".

I think I'd go with the first option unless your presenter grows unwieldy.

Lennaert
A: 

If you are talking about a simple interface for selection an account type, IMO it depends on the number of account types. I would just add new buttons for each account. However, if you have a lot of account types, I would have a combobox with the list of all possible accounts and the first (the one the user sees first) be an invalid or unselected type. I would also add some label saying "Select account type to create", then have one single button press that sends the value in the combobox to the model. This way if the user just clicks the button without select an account type, the model will valid the type, and return the problem to the view (and the view can highlight the box or red the text or whatever). That would prevent the user from missing the account type selection. This approach would also make unit testing easier.

If you are talking about each account type having different information that needs to be filled out, then you would have to have a different view and presenter per each account. (This would be what you need after the user selects the account type)

SwDevMan81
A: 

My solution for this was different than I expected. I changed the button the user clicked to a DropDownMenuButton. Then I passed a string list of account types to the view which populates the drop down menu. I also created an event handler for the drop down menu item click event, which updates a public property with the name of the menu item then delegates everything else to the presenter.

The presenter just has to get the menu item name from the exposed property and then lookup the account type in a private dictionary of account types using the account type name as the key.

codeelegance