ASP.NET 2.0 introduces the ability to have an ASPX page postback to a different ASPX page with cross page postbacks. This was done all the time in ASP but wasn't supported in ASP.NET 1.x. This wasn't directly supported because on the server you need the same page to be recreated upon postback so the same controls could be repopulated with the post data. Since the model is to work at a higher level with server side controls and their properties, posting back to a different page would force you to access Request.Form to fetch the data a user had entered, which is a lower level than the control model wants.
So, in v2.0 they came up with a way to support cross page postbacks. This is enabled by a button on the first page setting PostBackUrl property to the page that will handle the postback. Once in the second page you can access the controls from the previous page by accessing the Page.PreviousPage property. Here's a sample that's like most of the documentation I've seen:
// Page1.aspx
<form id="form1" runat="server">
<asp:TextBox runat="server" ID="_tb1"></asp:TextBox>
+
<asp:TextBox runat="server" ID="_tb2"></asp:TextBox>
<asp:Button runat="server" ID="_button"
PostBackUrl="~/Page2.aspx" Text=" = " />
</form>
// Page2.aspx
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
TextBox tb1 = (TextBox)PreviousPage.FindControl("_tb1");
TextBox tb2 = (TextBox)PreviousPage.FindControl("_tb2");
int sum = Int32.Parse(tb1.Text) + Int32.Parse(tb2.Text);
_result.Text = sum.ToString();
}
</script>
<form id="form1" runat="server">
Answer is: <asp:Label runat="server" ID="_result"></asp:Label>
</form>
I find this to be entirely too tedious primarily because this approach still loses out of the declarative server side object model. The second page has to re-declare the same controls as local variables to access the properties. I don't think it will be how people write their second page to handle the postback. Instead the more useful approach will be to use the <%@ PreviousPageType %> directive in the second page:
// Page1.aspx
<script runat="server">
public int Sum
{
get
{
return Int32.Parse(_tb1.Text) + Int32.Parse(_tb2.Text);
}
}
</script>
<form id="form1" runat="server">
<asp:TextBox runat="server" ID="_tb1"></asp:TextBox>
+
<asp:TextBox runat="server" ID="_tb2"></asp:TextBox>
<asp:Button runat="server" ID="_button"
PostBackUrl="~/Page2.aspx" Text=" = " />
</form>
// Page2.aspx
<%@ PreviousPageType VirtualPath="~/Page1.aspx" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
_result.Text = PreviousPage.Sum.ToString();
}
</script>
<form id="form1" runat="server">
Answer is: <asp:Label runat="server" ID="_result"></asp:Label>
</form>
The first page utilizes the posted data via the declarative controls and it provides the necessary information to the second page a public property. Now this is much better since we now get to reuse the declarative controls. I really think this will be the preferred style of using cross page postbacks in ASP.NET 2.0.
One very interesting thing I've noticed about cross page postbacks is the life cycle of the first page when posting back to the second. The first time the second page accesses Page.PreviousPage ASP.NET needs to make a page object available. So it, in essence, creates the Page.PreviousPage object and calls ProcessChildRequest , which is similar to ProcessRequest except it stops processing prior to PreRender and a fake Response object is created so that no Write s are emitted. This has some interesting side effects, one of which is that all of the server side events of the first page fire. This includes Page_Init , Page_Loadand any control events like Button.Click events (if the Button has an OnClick event declared). This blew me away and it's certainly something to keep in mind when using cross page postbacks. One way to detect if your page is being accessed as a PreviousPage is to check Page.IsCrossPagePostBack .
One last thing to note about cross page postbacks is that using tracing is a PITA, since the PreviousPage's Trace messages end up mixed with the current page's Trace messages. I submitted a request to the product feeback center to see what they could do about it.
This was originally published on Brock Allen's Blog here
Brock Allen is an instructor for DevelopMentor where he teaches .NET and ASP.NET. He also manages the ASP.NET curriculum at DevelopMentor by doing research and course development. When not teaching...
Comments