一、对于需要频繁操作的场合，从操作便利和快捷性出发，尽可能的减少服务器和客户端交互次数，应该避免使用中间过渡页面。提交完毕直接返回原来的表单页面或默认页面。在这种情况下要考虑到数据安全和可恢复性。
如果因为用户输入的数据不合格，需要重新输入，那么，去除中间页面，把错误信息直接显示在原表单页面上的设计方式，将是最简洁的处理方式。用户只需要根据错误提示进行更正即可。当然这样做稍微增加了编程负担。在表单接收页面上需要包含原表单页面的内容，而且输入数据项都必须用服务器端代码或客户端JavaScript设置成用户输入的值。为了开发快捷，可以这样做：表单页面和接收表单页面用同一个服务器端脚本页面实现。这个页面按如下流程完成原来两个页面的工作：
页面脚本初始化
┃
检查“提交”变量是否设置
┠已设置，做数据验证
┃ ┠验证通过－>业务逻辑处理－>使用包含页面方式或重定向方式返回到特定页面
┃ ┗验证不通过－>保存用户输入的数据－>退出表单提交处理到表单页面流程中
┗未设置，做表单页面流程，如有来自提交流程中产生的用户输入数据，则显示出来
其中，使用包含页面方式返回到特定页面可以避免一次客户端重定向过程，比客户端重定向过程还要快捷和稳定一些。但是有些情况下因为代码变量冲突或其他原因，使用包含页面方式可能并不方便，这时候可以使用服务器端重定向技术，在ASP里是Server.Transfer方法，在Java Servlet里是RequestDispatcher.forward()方法。不要使用Response.Redirect或者HttpServletResponse.sendRedirect()这种客户端HTTP重定向方法。不使用中间过渡页面也就意味着用户不能后退浏览原先已经填好的表单页面，因为使用的是同一个URL。所以在验证不通过情况下保存用户输入的数据就是必不可少的。
不使用中间过渡页面带来的另一个问题就是使用包含页面方式或服务器端重定向方式返回会使得URL和页面内容不能一一对应。对于用户可能会直接用这个URL（会收藏这个URL）访问返回页面的情况，他会发现实际上到达的是表单页面，不是他想要的那个返回结果页面。所以，去除中间过渡页面，确实会带来URL和内容含混不清的情况，因而不适合需要URL和页面内容一一对应的场合。
二、从技术角度考虑，使用中间过渡页面能保证URL和页面内容一一对应，简化页面开发工作。
为了保证页面内容总是和固定的URL联系起来，必须使用客户端重定向：
提交 业务逻辑处理 （中间过渡页面）
表单页面――――－>接收表单页面―――――――――>显示处理结果―――>客户端重定向到特定页面
客户端重定向分几种情况：1，使用HTTP Header重定向，Location:http://www.netall.com.cn，这种定向是最快的，在窗口一片空白的情况下就迅速访问（GET）另一个页面。这种方式实际上不能显示处理结果，只能说是向第一种快速重定向方式的一种折衷处理；2,HTML标签刷新，<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://www.netall.com.cn">，这种定向比较友好，在这个页面加载完毕后访问另一个页面。很多设计者把这个作为一个技巧使用，在载入一个大页面前放置一个缓冲页面以避免用户乏味的等待；3，JavaScript重定向。由于是用代码控制重定向，可以做的更灵活。比如根据用户习惯，控制操作完毕后的转向流程。4，被动式的重定向。在页面上放置按钮或链接，由用户手动决定返回到特定页面。这种情况适合于处理结果的显示页面包含相当多的信息，需要用户仔细浏览，而决定下一步的操作。
在使用中间过渡页面的情况下，不能再使用页面过期失效了。否则一旦出现错误，需要用户重新输入表单数据，用户就不能用后退按钮恢复此前填写的表单数据了。除非设计者有意禁止这种恢复。
6． 防止表单重复提交处理
对提交按钮点击后做变灰处理避免在网络响应较慢情况下用户重复提交同一个表单。使用页面过期失效避免用户后退浏览重复提交表单。
有些复杂的应用会导致需要较长时间的等待才会返回处理结果。而在较慢的网络环境中，这种情况更是频繁发生。焦急等待的用户往往会重复点击提交按钮。这种情况是设计者所不希望看到的。
使用JavaScript在点击提交按钮后使按钮失效变灰是一个最直接的办法（根据原则2这段代码应该放在<form>标签里onSubmit=”…”做）。此外，在表单页面上，用服务器端脚本设置HTTP Header的Expires为立即过期可以保证用户没办法使用后退浏览恢复表单页面。注意这样做的代价可能是用户辛辛苦苦填写很长的内容，结果一旦操作失误就没法恢复。所以应该避免在包含<textarea>表单元素的页面上使用页面过期失效。
应该说，更严格的方法是，服务器端脚本就应该具备抵抗重复提交的能力。例如，为这个表单分配一个唯一ID或一个使用一次即失效的验证码。此外，这个表单处理还应具有事务性质，如果表单不被接受，所做的改变还是能恢复的。在金融应用场合，重复提交同一笔交易是肯定不被允许的。能在重复提交中获利的一方总是会想办法绕过浏览器的限制，所以不能依赖于客户端的技术。
