This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Originally posted by Deepak AL: 1> I wanted to know the "Differences" between response.sendRedirect and Requestdispatcher.forward
A forward() is like a server side include. Your original page begins managing the response, then forwards the responsibility for the response to another page. The user is completely oblivious that the change in control has been made.
A sendRedirect() is a Response to the client telling them to go to a different page. The first page (usually a servlet) begins to handle the job requested by the user. It finishes its job, then sends a Response to the Client to go to the next page. The Client then automatically makes a new Request to the second page (which is usually a JSP for display).
Some key differences: 1) You can only forward() to pages on the same server, and without special configuration only to pages in the same context. With sendRedirect() you can redirect to any page on the internet.
2) The forward() passes on responsibility for a request/response to the next page. This means that the Request object and Response object are shared between the caller and the callee. You can store data in the Request and get it from the forward()ed page. With the sendRedirect, a New Request is made, so you can't store data in the Request scope to share it between pages.
3) With a forward() the user sees the URL of the original page (the one doing the forward()ing) - including any form parameters that were submitted. They do not see the URL of the forward()ed to page. If the user bookmarks the page, refreshes the page, or decides to memorize the URL to type it in later they would be brought to the forward()ing page, which would do its work again. With a sendRedirect() the user doesn't see the redirecting URL so if he bookmarks/memorizes/refreshes the page, this second page gets used, the processing page that does the redirect will not be re-invoked. Same thing applies to using the Back button.
Originally posted by Deepak AL: 2> when do we Opt for response.sendRedirect?
I generally use sendRedirect when I am done processing a POST request. A POST request can change the state of the server/user session in an 'important' manner, such as adding information to the database, adding items to a shopping cart, or submitting credit card orders. Or perhaps the user is simply logging in. These are actions that I don't want the user to do a second time if they press the Refresh button, or navigate away from the page then press the Back button.
Originally posted by Deepak AL: 3> when do we Opt for Requestdispatcher.forward?
I generally will do a forward() for any page that I can access using a GET request. The GET request should not affect the state of the server, but simply poll for information, like "Get books for authors A-Ar" or "Look for hotel rooms in Fremont CA on September 1". Since these tasks can be performed multiple times without changing the state of the sever, they should be allowed to be done over and over again. Users should be able to see the URL so they can bookmark them, or send the URL to others and allow them to see the same results. I would want to make sure the forward()ing URL gets remembered in these cases, not the forward()ed URL, because that first page is usually my Controller and usually responsible for collecting the data while the second page is usually a View and responsible for displaying the data. I would want to make sure all requests go to the Controller so the proper data is available for View.
"Deepak AL", please check your private messages for an important administrative matter.
And, please use real words when posting to the forums. Abbreviations such as "btwn" in place of "between" only serve to make your posts more difficult to read and less likely to generate useful responses.