AspAlliance.com LogoASPAlliance: Articles, reviews, and samples for .NET Developers
URL:
http://aspalliance.com/articleViewer.aspx?aId=1440&pId=-1
Cross-Page Postbacks Made Easy with .NET 2.0
page
by Shaun Eutsey
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 30896/ 65

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.


Product Spotlight
Product Spotlight 

©Copyright 1998-2019 ASPAlliance.com  |  Page Processed at 2019-09-17 10:48:49 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search