Calling A Page Using ShowPage vs. Response.Redirect

Calling A Page Using ShowPage vs. Response.Redirect

Mark Wagner
May 21, 2004

Applies to

  • Response.Redirect
  • Calling a page
  • State Management

Summary

This article shows how you can call a page using strongly typed parameters just as you would call any common method.

Contents

  • Introduction
  • Response.Redirect
  • Creating Page Parameters
  • Using ShowPage and PageUrl

Introduction

The typical technique used to call a page is using the Response.Redirect method.  This often involves passing relative data in the form of a query string.  The query string is just as it implies, a string of data.  Additionally, the query string is a very unsecure method often requiring the query string to be encrypted.

Another technique is to provide a method on each page called ShowPage.  The ShowPage method provides a number of benefits.  This article will cover how simple you can accomplish this.

  • Strongly typed parameters.
  • Exposure of required parameters via the interface
  • Encapsulated parameter state management
  • Improved security (no query string visibility)
  • Page mobility within the web application

Response.Redirect

Below is an example of using the Response.Redirect method.  This looks very simple, and it is for the most part.

Example
string query = "?id=" + someVariable;
Response.Redirect("~/FolderX/PageX.aspx" + query);

Although this method works perfectly well, it can pose a security risk under certain circumstances.  As a rule, the query string should be used with the understanding that the data can be modified by the user.  The query string should always be considered as user input and therefore it should always be subject to the same validation requirements as user input is.  Page parameters address this.

The query string does not support strongly typed values.  Just to be fair, its a good thing the query string doesn’t require strongly typed values, and it is definitely worth having at times.  However, there are several times when the use of strongly typed variables is useful.  Using the query string also forces us to convert all values to a string before calling the page.  Additionally, we must to convert these string values obtained from the query string back to their native data types on the called page.  This requires the developer to research any required parameters, usually by opening the source code for that page and inspecting the page’s Page_Load method or page documentation.  Page parameters provide for strongly typed values as well as exposure via the page’s class interface.

The session object is another mechanism for managing state between page calls.  This also works well, but it requires the calling page to know the name of the session variable(s) to use in storing the value(s).  Page parameters resolve this using encapsulation.

With most web projects the pages are not moved around all that often once they are created.  However, there are times when they do need to be moved.  Page parameters addresses this by encapsulating the page url in a central location and removes the need to hard-code or duplicate this information in other pages.

Creating Page Parameters

Using page parameters involves creating one static property and one static method.  These new methods should be static for optimal performance and ease of use for the developer.  As we know, static methods are available as part of the class definition and do not require the page class to be instantiated.

PageUrl property

The first property we create is the PageUrl property.  This encapsulates the url used to call this page.  The string containing the url should be relative to the root of the application.  Using the HttpContext.Current.Request.ApplicationPath ensures we return the url relative to the web applications root folder.  Additionally, exposing this url as a public method allows the url to be available for use when needed in situations such as for a menu link, hyperlink, or any other url related need.  The following is an example of the PageUrl property to add to you page.

Example
public static string PageUrl
{
  get
  {
    return HttpContext.Current.Request.ApplicationPath + "/FolderX/PageX.aspx";
  }
}

ShowPage Method

The second method needed is the ShowPage method.  This facilitates the need to call (redirect to) this page.  When calling a page it is often necessary to pass data to that page.  This is often done using the query string, session state, or some other mechanism.  Again, although these methods work fine, there are several drawbacks to these methods as discussed above in the Response.Redirect section.

In the example below we allow the user to pass objects such as a dataset to the page.  The calling page does not need to be concerned with how the required page parameters are managed.

Example
public static void ShowPage(int selectedItemPK, DataSet largeDataSet)
{
 SessionState("PageX.SelectedPK") = selectedItemPK; 
 SessionState("PageX.DataSet") = largeDataSet;
 HttpContext.Current.Response.Redirect(PageX.PageUrl);
}

Additionally, you can overload the ShowPage method to expose the acceptable combination of parameters when calling this page.

Example
public static void ShowPage(DataSet largeDataSet)
{
 ShowPage(DataSet largeDataSet);
}

public static void ShowPage()
{
 ShowPage((DataSet) null);
}

Using ShowPage and PageUrl

Having implemented these two simple methods in our page we have reduced the development time for any developer needing to call our page.  The developer simply uses the page class name to access either the ShowPage mothod or the PageUrl property.  As you will see below, using these methods is very simple.

Using the PageUrl property

Obtaining the url used to call a page is easily retrieved at run-time via the PageUrl property.  Again, this is retrieved at run-time and not hard-coded as is usually done.  In this example we are assigning the page url to a menu object.

Example
menuItem.TargetUrl = PageX.PageUrl;

Using the ShowPage method

Using the ShowPage method becomes very easy for any developer needing to call your page.  The available and required parameters are easily visible to the developer at design time via Intellisense.  Additionally, the expected data type for each parameter is easily accessible and visible to the developer.

Example
PageX.ShowPage(newDataSet);

As you can see, providing a strongly typed interface to call your page is very simple and only requires a few lines of code.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s