DesignPatterns: Который является самым соответствующим для использования для пользовательского интерфейса стиля мастера?
Невозможно использовать v-model для двусторонней привязки данных, так как вы хотите изменить поведение по умолчанию при изменении ввода в дочернем компоненте.
Вы хотите использовать v-bind для отображения значения и v-on:input для передачи данных обратно в родительский компонент.
См. Например https://codesandbox.io/s/rj76y5w02o .
Первая строка - это текст только для чтения. Выпадающий список выбора является родительским мутатором данных, а текстовое поле - дочерним компонентом.
По сути, вы хотите, чтобы данные содержались на родительской стороне и передавали данные в дочерний компонент с помощью реквизита. Внутри дочернего компонента вы хотите передать входное событие обратно родительскому для обработки с помощью $emit.
Изменение значения с помощью раскрывающегося списка родителей приведет к обновлению значения. Изменение значения изнутри ввода текста дочернего компонента также будет. Если вы введете one, two или three, выпадающий список выбора родителей также будет соответствующим образом обновлен.
4 ответа
Другими словами: где / как вы абстрагируете / инкапсулируете логику определения следующего шага в wizard, основанный на том, что пользователь выбрал на конкретном шаге мастера?
Один из способов сделать это - смоделировать классы Wizard, Step и Product. Может быть, что-то вроде этого?
public class Wizard
{
public Step forward() {//...}
public Step backward() {//...}
public Step current() {//...}
public Product getProduct() {//...}
}
public class Step
{
public String name() {//...}
public void commit(Product product) {//...}
public void rollback(Product product) {//...}
}
public class Product
{
//...
}
Цель мастера - создать продукт (автомобиль, компьютер, отпуск и т. Д.).
В этом сценарии мастер решает следующий шаг - возможно, в зависимости от состояния продукта, создаваемого мастером. Wizard будет действовать как Builder под управлением пользовательского интерфейса, который будет директором и сообщать Wizard, когда и в каком направлении делать переход. Мастер должен решить, каким будет следующий шаг. Может поддерживаться несколько точек ветвления, но эта реализация будет скрыта внутри мастера.
Шаг будет экземпляром Command Pattern с возможностью отмены / повтора.
Шаблон « State » может иметь смысл, если вы хотите, чтобы пользователь мог перемещаться вперед и назад через мастера.
Шаблон рабочего процесса также может иметь смысл. Может быть, исследовать с помощью Windows Workflow Foundation.
Мне нравится быть проще. Я устанавливаю значение для объекта, который я строю, с номером шага, поэтому, если я создаю страховой полис, у меня будет свойство в полисе, которое указывает, на каком шаге он находится. Затем у меня есть один метод - маршрутизатор, который просматривает политику и определяет, куда ее отправлять дальше. Вы можете встроить дополнительную логику в маршрутизатор, чтобы пропустить шаги, или вы можете поместить логику в каждый метод шага и перенаправить обратно к маршрутизатору. метод.
Я должен согласиться с Бо.
На самом деле, если вам нужен сложный набор правил для логики навигации , тогда у вас есть мастер с графическим интерфейсом, но не мастер под колпаком.
Если то, что вы пытаетесь построить, действительно волшебник, то каждый экран должен отображаться максимум в 2-3 разных экранах (IMO). Это можно легко сохранить в очень простую структуру (база данных, статический файл конфигурации).