借助 Ajax 自动保存 JSF 表单: 第 3 部分：保存 JSF 表单中的用户输入

核心提示： 跳过某些 JSF 请求处理阶段前面一节讨论的 renderResponse() 调用与本节讨论的 renderResponse() 调用没有任何关系，JSF 框架在 Restore View 阶段执行前一个调用，借助 Ajax 自动保存 JSF 表单: 第 3 部分：保存 JSF 表单中的用户输

跳过某些 JSF 请求处理阶段

前面一节讨论的 renderResponse() 调用与本节讨论的 renderResponse() 调用没有任何关系。JSF 框架在 Restore View 阶段执行前一个调用。而示例应用程序代码在 JSF 请求处理生命周期的 Apply Request Values 阶段执行后一种调用。

ViewRestorer 类的两个侦听器方法调用同一个类的 restoreCurrentView() 方法，而后者将调用 faces 上下文的 renderResponse() 方法。因此，请求处理将从 Apply Request Values 阶段直接跳跃到 Render Response 阶段，跳过了 Process Validations、Update Model Values 和 Invoke Application 阶段。

让我们分析一下 ViewRestorer 类的 restoreCurrentView() 方法的 renderResponse() 调用。首先，当使用 submitRestoreRequest() 函数提交表单以触发 ViewRestorer 的 valueChangeListener() 时，应用程序必须忽略所有已提交的数据。这就是 DataMapRepository 类的 restoreValues() 方法清除每个输入组件 submittedValue 属性的原因。丢失值一般会引起很多验证错误，但是不会出现在示例应用程序中，因为由于 renderResponse() 调用，没有对恢复请求执行 Process Validations 阶段。

使用 renderResponse() 跳过 Process Validations、Update Model Values 和 Invoke Application 阶段意味着您不用担心恢复请求的任何副作用。因此，在验证阶段后侦听阶段事件的 AutoSaveListener 类不会受到这些请求的影响，因此无需改变该类。此外，执行恢复请求后，将不会更新应用程序的数据模型并且也不会调用操作方法。如您所见，对恢复和自动保存请求应用了相同的规则，这些请求可以透明地进行处理，而不会打断应用程序的逻辑。

允许用户控制表单保存和恢复