Cross-Page Posting
| The postback architecture of ASP.NET is undoubtedly good, but it can be confusing to many traditional ASP programmers. The problem people have is not with automatically posting back to the same page but with not being able to specify another page to post to. There are reasons both for (security) and against (big pages) posting to another page and many people used Server.Transfer to move between pages. Content from the posting form was accessible only by ensuring the posting page was strongly typed or by storing it before posting (such as in the Items collection of the page). The biggest problem with Server.Transfer is that the original URL still shows in the browser. ASP.NET 2.0 has made cross-page posting easier by allowing button controls to indicate the form they are posting to. This actually sets the action attribute on the form, but specifying this attribute manually will not work because it continues to be ignored. Security issues regarding the ViewState are not relevant; the post will instruct the receiving page to ignore it. The previous page can be accessed with the new page property PreviousPage . Posting to Another PageLet's consider two pagesPage1 ( Page1.aspx ) needs to post to Page2 ( Page2.aspx ). Page1 could look like the code shown in Listing 9.1. Listing 9.1 Posting to Another Page<form runat="server"> This is the first page <p /> Please select a country: <asp:DropDownList id="Country" runat="server"> <asp:ListItem text="USA" value="0" /> <asp:ListItem text="Canada" value="1" /> <asp:ListItem text="UK" value="2" /> </asp:DropDownList> <p /> <asp:Button id="Button1" Text="This button just posts back to itself" onClick="btn_click" runat="server" /> <br /> <asp:Button id="Button2" Text="This button posts to another page" PostTargetUrl="Page2.aspx" runat="server" /> </form> The important section is that containing Button2 , where you see the PostTargetUrl attribute, which is set to the page being posted to. When the button is clicked, instead of posting back to the same page, the postback is redirected to the requested page, which can then access controls from Page1. However, controls on a page are protected, so they either have to be exposed on the previous page as a Public Property or accessed via FindControl . For example, we could add the following to Page1 to expose the list of countries : Public ReadOnly Property SelectedCountry() As DropDownList Get Return Country End Get End Property The exposed control doesn't have to be ReadOnly , but it works well for this example. Accessing the Previous PageOnce the postback has been completed, you are now in the second page, and with the addition of the PreviousPage property, Page2.aspx now has the capability to access content from Page1.aspx . However, by default, PreviousPage is not strongly typed and will therefore be of type Page . To strongly type the page, use the PreviousPage directive: <%@ PreviousPage VirtualPath="page_name.aspx" %> or <%@ PreviousPage TypeName="type" %> Only one of the attributes can be used at a time. Now the exposed controls can be accessed easily. For example, consider Page2 (see Listing 9.2). Listing 9.2 Using a Strongly Typed Page<%@ Page Language="VB" %> <%@ PreviousPage VirtualPath="Page1.aspx" %> <script runat="server"> Public Sub Page_Load() PrevMessage.Text = "On the previous page you selected: " & _ PreviousPage.SelectedCountry.SelectedItem.Text End Sub </script> <form runat="server"> This is the second page <p /> <asp:Label id="PrevMessage" runat="server" /> </form> Here you can see that the PreviousPage directive indicates that Page1.aspx is the previous pagethis ensures that the PreviousPage property will be strongly typed. From Page1.aspx the DropDownList is exposed via the SelectedCountry property. You can have only one PreviousPage directive on a page, although this doesn't prevent multiple pages from cross-posting to a single page. However, setting the PreviousPage directive will mean that all pages will be strongly typed as the same type. Under these circumstances it's best to not use the PreviousPage directive and instead access late-bound controls. Transferring to Another Page in CodeTransferring execution to another page can also be achieved with Server .Transfer , and with ASP.NET 2.0 this has another overloaded method: Server.Transfer( IHttpHandler, preserveForm ) The parameters are:
Detecting Cross-Page PostingThe question that naturally arises out of the preceding code is what happens if Page2 is accessed directly, without having been posted to from Page1.aspx , or perhaps if it posts back to itself. As well as the PreviousPage property, there is an IsCrossPagePostBack property, which indicates whether or not a page is participating in a cross-page postback. This property is True only for Page1 during its second instantiation, when accessed via the PreviousPage property of Page2. The following lists show what properties are set under what circumstances.
Here you can see that the existing ASP.NET 1.0 behavior isn't changed. When a page posts back to itself, the IsPostBack property is True , and the new properties are False . When posting to another page, however, the new properties are set. The use of these properties allows you to detect at what stage in a postback you are. The Page Life CycleIt is important to understand the life cycle of the pages when posting across pages. The following list indicates what happens when Page1 posts to Page2, and in what order:
Understanding this life cycle ensures that you realize the implications of using cross-page posting. For example, posting from a page with a large amount of ViewState means the ViewState is stored and then reposted when the PreviousPage is accessed.  | ||||||||||||||||||||||||||||||||
