Мой докладчик должен запросить у пользователя дополнительную информацию. Как мне это подключить?

Question

Я работаю с шаблоном пассивного просмотра. Пользователь нажимает кнопку новой учетной записи. Представление делегирует ответственность докладчику, используя вызовы методов без параметров.

Проблема в том, что существует несколько типов учетных записей, поэтому пользователю необходимо выбрать, какой из них он хочет создать. Как мне решить эту проблему?

1. Создайте новую форму из представления, получите необходимую информацию и представьте ее как свойство, чтобы докладчик мог ее получить. (Это игнорирует представление о том, что в представлении не должно быть никакой логики)
2. Создайте и используйте новую форму от докладчика. (Это связывает докладчика непосредственно с формой, игнорируя всю точку MVP)
3. Создайте новую форму где-нибудь еще и передайте ее в качестве аргумента конструктора докладчику ... или представлению.
4. Забудьте об этом и добавьте новую кнопку для каждого типа учетной записи. (Существует несколько типов учетных записей, и это будет мешать пользовательскому интерфейсу, но так и будет.)
5. Я поступаю неправильно, и мне нужно переосмыслить свой дизайн. (Если это так, то было бы полезно толкнуть в правильном направлении.)

Answer 1

Я бы, вероятно, создал еще одну пару для представления докладчика для получения типа учетной записи. Тогда либо

• ваш докладчик вызывает другого докладчика напрямую, чтобы отобразить новую форму, или
• Ваш докладчик запрашивает у своей модели правильный тип учетной записи. Модель знает, что она должна спросить где-то еще, и вызывает «предъявителя типа учетной записи» или даже «модель типа учетной записи».

Думаю, я бы выбрал первый вариант, если ваш ведущий не станет громоздким.

Answer 2

Мое решение для этого было другим, чем я ожидал. Я изменил кнопку, которую пользователь нажал, на DropDownMenuButton. Затем я передал строковый список типов учетных записей представлению, которое заполняет раскрывающееся меню. Я также создал обработчик события для события щелчка выпадающего меню, который обновляет открытое свойство с именем пункта меню, а затем передает все остальное докладчику.

Докладчик просто должен получить имя элемента меню из открытого свойства, а затем найти тип учетной записи в личном словаре типов учетных записей, используя имя типа учетной записи в качестве ключа.

Answer 3

Если речь идет о простом интерфейсе для выбора типа учетной записи, IMO зависит от количества типов учетных записей. Я бы просто добавил новые кнопки для каждой учетной записи. Однако, если у вас много типов учетных записей, у меня будет комбинированный список со списком всех возможных учетных записей, и первый (тот, который пользователь увидит первым) будет недействительным или невыбранным типом. Я бы также добавил ярлык с надписью «Выберите тип учетной записи для создания», а затем одним нажатием кнопки отправил бы значение в выпадающем списке модели. Таким образом, если пользователь просто нажимает кнопку без выбора типа учетной записи, модель проверит тип и вернет проблему в представление (и представление может выделить поле или выделить красный текст или что-то еще). Это не позволит пользователю пропустить выбор типа учетной записи. Этот подход также облегчит модульное тестирование.

Если вы говорите о каждом типе учетной записи, имеющей различную информацию, которую необходимо заполнить, то для каждой учетной записи вам потребуется другое представление и докладчик. (Это будет то, что вам нужно после того, как пользователь выберет тип учетной записи)

Answer 4

Я не эксперт MVP, но я бы справился с этим, используя делегата, чтобы получить тип учетной записи из представления. Докладчик вызывает делегата в представлении, которое открывает форму «выберите тип учетной записи» и возвращает выбранный тип учетной записи, когда пользователь выбрал тип учетной записи и закрыл форму.