Поддержка пользовательского интерфейса конечным автоматом

Question

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

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

Может ли кто-нибудь, кто пробовал это, дать какое-либо понимание этого подхода?Есть ли какие-либо подводные камни, о которых мне нужно знать?

Answer 1

Сверху в голове, это немного очевидно, но тем не менее, поскольку никто ничего не ответил:

• Я бы посоветовал сохранить состояние стороны сервера приложений,индексируется через переменную сеанса / идентификатор пользователя по соображениям безопасности и гибкости;

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

Подход, основанный на событиях, в некоторой степени относится к этой методике , которая "еще"визуально ориентированные среды (Adobe Flex, формы Oracle, а также HTML, в некотором роде ограниченным образом) используют.В двух словах, у вас есть триггеры (item.on_click, label.on_mouse_over, text_field.on_record_update), которые вы используете для управления состояниями интерфейса.

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

Некоторые языки / среды предлагают некоторую защиту от более очевидных случаев, но это то, что нужно искать.

Это, вероятно, полезно для вашего подхода.