Моему докладчику необходимо запросить у пользователя дополнительную информацию.Как мне его подключить?
-
20-08-2019 - |
Вопрос
Я работаю с шаблоном пассивного просмотра.Пользователь нажимает кнопку создания новой учетной записи.Представление делегирует ответственность презентатору с помощью вызовов методов без параметров.
Проблема в том, что существует несколько типов учетных записей, поэтому пользователю необходимо выбрать, какой из них он хочет создать.Как мне это решить?
- Создайте новую форму из представления, получите необходимую информацию и представьте ее как свойство, чтобы ведущий мог ее получить.(Это игнорирует идею о том, что представление не должно содержать никакой логики)
- Создайте и используйте новую форму из презентатора.(Это привязывает докладчика непосредственно к форме, игнорируя весь смысл MVP)
- Создайте новую форму где-нибудь еще и передайте ее презентатору в качестве аргумента конструктора...или просмотреть.
- Забудьте об этом и добавьте новую кнопку для каждого типа учетной записи.(Существует несколько типов учетных записей, и это будет загромождать пользовательский интерфейс, но пусть будет так.)
- Я делаю это неправильно, и мне нужно переосмыслить свой дизайн.(Если это так, то толчок в правильном направлении будет признателен.)
Решение 4
Мое решение для этого было другим, чем я ожидал.Я изменил кнопку, которую нажал пользователь, на DropDownMenuButton.Затем я передал строковый список типов учетных записей в представление, которое заполняет раскрывающееся меню.Я также создал обработчик событий для события щелчка элемента раскрывающегося меню, который обновляет общедоступное свойство с именем пункта меню, а затем делегирует все остальное презентатору.
Докладчику просто нужно получить имя пункта меню из предоставленного свойства, а затем найти тип учетной записи в частном словаре типов учетных записей, используя имя типа учетной записи в качестве ключа.
Другие советы
Я бы, вероятно, создал еще одну пару докладчик-представление, чтобы получить тип учетной записи.Тогда либо
- ваш докладчик напрямую вызывает другого докладчика, чтобы отобразить новую форму или
- ваш докладчик запрашивает у своей модели правильный тип учетной записи.Модель знает, что она должна задать вопрос где-то еще, и вызывает «представителя типа учетной записи» или даже «модель типа учетной записи».
Думаю, я бы выбрал первый вариант, если только ваш ведущий не станет громоздким.
Я не эксперт по MVP, но я бы справился с этим, используя делегата, чтобы получить тип учетной записи из представления.Ведущий вызывает делегата в представлении, которое открывает форму «выбор типа учетной записи» и возвращает выбранный тип учетной записи, когда пользователь выбрал тип учетной записи и закрыл форму.
Если вы говорите о простом интерфейсе выбора типа учетной записи, то, по моему мнению, это зависит от количества типов учетной записи.Я бы просто добавил новые кнопки для каждой учетной записи.Однако, если у вас много типов учетных записей, у меня будет поле со списком всех возможных учетных записей, и первая (та, которую пользователь увидит первой) будет недействительным или невыбранным типом.Я бы также добавил метку с надписью «Выберите тип учетной записи для создания», а затем нажмите одну кнопку, которая отправит значение в поле со списком в модель.Таким образом, если пользователь просто нажмет кнопку, не выбрав тип учетной записи, модель проверит тип и вернет проблему в представление (и представление может выделить поле, сделать текст красным или что-то еще).Это не позволит пользователю пропустить выбор типа учетной записи.Этот подход также облегчит модульное тестирование.
Если вы говорите о том, что каждый тип учетной записи имеет разную информацию, которую необходимо заполнить, тогда вам придется иметь разные представления и презентаторов для каждой учетной записи.(Это то, что вам нужно после того, как пользователь выберет тип учетной записи)