Считаете ли вы, что формат определения Spring WebFlow Flow подойдет для экстернализации Web Flow для фреймворка, отличного от Spring?

Конечные автоматы (например, Spring webflow) использовались для описания потоков веб-приложений с момента создания первых веб-приложений. Так что да, все в порядке. Почему не все это делают? Я думаю, что при использовании конечных автоматов для описания веб-потоков существует тенденция к тому, что формализм берет слишком много лишнего. То, что начиналось как хорошая идея, в конечном итоге становится болью. Ajax и несколько одновременных активных состояний на данной странице еще больше усугубляют ситуацию.

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

Концепция состояния просмотра и состояния действия хорошо имитирует взаимодействие пользователя с веб-приложением, когда переход к действию происходит после того, как пользователь создал событие, затем пользователю предоставляется следующее представление, и машина находится в состоянии ожидания следующего пользовательского события. Важно отметить, что эти потоки происходят на стороне сервера. В наши дни все, кажется, переходит на клиентскую сторону, и даже в этом случае конечный автомат может играть свою роль. Например, Flex имеет концепцию состояния и переходов. Это должно помочь программисту управлять сложными пользовательскими интерфейсами с большим количеством элементов управления. Состояния могут скрывать или отображать элементы управления и многое другое. Итак, я бы сказал, что это может быть очень изящная парадигма для моделирования потоков и взаимодействия с пользователем.