小项目总结之三：页面转发（forward以及redirect）

总结一下内容。

      直观的感觉，使用forward可以使用request来传递参数进入下一个页面，而使用sendRedirect使用request无货传递到下一个页面，我们要使用session来传递。

另外我想先谈谈对于session的理解。

      其实我们的session该你是这样的，是一个浏览器的作用范围（生命周期），即就是当我们打开浏览器访问页面时，服务器会在初次访问时给每个进程设置一个可以记录的标志，就是SessionID，存放于服务器端并且通过加载于HTTP头部发送客户端，在以后每次这个浏览器与服务器交互的时候，会带着这个SessionID与服务器来回话操作。

      于是问题出现了，当我们将浏览器关闭的时候，是不会给服务器发送任何消息的，也即是说服务器无法获取我们客户端将浏览器关闭的事件。因此，迫使服务器端不得不采取这样一种设计方案，设置session的过期时间，问题就这样解决了。    

      另外还有一个平常的误区就揭开了，我们关闭了一个浏览器session就销毁了，这个session现在是无法获取了的（除非采用另外一种简单的方法，下边会介绍），服务器端会为我们解决，但是它不是随着浏览器的关闭而消亡，浏览器的关闭对他影响不大。

      其实上述的讨论只是一种类型的session，常常概念上叫做会话session。要是我们将浏览器关闭了，在下次进来的时候还想保持以前的状态呢？这时候采用了Cookie技术，他简单的保留了我们的sessionId，当然似乎有些什么绑定的信息，以后再研究，也就是说他记录了我们访问过的网页的一些历史信息，最重要的是sessionID，我们在下次访问这个页面的时候，首先查找看有没有关于他的信息，有的话取出来，直接发送给服务器，要是服务器上这个sessionId还存活的话，就可以获取历史信息了，及我们要保存的信息。此种一般我们称之为保持session.

      我们登录网站时一般会询问是不是要保留，并且多长时间，实际上均是保持session做的事，像Javaeye也是如此。当时以为它（javaeye）的设计有问题，为什么我选择了那个永久登录，在重新打开时有时候会失去我的信息，最后发现，是我的失误：我使用魔法兔子清除了一些垃圾文件，当然有时候也就吧那个信息给清除了。

      好了言归正传。

1.RequestDispatcher.forward()

      是在服务器端起作用,他只是服务器内部的一种自动转向，对于外部（客户端）是检测不到的，因此我们的外在表现即为：浏览器的地址没有变化，但是我们赚到了另外一个页面，并且参数也通过request传了过去。

      在a.jsp用到了forward()重定向至b.jsp,此时form提交的所有信息在b.jsp都可以获得,参数自动传递。但forward()无法重定向至有frame的jsp文件,可以重定向至有frame的html文件,同时forward()无法在后面带参数传递,比如servlet?name=frank,这样不行,可以程序内通过response.setAttribute("name",name)来传至下一个页面，也就是说不能通过parameter传递而只能通过attribute在request中记录传递。

      因为完成一个业务操作往往需要跨越多个步骤，每一步骤完成相应的处理后，转向到下一个步骤。比如，通常业务处理在Servlet中处理，处理的结果转向到一个 JSP页面进行显示，类似于Servlet链的功能。

例:servlet文件中重定向

public void doPost(HttpServletRequest request,HttpServletResponse response)throws ServletException,IOException { 

     ServletContext sc = getServletContext(); 

     request.setAttribute("info","info"); 

     RequestDispatcher rd = sc.getRequestDispatcher("/index.jsp"); 

    rd.forward(request, response); 

} 

 

 

2.response.sendRedirect()

      是在用户的浏览器端工作,sendRedirect()可以带参数传递,比如servlet?name=frank传至下个页面,同时它可以重定向至不同的主机上,且在浏览器地址栏上会出现重定向页面的URL，此时假如你还用简单的attribute传递的时候，问题出现了，每次均为空？于是我们改进方案，拿出来我们的session，用request获取session信息，在此处可以采用attribute传递了，相当于将attribute提升了一个更高的层次，在浏览器的作用范围内。

     他实际上的表现效果相当于用户在页面直接输入一个网址，然后按那个转向键。

public void doGet(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException { 

    request.getSession().setAttribute("newsxmlinfo", list); 

    request.getSession().setAttribute("flag", "news"); 

   response.sendRedirect(request.getContextPath()+ "/pages/news/news.jsp?info=info&info=info"); 

} 

 

     这个方法将响应定向到参数location指定的、新的URL。location可以是一个绝对的URL，如response.sendRedirect ("http://java.sun.com")也可以使用相对的URL。如果location以"/"开头，则容器认为相对于当前Web应用的根，这种重定向的方法，将导致客户端浏览器的请求URL跳转，地址栏中可以看到新的URL地址。

 

3.继续思考

RequestDispatcher.forward()方法和HttpServletResponse.sendRedirect()方法的区别是：

      前者仅是容器中控制权的转向，在客户端浏览器地址栏中不会显示出转向后的地址；

      后者则是完全的跳转，浏览器将会得到跳转的地址，并重新发送请求链接。

      这样，从浏览器的地址栏中可以看到跳转后的链接地址。现在你还在为参数的传递烦恼么?? 对于过度使用session传递的问题，应当深思。

      对于向导式页面，session是无法替代的，否则参数传递太复杂了。

      对于一般不太复杂的小型项目，session也是不会有太大的影响。其实还不是我以前认识的那么恐怖，只是控制好就可以了。 什么时候清楚这个session的问题？考虑中，最佳时机。不然每次request不是很臃肿？？

      有没有好的建议？谢谢。