-----------------------------------------------------------
New Message on MumbaiUserGroup
-----------------------------------------------------------
From: Swapnil_B1
Message 1 in Discussion
Response.Redirect
In earlier versions of IIS, if we wanted to send a user to a new Web page, the
only option we had was Response.Redirect. While this method does accomplish our
goal, it has several important drawbacks. The biggest problem is that this
method causes each page to be treated as a separate transaction. Besides making
it difficult to maintain your transactional integrity, Response.Redirect
introduces some additional headaches. First, it prevents good encapsulation of
code. Second, you lose access to all of the properties in the Request object.
Sure, there are workarounds, but they're difficult. Finally, Response.Redirect
necessitates a round trip to the client, which, on high-volume sites, causes
scalability problems.
The Response.Redirect method causes the browser to connect to a specified URL.
When the Response.Redirect() method is called, it creates a response whose
header contains a 302 (Object Moved) status code and the target URL. When the
browser receives this response from the server, it uses this header information
to generate another HTTP request to the new URL. When using the
Response.Redirect method, the redirection happens at the client side and
involves two round trips to the server: one to request the original page, which
is met by the 302 response, and then a second to request the redirected page.
Server.Transfer
The Server.Transfer method transfers execution from the current ASPX file to
another ASPX file on the same web Server. When your code calls the
Server.Transfer method, the current ASPX page terminates execution and the flow
of control is transferred to another ASPX page. The new ASPX page still uses
the response stream created by the prior ASPX page. When you use this method to
navigate between pages, the URL in the browser still shows the original page,
because the redirection occurs on the server side and the browser remains
unaware of the transfer.
By default, the Server.Transfer method does not pass the form data or the query
string of the original page request to the transferred page. But you can
preserve the form data and query string of the original page by setting the
optional second argument of the method to True. When you use this technique,
though, you need to aware of one thing: the destination page uses the same
response stream that was created by the original page, and therefore the hidden
_VIEWSTATE field of the original page ends up on the second page. This causes
the ASP.NET machine authentication check (MAC) to assume that the ViewState of
the new page has been tampered with. Therefore, when you choose to preserve the
form and query string collection of the original page, you must set the
EnableViewStateMac attribute of the Page directive to False for the destination
page.
But watch out: because the "transfer" process can work on only those sites
running on the server, you can't use Server.Transfer to send the user to an
external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can
really help streamline data entry techniques, although it may make for
confusion when debugging.
That's not all: The Server.Transfer method also has a second
parameter—"preserveForm". If you set this to True, using a statement such as
Server.Transfer("WebForm2.aspx", True), the existing query string and any form
variables will still be available to the page you are transferring to.
For example, if your WebForm1.aspx has a TextBox control called TextBox1 and
you transferred to WebForm2.aspx with the preserveForm parameter set to True,
you'd be able to retrieve the value of the original page TextBox control by
referencing Request.Form("TextBox1").
So, in brief: Response.Redirect simply tells the browser to visit another page.
Server.Transfer helps reduce server requests, keeps the URL the same and allows
you to transfer the query string and form variables.
Server.Execute
The Server.Execute method allows the current ASPX page to execute a specified
ASPX page on the same web server. After the specified ASPX page is executed,
the control transfers back to the original page from which the Server.Execute
method was called. This technique of page navigation is analogous to making a
function call to an ASPX page. The called ASPX page has access to the form and
query string collections of the calling page, and thus you need to set the
EnableViewStateMac attribute of the Page directive to False on the executed
page.
By default, the output of the executed page is added to the current response
stream. This method also has an overloaded version in which the output of the
redirected page can be fetched in a TextWriter object (or one of its children,
such as a StringWriter object) instead of added directly to the response
stream. This helps you to control where to place the output in the original
page.
To see how this works, create a Web Form in a test ASP.NET application and
place a Button control (Button1) and a Literal control (Literal1) on the Web
Form. Switch to code view and add an Imports statement for the System.IO
namespace. Then add code to execute when the user clicks the button:
Private Sub Button1_Click( _
ByVal sender As System.Object, _
ByVal e As System.EventArgs) _
Handles Button1.Click
Dim sw As StringWriter = New StringWriter()
Server.Execute("WebForm2.aspx", sw)
Literal1.Text = sw.ToString()
End Sub
Now create a second Web Form in the same application, WebForm2.aspx. Switch to
the HTML view of this second Web Form and modify its Page directive to disable
ViewState checking:
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="WebForm2.aspx.vb"
Inherits="Navigate.WebForm2" EnableViewStateMac="false"%>
Switch back to design view and add some controls to the second Web Form. Now
set the first Web Form as the default page and start the application. Click the
button, and the controls from WebForm2 will be displayed in the area of
WebForm1 where you placed the Literal control. You'll note from the URL and
page title that the browser is still displaying WebForm1.
There's one more thing to be aware of when you use the Server.Transfer or
Server.Execute methods to navigate: the ultimate page may not be valid HTML.
That's because the response to the client will contain multiple <html> and
<body> tags, among other tags. Internet Explorer seems to tolerate this
situation just fine, but you may want to test the results carefully if your
users prefer a different browser.
Decisions
So, given these choices for navigating from page to page, how do you select the
appropriate one for your application? Here are some things to think about:
Use Response.Redirect to connect to resources outside of the web server where
your page is hosted. Use Response.Redirect to connect to non-ASPX
resources such as HTML pages. Use Response.Redirect if you need to
preserve a query string as an explicit part of the URL. When you want to
transfer control to an ASPX page residing on the same web server, you should
use Server.Transfer instead of Response.Redirect because Server.Transfer will
avoid the unnecessary round trip and provide better performance and a better
user experience. To capture the output from an ASPX page and display it
at a specified location on another ASPX page, use Server.Execute. If
valid HTML output is essential, use Response.Redirect instead of either the
Server.Transfer or Server.Execute methods.
Swapnil (swaps)
http://swapsnet.spaces.live.com/
-----------------------------------------------------------
To stop getting this e-mail, or change how often it arrives, go to your E-mail
Settings.
http://groups.msn.com/MumbaiUserGroup/_emailsettings.msnw
Need help? If you've forgotten your password, please go to Passport Member
Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help
For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact
If you do not want to receive future e-mail from this MSN group, or if you
received this message by mistake, please click the "Remove" link below. On the
pre-addressed e-mail message that opens, simply click "Send". Your e-mail
address will be deleted from this group's mailing list.
mailto:[EMAIL PROTECTED]
