Я помогаю создать приложение GWT для клиента и переписал большую часть материала, чтобы он работал лучше, короче код, быстрее и т. Д. Однако во всех приложениях с графическим интерфейсом, над которыми я работал (не так уж много), там наступает момент сгибания, когда вам просто нужно установить множество правил и переместить логику от слушателей к какому-то общему посреднику. Иногда это может привести к ужасному беспорядку, так что вы, как ни крути, думаете, что вам нужно сделать в слушателе.
Давайте рассмотрим пример:
- форма с 10-20 полями
- два эксклюзивных радиоуправления около половины состояния других полей (включение, проверка, пределы ввода)
- три эксклюзивных радиоуправления снова контролируют почти одни и те же поля, но по-другому (влияют на вычисления, включают); они также контролируются вышеуказанным
- 4 или около того числовые поля проверяются на лету в зависимости от предыдущих выборов и некоторого объекта данных в реальном времени; они могут иметь верхние / нижние пределы, быть включены / отключены
- один выпадающий список управляет следующими примерно шестью элементами управления - отображает / скрывает их, изменяет валидаторы
- некоторые флажки (показанные выше комбинированным списком) активируют некоторые поля ввода, а также определяют их алгоритм проверки
Пока все работает, без известных ошибок, есть несколько проблем с кодированием, которые действительно беспокоят меня:
- код распространяется среди слушателей и некоторых посреднических методов.
- загрузка формы с некоторыми предустановленными значениями представляет свои собственные проблемы: например, объекты данных, которые могут быть доступны или нет, объекты данных, которые могут изменять свое состояние, и последующее поведение поля
- для некоторых полей установлено значение по умолчанию, и это не должно быть перезаписано автоматическим заполнением, но если объекты данных еще не созданы (пока), их необходимо будет заполнить в конце концов, когда последующие станут доступными
- форма не может быть отправлена, если ни одно из полей не проверено
Мой подход:
- определить, какие поля имеют общий доступ и переместить код в одно место
- каждая радиогруппа разделяет реализацию одного слушателя между своими радиостанциями
- заполнение формы по умолчанию откладывается до тех пор, пока оперативные данные не станут доступны (насколько это возможно), и в результате они будут вызываться несколько раз
- каждое действие имеет вызов общего метода проверки
- Валидатор пробегает все поля в форме, вызывает их валидаторы (которые выделяют все ошибки) и возвращает единственное логическое значение
- каждое соответствующее нажатие клавиши или действие мыши, изменение данных откладывается для вызова через 250 мс после последнего вызова; это означает, что первый вызов просто устанавливает валидатор как отложенное действие, последующие вызовы сбрасывают таймер
Хорошо, не имеет смысла вдаваться в подробности, но меня больше огорчает тот факт, что нет четкого разделения между визуальными действиями (включение), действиями с данными (установка значений полей формы), слушателями полей. , получение значений формы и прослушивателей данных в реальном времени.
Каков будет хороший подход / шаблон (возможно, в следующий раз), чтобы убедиться, что MVC отделен и лучше поддается обслуживанию? Я знаю, что это не типичный вопрос, но я прочитал каждую документацию, которую мог достать, и все еще не нашел какого-либо полезного ответа.