Comments 31
Шалыто будет счастлив :)
UFO just landed and posted this here
Имхо это слишком накладно ;) Даже простое приложение насчитывает десятки событий, какой смысл описывать их с помощью КА? В конце-концов, та же стандартная событийная система — это тот же автомат.
Недавно реализовал Веб-интерфейс приложения используя конечный автомат. Бибилиотекой не делал, все реализовал в одном классе. Главной целями ставил:
— Чтобы можно бы было нарисовать удобночитаемую диагррамку состояний интерфейса.
— Чтобы код соответствовал диаграмме.
— Чтобы легко было бы перемещаться от кода к диаграмме и наоборот.
— Чтобы легко можно бы было разбираться/добавлять/удалять состояния и действия.
Думаю, что поставленные цели достигнуты.
— Чтобы можно бы было нарисовать удобночитаемую диагррамку состояний интерфейса.
— Чтобы код соответствовал диаграмме.
— Чтобы легко было бы перемещаться от кода к диаграмме и наоборот.
— Чтобы легко можно бы было разбираться/добавлять/удалять состояния и действия.
Думаю, что поставленные цели достигнуты.
UFO just landed and posted this here
Хочу вот статеечку в блог родить по этому поводу.
Сейчас могу вкратце на пальцах объяснить. Реализовано на Python. Все на стороне сервера.
1. Переходы из состояния в состояние по запросу от браузера. В запросе параметр tostate=«state to go to». FSM помнит предыдущее состояние.
2. Есть словарь переходов. В этом словаре ключом является строка вида «prev_state» + «next_state». Значением строки является массив названий функций, которые необходимо выполнить при выполнении перехода. Функции работают с атрибутами класса и являются интерфейсом к ядру программы.
3. Метод обработки переходов запоминает предыдущее состояние и последовательно исполняет функции из массива функций перехода.
4. Состояния сделаны двух видов одни состояния условно называются «Show» (показать страницу), другие «Action» они например выполняют проверку формы и в зависимости от результатов переходят в одно из состояний типа «Show».
5. Последняя функция в массиве функций перехода возвращает для перехода в состояние типа «Show» html код для передачи серверу, для состояния типа «Action» — имя состояния, в которое перейти.
Ну вот, вроде и все. Пока готова первая версия. Она включает 20 состояний и 38 переходов.
Сейчас могу вкратце на пальцах объяснить. Реализовано на Python. Все на стороне сервера.
1. Переходы из состояния в состояние по запросу от браузера. В запросе параметр tostate=«state to go to». FSM помнит предыдущее состояние.
2. Есть словарь переходов. В этом словаре ключом является строка вида «prev_state» + «next_state». Значением строки является массив названий функций, которые необходимо выполнить при выполнении перехода. Функции работают с атрибутами класса и являются интерфейсом к ядру программы.
3. Метод обработки переходов запоминает предыдущее состояние и последовательно исполняет функции из массива функций перехода.
4. Состояния сделаны двух видов одни состояния условно называются «Show» (показать страницу), другие «Action» они например выполняют проверку формы и в зависимости от результатов переходят в одно из состояний типа «Show».
5. Последняя функция в массиве функций перехода возвращает для перехода в состояние типа «Show» html код для передачи серверу, для состояния типа «Action» — имя состояния, в которое перейти.
Ну вот, вроде и все. Пока готова первая версия. Она включает 20 состояний и 38 переходов.
Дополнено к пункту 3.:
Конечно совершенно необязательно было делать массивы функций. Можно было сделать переходы и через вложенные вызовы функций. Массивы были выбраны для того, чтобы в совокупности с говорящими названиями исполняемых функций получить в одном месте (в словаре перехода) удобочитаемые цепочки исполняемых для перехода действий.
Пример, один ключ/значение словаря (значение тоже словарь):
# 23 — номер перехода по диаграмме
Конечно совершенно необязательно было делать массивы функций. Можно было сделать переходы и через вложенные вызовы функций. Массивы были выбраны для того, чтобы в совокупности с говорящими названиями исполняемых функций получить в одном месте (в словаре перехода) удобочитаемые цепочки исполняемых для перехода действий.
Пример, один ключ/значение словаря (значение тоже словарь):
# 23
'page_pg_block_add':{'type':'Act','methods':[self.fsm_pg_block_add,
self.fsm_diag_files_rm,
self.fsm_create_cur_page_diag_files,
self.fsm_page_cur_save,
self.fsm_go_to_page]},
# 23 — номер перехода по диаграмме
У меня есть знакомый, который сделал веб-интерфейс на конечных автоматах на лиспе :)
Шалыто набивает себе references для Википедии.
UFO just landed and posted this here
Очень интересно. Я, правда, не очень понимаю где в web-разработке применять FSM. Вот во встроенных системах раздолье.
Спасибо за библиотеку!
(Прелестно! Просто прелестно! Получите заслуженный плюс)
0. Надеюсь вы будете её дальше поддерживать и развивать?
1. Ещё не разобрался, ответьте, пожалуйста, содержательно:
Как там с шаблоном «Команда» (pattern «Command») для представления смен состояния как команд? Как проще всего сделать этот шаблон на вашей библиотеке?
Конкретно интересует такая особенность «Команды» как возможность кэширования команд, направить их в очередь, в очередь с приоритетами, сохранить, сделать транзакции и откат транзакции.
(Прелестно! Просто прелестно! Получите заслуженный плюс)
0. Надеюсь вы будете её дальше поддерживать и развивать?
1. Ещё не разобрался, ответьте, пожалуйста, содержательно:
Как там с шаблоном «Команда» (pattern «Command») для представления смен состояния как команд? Как проще всего сделать этот шаблон на вашей библиотеке?
Конкретно интересует такая особенность «Команды» как возможность кэширования команд, направить их в очередь, в очередь с приоритетами, сохранить, сделать транзакции и откат транзакции.
Пожалуйста.
Развивать не буду, если не понадобится в рамках работы. В данный момент всего хватает.
Насчет паттерна Command, не совсем понял, что ты имеешь ввиду. Мне в голову приходит только команда, у которой в имплементации самой команды встречается вызов автомата.
Насчет аналога отката транзакций, в ИТМО народ при разработке обучающего портала для иллюстрации алгоритмов придумал делать автоматы, которые моделируют как движение «вперед» по алгоритму, так и движение «назад». На is.ifmo.ru про это когда-то давно была статья.
Развивать не буду, если не понадобится в рамках работы. В данный момент всего хватает.
Насчет паттерна Command, не совсем понял, что ты имеешь ввиду. Мне в голову приходит только команда, у которой в имплементации самой команды встречается вызов автомата.
Насчет аналога отката транзакций, в ИТМО народ при разработке обучающего портала для иллюстрации алгоритмов придумал делать автоматы, которые моделируют как движение «вперед» по алгоритму, так и движение «назад». На is.ifmo.ru про это когда-то давно была статья.
На мой взгляд, в исходном коде не хватает комментариев, что является неким неудобством в понимании принципов работы.
Раз уж развитие библиотеки Вами не предвидится, то может дадите толчек к развитию некоторого сообщества разработчиков? Ибо предвижу: скачивания из SVN вечной(???) 6й ревизии, и локальные разработки будет лишь плодить бесчисленные клоны, итерация за итерацией теряя основную нить…
Я бы поддержал этот проект. Если что — напишите в ЛС. Тем более тема подобной библиотеки для меня актуальна.
Раз уж развитие библиотеки Вами не предвидится, то может дадите толчек к развитию некоторого сообщества разработчиков? Ибо предвижу: скачивания из SVN вечной(???) 6й ревизии, и локальные разработки будет лишь плодить бесчисленные клоны, итерация за итерацией теряя основную нить…
Я бы поддержал этот проект. Если что — напишите в ЛС. Тем более тема подобной библиотеки для меня актуальна.
Не комментировал исходя из принципа «не комментируйте очевидное». Сам по себе код там очень простой, его мало, неочевидных моментов нет. А чтобы в целом понять, как работает FSM, смотрите юнит-тесты (они, в отличие от комментариев, не врут).
Сообщество, развитие библиотеки и т.п. — это мне неинтересно. Я в данном случае просто поделился удачной идеей, но каких-либо качественных направлений в развитии библиотеки пока не вижу.
Если тебе интересно заняться централизованной поддержкой и развитием библиотеки — ничего не имею против. Могу дать доступ в проект на Google Code, а коллеги с www.devprom.net уже предлагали захостить проект у них.
Сообщество, развитие библиотеки и т.п. — это мне неинтересно. Я в данном случае просто поделился удачной идеей, но каких-либо качественных направлений в развитии библиотеки пока не вижу.
Если тебе интересно заняться централизованной поддержкой и развитием библиотеки — ничего не имею против. Могу дать доступ в проект на Google Code, а коллеги с www.devprom.net уже предлагали захостить проект у них.
Насколько просто составить композицию двух и более FSM?
Технически – несложно. Есть три способа.
1. Один автомат в своих условиях переходов проверяет, в каком состоянии находится другой автомат. Можно делать это явно (что-то вроде a1.y() == A.READY), но обычно такие проверки спрятаны в методах – getter'ах того класса, которым управляет автомат a1.
2. Один автомат вызывает другой автомат из своих действий, выполняемых в enter() или в exit(). Как и в предыдущем случае, можно явно вызвать a1.handleEvent(), но обычно этот вызов спрятан в методах того класса, которым управляет автомат a1.
3. Третий вариант самый интересный – вложенные автоматы. Один автомат как-бы расширяет поведение другого автомата для одного (или нескольких) из его состояний. В этом случае handleEvent() одного автомата вызывается из handleEvent() другого (а также, при необходимости, и их enter() и exit()). Пример в файле FSMTestIncl.java.
1. Один автомат в своих условиях переходов проверяет, в каком состоянии находится другой автомат. Можно делать это явно (что-то вроде a1.y() == A.READY), но обычно такие проверки спрятаны в методах – getter'ах того класса, которым управляет автомат a1.
2. Один автомат вызывает другой автомат из своих действий, выполняемых в enter() или в exit(). Как и в предыдущем случае, можно явно вызвать a1.handleEvent(), но обычно этот вызов спрятан в методах того класса, которым управляет автомат a1.
3. Третий вариант самый интересный – вложенные автоматы. Один автомат как-бы расширяет поведение другого автомата для одного (или нескольких) из его состояний. В этом случае handleEvent() одного автомата вызывается из handleEvent() другого (а также, при необходимости, и их enter() и exit()). Пример в файле FSMTestIncl.java.
Я так понимаю в ExtGWT реализован похожий подход?
Не видел… Можно линк?
Сори, я почемуто подумал что ExtGWT также известен для GWT разработки, как Spring и Hibernate для серверной java.
Линк: extjs.com/products/gxt/
Линк: extjs.com/products/gxt/
Я не это имел ввиду. Естественно я знаю и про GXT, и слегка внутри GXT. Но реализации конечного автомата там не видел. Именно на описание этой реализации я и просил линк — интересно посмотреть, как сделано у них. И сделано ли вообще, повторю, что не заметил в этой библиотеке подобных классов.
Ни разу не оно.
В GXT есть простенькая база для реализации MVC (Observable, Event Dispatcher, Binding), не более того.
В GXT есть простенькая база для реализации MVC (Observable, Event Dispatcher, Binding), не более того.
> PS. Уверен, что на Groovy или на Ruby аналогичную реализацию можно сделать еще более красивой.
Если кого-то это интересует, вот довольно яркий пример, как это выглядит с использованием предметно-ориентированных языков (DSL): www.youtube.com/watch?v=KTmwXr52cwM
Если кого-то это интересует, вот довольно яркий пример, как это выглядит с использованием предметно-ориентированных языков (DSL): www.youtube.com/watch?v=KTmwXr52cwM
Only those users with full accounts are able to leave comments. Log in, please.
Implementing FSM