第六章：高级OAF开发话题---支持浏览器后退按钮

本文档提供了一系列的目标并描述了一些你必须遵守的编码标准来确保强壮的浏览器后退按钮支持。

可用性测试表明用户高度依赖浏览器后退按钮，不幸的是，在事务处理程序中，这个导航的首选方法带来了一系列的潜在错误点。例如，考虑下面OAF使用中可能的场景，他们没有完全预期浏览器后退按钮导航的结果。

 

 用户导航场景问题

 

用户从一个表中删除了一行数据，同时页面重绘并给出了一个确认行已删除的消息（表中已经不存在改行数据），然后用户点击后退按钮，显出出改行依然存在的页面，用户再尝试第二次删除改行

浏览器缓存了页面内容，如果用户执行了一个动作改变了数据状态，然后使用浏览器后退按钮，浏览器的页面缓存内容并没有正确的反映中间层状态（在这个例子里，一行不再存在）。

如果用户尝试删除，或者别的事务，缓存页面中这一行已经删除的数据将导致一个难看的运行时程序错误。

一个遵循后退按钮设计的页面应该可以检测到这样一个删除行的事务并优雅地显示一个用户友好的失败消息来指出改行已经被删除了

 

在一个购物车结账的处理中，用户选择了“提交订单”按钮来购买物品，出于各种原因，用户从确认消息页面导航到了之前的页面并且第二次点击“提交订单”（也许她认为她可以改变一些订购数量并且能够在之前的订单中反应出来）

 这个场景和上一个场景有些类似，然而这样无防备的操作将会得到一个“成功”的 事务重复提交（订单可能被创建两次，这可能不是用户所期望的）。

一个遵循后退按钮设计的页面应该检测到这样一个重复提交订单的操作并优雅地显示一个用户友好的失败消息来指出该订单已经提交了

 

用户从页面1导航到页面2，然后使用浏览器后退按钮导航到页面1，用户点击页面1的一个FORM提交组件，同时一个未处理的一场抛出（NullPointerException,
IndexOutOfBoundsException 或类似）

OAF页面1 预计Web Bean 层处于确定状态并且/或者需要显示事务、Session、BC4J对象状态值，当通过浏览器后退按钮导航时，这些状态将会丢失，如果这个页面没有预期到这些情况，用户将会看到未处理的异常。
一个遵循后退按钮设计的页面应该预料到这种可能丢失状态的场景，并且要么具有重建状态的能力来使功能正常完成，要么优雅地显示一个对用户友好的失败消息来指出这个页面不能通过浏览器后退按钮来访问