Cross-Page Postbacks Made Easy with .NET 2.0
 
Published: 26 Oct 2007
Abstract
This article provides a brief walk through and explanation of the cross-page post back functionality that has been added back into the .NET Framework.
by Shaun Eutsey
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 31086/ 70

Introduction

New technology is wonderful. I love going into things and looking at the nuts and bolts and figuring out how things work. This has led my wife to many hours of despair as I have tried to "fix" things that were not working too well. One thing was guaranteed, after it has been "fixed," it would be heading to the garbage truck the next week. But I digress. Sometimes new technology forgets things that worked with older versions, leaving common and necessary functions behind in the rush to get things to market.

One of the things that ASP.NET 1.0 and 1.1 forgot from classic ASP was the ability to perform cross-page postbacks. Sure, we could still do a Server.Transfer or a Response.Redirect, but these methods leave a lot to be desired. Security for one is a nightmare; things can get ugly quick if you have malicious end users intent on destruction.

Thankfully, with .NET 2.0, Microsoft has brought back something that I have dearly missed.  Not only have they brought it back, they have made it so much better that it makes my head spin. Even more than that, I have found that not too many people are using them. Most developers I have talked to do not even know that they can use it. They are still using Server.Transfer or Response.Redirect. 

If this is you, my dear reader, there is a light at the end of the tunnel. You have stumbled on a gold nugget that will make your development richer than you can imagine (OK, maybe that last statement is a little presumptuous.)

The Solution

For the sake of this article I will keep my examples very basic. The pages that we will create will take a small form and submit it to another form and display the information in the other form.  Traditionally, I have used this technique to run Local SQL Server Reporting Service Reports. The base form was to gather report criteria, then post that back to the page that displayed the report.

I am only going to give you the areas of the HTML that you will need.  I am not going to write out the whole pages.

The Posting Page

For the posting page we will create a small form. Let us say that it is a message editor. We want to edit a message that the end users will see and then display a confirmation on another page.  For simplicities sake we will use need a Message ID, a Subject, a Message and of a way to Submit the form.

Listing 1 - Page1.aspx

<asp:TextBox ID="tMessageID" runat="server" />
<asp:TextBox ID="tSubject" runat="server" />
<asp:TextBox ID="tMessage" runat="server" TextMode="MultiLine" 
      width="300px" height="80px" />
<asp:Button ID="bSubmit" runat="server" Text="Submit" PostBackUrl="~/Page2.aspx" />

Notice that on the submit button there is a PostBackUrl property that has been set. This property changes the destination of the postback when that control is clicked. If there are other buttons or controls on the page that do auto postbacks or do not have this property set, then they will postback to the current page, something that ASP Classic would not do easily.

Now there is a little code needed behind the scenes on this page that is needed to make the form controls available to Page2.aspx. We need to set public read only properties that return the values from the form fields.

The Code in VB.NET

Listing 2 - Page1.aspx.vb

Public ReadOnly Property MessageID As Int32
   Get
      Return CInt(tMessageID.Text)
   End Get
End Property
 
Public ReadOnly Property Subject As String
    Get
      Return tSubject.Text
    End Get
End Property
 
Public ReadOnly Property Message As String
    Get
      Return tMessage.Text
    End Get
End Property

The Code in C#

Listing 3 - Page1.aspx.cs

Public Int32 MessageID
{
   Get
   {
      Return Int32.Parse(tMessageID.Text);
   }
}
 
Public String Subject
{
    Get
    {
      Return tSubject.Text;
    }
}
 
Public String Message
{
    Get
    {
      Return tMessage.Text;
    }
}

The Receiving Page

Now that we have the page that will be doing the posting created, we can move on to the page that will be receiving the post. We will call this one Page2.aspx (as referenced in the PostBackUrl in the submit button above).

The first thing that we need to do in the receiving page is create a reference to the posting page.  This is the only limitation to this method that I am not thrilled about, but it is passable. The reason I am not thrilled is that you have to know the page that is posting to this page; you will get errors otherwise. So in a full and robust application some situational coding will need to be done. I am not going to put that in here, as it does not directly affect the working of Cross-Page Postbacks.

Page2.aspx

The directive:
<%@ PreviousPageType VirtualPath="~/Page1.aspx" />

Now comes the part that I absolutely love about this method, referencing the properties of Page1.aspx from Page2.aspx.

Page2.aspx.vb

Response.Write("Message ID: " & PreviousPage.MessageID & vbNewLine)
Response.Write("Subject: " & PreviousPage.Subject & vbNewLine)
Response.Write("Message: " & PreviousPage.Message & vbNewLine)

Page2.aspx.cs

Response.Write("Message ID: " + PreviousPage.MessageID + "\n");
Response.Write("Subject: " + PreviousPage.Subject + "\n");
Response.Write("Message: " + PreviousPage.Message + "\n");

You probably noticed the PreviousPage.PropertyName. This is the ingenious part of the whole process. You do not have to grab information in the Request or blindly reference a cookie or session. You have the strongly typed PreviousPage reference to guide you. Like I said, the new Cross-Page postbacks are Ingenious.

The simplicity and the brilliance of the PreviousPageType directive is that not only can you reference the previous page, but the properties are strongly typed. You can now reference the parameters without exposing them in a query string or hogging resources with cookies and session variables.

The advantages of using cross-page postbacks vastly outweigh the disadvantages, in security alone. You cannot hack a cookie that does not exist.  You cannot edit a query string that is not there. You can use this across server farms, as there is no session to contend with.

Conclusion

I think that Cross Page Postbacks have been largely forgotten about because of the other advantage that .NET has brought. The ease of using one page to do all of the work has made the need for doing a cross-page postback more rare than it was "back in the day." However, the next time you find yourself type Server.Transfer or Response.Redirect, look a little deeper at that you are doing, and ask yourself if a cross-page postback would serve your needs better.



User Comments

Title: Good piece   
Name: Vino
Date: 2008-09-26 10:19:14 AM
Comment:
Really a good piece of article in a simplest way possible. Good Effort. Keep up the good work.
Title: Re: Limitation(s)   
Name: Florin Labou
Date: 2007-11-09 8:16:02 AM
Comment:
When you need to postback from more pages to Page2.aspx you'll need to define a 'contract' that describes the list of expected transferred values to Page2.aspx.

When Page1.aspx and Page3.aspx need to postback to Page2.aspx you may create a base page:
public abstract class SourceBasePage : System.Web.UI.Page
{
public abstract Int32 MessageID { get; }
public abstract String Subject { get; }
public abstract String Message { get; }
}
Page1.aspx and Page3.aspx should inherit from this SourceBasePage. Page2.aspx should describe the previous page type by TypeName:
<%@ PreviousPageType TypeName="MyNamespace.SourceBasePage" %>

So one solution is inheritance.

I hope this will help.

Regards,
Florin Labou
Title: nice article   
Name: Sandeep
Date: 2007-11-09 6:34:02 AM
Comment:
Really good information presented in simple to understand manner!
Title: Limitation ?   
Name: Abdul wahab
Date: 2007-11-05 1:53:58 AM
Comment:
thats a nice article written
my question is : what if my page 2 expect input from two different pages in that case how will previous page will work
Title: Limitations   
Name: Pawan Bansal
Date: 2007-10-31 1:37:03 AM
Comment:
Hi Shaun!

thanks for writing this article. but the whole concept still has limitations that restricts the use of this concept. You should have a one way channel of the forms to be called like here Page1 is calling Page2. what if the Page2 needs to opened from many other pages as well. Like doing some common functionality from various pages and passi ng the query filter from each page. This will not help in that scenario. Moreover if in any case Page2 calls back Page1 then also it is going to fail.

I think the concept still needs a lot more to be done for a real time useful utility.
Title: Awesome!!   
Name: Nishanth Nair
Date: 2007-10-31 12:51:11 AM
Comment:
Very good article. Written in plain simple english. Was very useful.
Title: It's Works fine!   
Name: Azad
Date: 2007-10-31 12:22:59 AM
Comment:
Thanks for your nice article .Its really good .
Title: Very Nice!!   
Name: siva
Date: 2007-10-31 12:08:43 AM
Comment:
Very Nice Article !!!!!!
Title: Newbie Learning   
Name: Barney3012
Date: 2007-10-29 7:30:04 AM
Comment:
As a newbie things like this are really useful. I have used the old redirect a few times and as a new person you do not often see ways of doing the basics like moving values from page to page. This is a very useful article.
Thanks for taking the time

Product Spotlight
Product Spotlight 





Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2019 ASPAlliance.com  |  Page Processed at 2019-08-23 2:00:00 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search