无状态模式下的 JSTL 和绑定
JSTL and bindings in the stateless mode
摘自一本书，
For a stateless view, the component tree cannot be dynamically
generated/changed (for example, JSTL and bindings are not available in
the stateless mode). You can't create/manipulate views dynamically.
我完全理解 login 形式的无状态概念。
我不明白的是作者的观点，JSTL 和绑定在无状态模式下不可用。请说明。
作者好像自己也糊涂了或者笼统得有点过分了
组件树当然还是可以动态的generated/changed。这不依赖于 stateful/stateless 模式。与有状态模式的唯一区别是那些动态操作不会在 JSF 状态中被记住，因此它们无法在回发中恢复。
如果在视图构建期间由 非 用户事件发起这些动态更改，例如 @PostConstruct通过 binding 属性或 postAddToView 事件侦听器方法引用的请求作用域 bean。它只会被重新执行。但是，如果方法逻辑又依赖于某些用户控制的 variables/actions，例如请求参数或在先前回发期间调用的操作，或者它执行得太晚，例如在 preRenderView 事件期间，那么它是不再保证视图将在后续回发的应用请求值阶段变得与呈现要提交的表单期间相同。在这种情况下，与有状态视图相比，处理表单提交的行为可能 "unexpectedly" 不同。
摘自一本书，
For a stateless view, the component tree cannot be dynamically generated/changed (for example, JSTL and bindings are not available in the stateless mode). You can't create/manipulate views dynamically.
我完全理解 login 形式的无状态概念。
我不明白的是作者的观点，JSTL 和绑定在无状态模式下不可用。请说明。
作者好像自己也糊涂了或者笼统得有点过分了
组件树当然还是可以动态的generated/changed。这不依赖于 stateful/stateless 模式。与有状态模式的唯一区别是那些动态操作不会在 JSF 状态中被记住，因此它们无法在回发中恢复。
如果在视图构建期间由 非 用户事件发起这些动态更改，例如 @PostConstruct通过 binding 属性或 postAddToView 事件侦听器方法引用的请求作用域 bean。它只会被重新执行。但是，如果方法逻辑又依赖于某些用户控制的 variables/actions，例如请求参数或在先前回发期间调用的操作，或者它执行得太晚，例如在 preRenderView 事件期间，那么它是不再保证视图将在后续回发的应用请求值阶段变得与呈现要提交的表单期间相同。在这种情况下，与有状态视图相比，处理表单提交的行为可能 "unexpectedly" 不同。