Cross-Page Postbacks Made Easy with .NET 2.0
page 2 of 3
by Shaun Eutsey
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 27745/ 29

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.


View Entire Article

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-2024 ASPAlliance.com  |  Page Processed at 2024-03-29 7:53:00 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search