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
<%@ 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.
