In an ASP.NET application, you can move between Web Forms in a variety of ways: with hyperlinks, with Response.Redirect, with Server.Transfer, or with Server.Execute. In this article, I will take a look at these various navigation methods and help you choose the appropriate one for your application.
The simplest possible way to navigate from one Web Form to another is with an HTML hyperlink control. On a Web Form, that might look like this:
<a href="WebForm2.aspx">WebForm2</a>When the user clicks on the hyperlink, WebForm2.aspx is served up to their browser. You can use this technique just about anywhere, including on HTML pages and in classic ASP. ASP.NET gives you another alternative, the HyperLink Web Server control:
<form id="Form1" method="post" runat="server">
<asp:HyperLink id="HyperLink1" runat="server"
NavigateUrl="WebForm2.aspx">WebForm2</asp:HyperLink>
</form>At runtime, this HTML has exactly the same effect as the first example, since
ASP.NET renders the HyperLink Web Server control as an HTML hyperlink control.
There is one key difference, though: the Web Server control can be programmed on
the server side. In particular, you can change its NavigateUrl property in code,
opening up the possibility of a hyperlink whose destination depends on some part
of your application's state:
Private Sub Button1_Click( _
ByVal sender As System.Object, _
ByVal e As System.EventArgs) _
Handles Button1.Click
HyperLink1.NavigateUrl = "WebForm3.aspx"
End SubIf the user clicks on the hyperlink after this code has executed, then the link will serve up WebForm3.aspx instead of WebForm2.aspx.
Although hyperlinks do transfer your application from one page to another,
they do so completely under the control of the user. Sometimes it's convenient
to control the entire process in code yourself, including deciding when to move
to another page. As it happens, ASP.NET provides three different methods to
accomplish this. You can call the Redirect method of the Response object, or the
Transfer or Execute methods of the Server object. Although they behave very
similarly, there are differences between these three methods.
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.
|
Related Reading .NET Framework Essentials |
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.
|
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 SubNow 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, as shown in Figure 1. 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.
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:
Hyperlinks are appropriate when you want the end user to control when navigation is performed, or to choose where to go.
To control the user's destination, but let them decide when to get there,
use a Web Server HyperLink control whose NavigateUrl property is dynamically
set.
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.
Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics.
Return to ONDotNet.com.
Copyright © 2009 O'Reilly Media, Inc.
