Cross-Page PostBack - Features and Limitations

This blog is an addendum to the previous article posted by Hammad. I want to share some other features and limitations of this technique.

Strongly Typed PreviousPage property

While casting the PreviousPage property to the “default2.aspx” page, there is always a chance of an invalid cast, this can be eliminated by using the PreviousPageType directive in the destination page i.e. Default2.aspx. This directive will allow us to use a strongly typed PreviousPage property as it defines the url of the page in the VirtualPath attribute.

<%@ PreviousPageType VirtualPath="~/Default.aspx" %>

The properties and controls from the source page can now be accessed using the PrevioousPage property without the need of typecasting as shown in the following excerpt from Default2.aspx Page_load event.


if (this.PreviousPage != null && this.PreviousPage.IsCrossPagePostBack)
{

this.txtDetails.Text = "This is a cross Page Post Back and the source page is "+ this.PreviousPage.ID;

this.txtDetails.Text += "Variables available at previous page: Comments = " +
this.PreviousPage.Comments;

this.txtDetails.Text += "Value = " +
this.PreviousPage.Value;

}


PostBackUrl and Button.Click Handlers

Starting from .NET 2.0, there is an IButtonControl Interface and the controls (button, linkButton and ImageButton) including custom controls that implement this interface can be used as a button.
In addition, we can set the PostBackUrl property for controls of this type as:
ID=”PostPage” runat = “server”
PostBackUrl=”~/default2.aspx”
Text=”Post Page” />
By doing this, you don’t even need to handle the Click event of the button.

_PREVIOUSPAGE

When the page contains a control that does cross-page posting, a new hidden field named __PREVIOUSPAGE is created.


Limitations of Cross-Page PostBack

Further, there are also some limitations of using the Cross-Page Postback technique in .Net 2.0.

Access to Query Strings:

Suppose there is some logic in the source page “Default.aspx” for building itself using the query string. Now the page is posted to “Default2.aspx”. If we now access Default.aspx through the PreviousPage property, and use the PreviousPage.Request.QueryString property, it gives you the current page’s query string rather than the query string of Default.aspx (the original page).
i.e. in Default2.aspx
this.PreviousPage.Request.QueryString = =this.Request.QueryString

Server Side Validation

The other problem is with server side validation i.e. when you need to perform some server side validation for the input that the user performs on Default.aspx. In “default2.aspx” code, you can check for the Page.IsValid property but what if the validation fails. There is no way to post the user back to the original page with the original data in tact and show the failure message in case the validation fails.