NavigateURL = "WebForm2.aspx"> Enter Form 2
The operation results of the above HTML code are the same as the first example because ASP.NET treats the HyperLink web server control as an HTML hyperlink control. But both have a little important difference, HyperLink Web Server Controls can be programmed on server-side. Specifically, it can be changed in the program code, allowing constructing a specific target to dynamically change the hyperlink based on the current state of the application, for example:
Private sub button1_click
Byval sender as system.Object, _
ByVal e as system.eventargs)
Handles button1.click
Hyperlink1.navigateURL = "Webform3.aspx"
End Sub
After this code is executed, if the user clicks on the link, he sees will be Webform3.aspx instead of WebForm2.aspx.
Second, use program control redirection
Although the hyperlink can navigate from a page to another, this navigation method is completely controlled by the user. Sometimes, we may have to use code to control the entire navigation process, including when to go to another page. In these cases, ASP.NET has three different ways to achieve similar purposes: call the REDIRECT method of the Response object, call the Transfer or Execute method of the Server object. These three navigation methods are basically similar, but there is also a difference.
2.1 Response.Redirect
The Response.Redirect method causes the browser to link to a specified URL. When the response.redirect () method is called, it creates a response, indicating that the status code 302 (indicating the target has changed) and the new target URL. The browser receives the response from the server and uses the information in the response head to issue a request for the new URL.
That is to say, the redirection operation occurs in the client when using the response.redirect method, involving two communication with the server (two rounds): The first time is a request for the original page, get a 302 answer, second The second is the new page declared in the request 302 to get the page after redirect. 2.2 Server.Transfer
Server.Transfer methods Turn the execution process from the current ASPX file to another ASPX page on the same server. When calling Server.Transfer, the current ASPX page is terminated, the execution process is transferred to another ASPX page, but the new ASPX page still uses the response created by the previous ASPX page.
If you use the Server.Transfer method to implement the navigation between the page, the URL in the browser will not change because the redirection is completely on the server side, and the browser does not know that the server has already executed a page transformation at all.
By default, the Server.Transfer method does not pass the form data or query string from one page to another, but as long as the second parameter of the method is set to true, you can retain the form of the first page. And query strings.
At the same time, attention should be noted when using Server.Transfer: The target page will use the response created by the original page, which causes the ASP.NET's machine authentication check (Mac) that the viewState of the new page has been tampered with. Therefore, if you want to keep the form data and query string collection of the original page, you must set the enableViewStateMac property of the target page to false.
2.3 Server.execute
The server.execute method allows the current ASPX page to perform a specified ASPX page on the same web server. When the specified ASPX page is executed, the control process re-returns the location of the server.execute call.
This page navigation mode is similar to a function call to the ASPX page. The page that is called can access the form data and query string collection that sent the call page, so set the enableViewStateMac property of the called page Page instruction to false.
By default, the output called the page is appended to the current response. However, the Server.execute method has an overloaded method that allows the output of the called page to be called through a TextWriter object (or its sub-object, such as StringWriter object), not directly to the output stream, which is in the original page. It can be convenient to adjust the location of the resulting result of the called page.
To illustrate the working process, let's create a web form, put a button control (Button1) and a text control (Literal1), transfer to the code view in the design interface, join a system.io namespace of the Imports statement, then Join the code to execute when you click 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
Then create a second page WebForm2.aspx for the same web application. Transfer to the HTML view of the page, modify its Page instructions to prohibit the viewState check: <% @ page language = "VB" autoeventwireup = "false" codebehind = "Webform2.aspx.vb"
Inherits = "navigate.webform2" enableViewStateMac = "false"%>
Go to the design view, add some controls for the second page. Next, set the first page to the default page, start the application. Click the button, the WebForm2 control will display the place where the Literal button is placed in WebForm1, pay attention to the page title and URL still display the original page WebForm1.
When you use the server.transfer or server.execute method, you should pay attention to a point: the final page may not be a legitimate HTML page, because the page that is finally returned to the client may contain multiple and
and other tags. IE views seem to tolerate and handle this situation correctly, but if users want to use other browsers, it is best to test it carefully.
