Spring WebFlow のアイデアが気に入っています。特に、フロー定義が Spring Bean コンテナー内のコンポーネントから高レベルの Web フローを抽象化する方法が気に入っています。
フロー定義形式には、ビュー、アクション、トランジション、サブフロー、結果など、Web フローに必要なものがすべて含まれているようです。
Spring WebFlow フロー定義形式は、Spring 以外のフレームワークの Web フローを外部化するのに適していると思いますか? 基盤となるコンポーネントに Spring を使用しないもの、またはおそらく Java を使用しないもの。
一般的なワークフローや BPEL タイプのものではなく、特にページ フローのみを考えていることに注意してください。
最初のWebアプリが構築されて以来、ステートマシン（スプリングWebフローなど）を使用してWebアプリフローを記述してきました。そうです、大丈夫です。なぜ誰もがそれをしていないのですか？ステートマシンを使用してWebフローを記述する場合、形式主義が少し行き過ぎてしまう傾向があると思います。良いアイデアとして始まったものは、最終的にはもっと苦痛になります。特定のページでのAjaxと複数の同時アクティブ状態は、それをさらに悪化させます。
私の意見では、SWF の最大の強みは、フロー (ナビゲーション) を 1 か所に集中させ、わかりやすく、読みやすく、操作しやすくすることです。ページ間を行き来するような、より複雑なナビゲーション フローに適しています。 、またはウィザードのような UI または段階的な UI 用。また、サブフローやフロー継承などの高度な再利用機能も備えています。
ビュー ステートとアクション ステートの概念は、ユーザーがイベントを作成した後にアクションへの遷移が発生し、次のビューがユーザーに提示され、マシンが次のユーザー イベントを待機している状態にある、ユーザーと Web アプリの対話をよく模倣しています。これらのフローはサーバー側で発生することに注意してください。最近では、すべてがクライアント側に移行しているように見えますが、それでもステート マシンがその役割を果たすことができます。たとえば Flex には、状態と遷移の概念があります。これらは、プログラマーが多くのコントロールを持つ複雑な UI を管理するのに役立ちます。状態は、コントロールなどを表示または非表示にすることができます。したがって、これはフローとユーザー インタラクションをモデル化するための非常に優れたパラダイムであると言えます。