您认为 Spring WebFlow 流定义格式适合为非 Spring 框架外部化 Web 流吗？
我喜欢 Spring WebFlow 的想法 - 特别是流定义从 Spring Bean 容器中的组件抽象出更高级别的 Web 流的方式。
Flow 定义格式似乎包含 Web Flow 中所需的一切 - 视图、操作、转换、子流、结果等。
您认为 Spring WebFlow Flow Definition 格式适合为非 Spring 框架外部化 Web Flow 吗？ 其底层组件不使用 Spring，甚至可能不使用 Java。
请记住，我只考虑特定的页面流，而不是一般工作流或 BPEL 类型的内容
I like the idea of Spring WebFlow - particularly the way the flow definitiion abstracts the higher level web flow from components in the Spring Bean Container.
The Flow definition format seems to include everything one needs in a Web Flow - views, actions, transitions, subflows, outcomes etc.
Do you think the Spring WebFlow Flow Definition format would be suitable for externalising a Web Flow for a non Spring framework? Something that does not use Spring, or perhaps even Java, for its underlying components.
Bear in mind, I am thinking of only page flow in particular, not general workflow or BPEL type stuff
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
自从第一个 Web 应用程序构建以来，状态机（如 Spring WebFlow）就被用来描述 Web 应用程序流程。 所以是的，没关系。 为什么不是每个人都这样做？ 我认为，当使用状态机来描述网络流时，形式主义有一种过度的倾向。 一开始是个好主意，最终却变得更加痛苦。 Ajax 和给定页面上的多个并发活动状态使情况变得更糟。
State machines (like spring webflow) have been used to describe web-app flows since the first web-apps were built. So yes it's ok. Why isn't everybody doing it ? I think that when using state machines to describe web-flows there is a tendency for formalism to take a little bit too much over. What starts off as a good idea ends up being more of a pain. Ajax and multiple concurrent active states on a given page makes it even worse.
在我看来，SWF 的最大优势在于将流程（导航）集中在一个地方，并使其明确、易于阅读、操作等。它非常适合更复杂的导航流程，您可能会在页面之间来回切换，或用于类似向导或分步式 UI。 它还具有一些高级重用功能，例如子流和流继承。
视图状态和操作状态的概念很好地模仿了用户 - Web 应用程序交互，其中在用户创建事件后发生到操作的转换，然后将下一个视图呈现给用户，并且机器处于等待下一个用户事件的状态。
值得注意的是，这些流程发生在服务器端。 如今，Everythnig 似乎正在转向客户端，即使如此，状态机也可以发挥其作用。 例如，Flex 有一个状态和转换的概念。 这些应该可以帮助程序员管理具有大量控件的复杂 UI。 状态可以隐藏或显示控件等等。
所以，我想说这可能是一个非常简洁的流程和用户交互建模范例。
The biggest strength of the SWF in my opinion is that centralizes flow (navigation) in a single place and makes it explicit, easy to read, manipulate etc. It is well suited for more complex navigation flows where you might go back and forth between pages, or for wizard-like or step-by-step UIs. It also has some advanced reuse features like subflows and flow inheritance.
The concept of view state and action state well mimics user - web app interaction where transition to action occurs after user has created an event, then the next view is presented to a user and the machine is in a state waiting for next user event.
It is important to note that these flows occur on server side. Everythnig seems to be moving to a client side these days and even so state machine can have its role. Flex for example has a concept of states and transitions. These should help programmer manage complex UIs with lots of controls. States can hide or display controls and much more.
So, I’d say this can be a very neat paradigm for modeling flows and user interactions.