Page and User Control Communication
 
Published: 14 Nov 2007
Abstract
This article shows how the page and user controls within the page can communicate together with a little more work. It shows how the use of interfaces or custom page classes can make the application more efficient and reduce code.
by Brian Mains
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 37803/ 84

Introduction

In .NET 1.1, the method for deployment was to build a web site, which compiled all of the ASP.NET code into a single assembly, which was deployed with the application. The benefit to this was that the application could program against the various page class models because each page was in the same assembly, the pages "knew" of each other. This is also the case in .NET 2.0, with the web application project template that can be downloaded and registered in Visual Studio.

However, native .NET 2.0 web sites do not work that way. Each page is dynamically compiled (or precompilation is an option). Because of that, each page does not know about the other because it does not exist in the same assembly. But there are ways to communicate between pages and user controls, which we shall examine in this article.

Custom Page Classes

Custom page classes involve creating a class that inherits from System.Web.UI.Page. For instance, the class below is a custom page class.

Listing 1

public class MyCustomPageClass : System.Web.UI.Page 
{ 
}

MyCustomPageClass is a custom page class in this case because it inherits from Page. The benefit to this is that it can provide added features to all of the pages that inherit from it. There are other benefits as well, as described in this article. One of the benefits that this article will discuss is the ability to have pages and user controls communicate with each other. The problem with the web site model is that the code-behind page is dynamically compiled in the assembly and is cut off from user controls that it may use.

The custom class can exist in the App_Code and can work uncompiled, be in a separate class project, or precompiled in the bin folder, using the publish web site option.

User Control Communication

Oftentimes, user controls mark regions or specific areas in a page. The reason to do this is to reduce the amount of code involved; instead of two pages duplicating the same code, the application can use user controls to move the interface markup into a single area. However, often user controls have to talk with other user controls in the page, or the page needs to work with user controls. This poses a dilemma; how does that happen in the dynamically compiled model?

The key is using one of two approaches: interfaces, or custom user control classes. Let us look at the first option. Defining an interface for the user control can make it easier to work with the control. Let us look at an interface.

Listing 2

public interface IUserInfoControl
{
  string FirstName
  {
    get;
  }
  string LastName
  {
    get;
  }
  string AddressLines
  {
    get;
  }
  string City
  {
    get;
  }
  string State
  {
    get;
  }
  string ZipCode
  {
    get;
  }
}

This interface, when defined within a user control, exposes the data that it holds. Alternatively, it could have exposed direct references to the controls, if preferred. Either could work, but I like having a more abstract interface, and by not exposing the controls directly, helps create a more maintainable solution (if the controls that represent the user control change, this interface does not have to).

So an ASP.NET User Controls code-behind can define this interface as such:

Listing 3

public class MyUserControl: UserControl, IUserInfoControl
{
  public string FirstName
  {
    get
    {
      return txtFirstName.Text;
    }
  }
 
  public string LastName
  {
    get
    {
      return txtLastName.Text;
    }
  }
  . .
}

Note that setters could have been included as well, which is useful especially if data is loaded from a database, XML, or some other source. So the page that hosts this can make use of the user control. But the page could have done that anyway, since it has a direct reference to the control. So where is the benefit?

The benefit lies if you need to leverage any coding in a custom page class, such as making the page the sole driver for all the interactions. This custom page class can make references to the user interface and work with it as such. The custom page class approach is great if you have a common user control used throughout the application, or if you have two pages that have mostly the same code, but work slightly differently (such as an add and edit page).

The custom page class can work with the interface in an abstract manner, by exposing an abstract property that the ASP.NET code-behind file will implement.

Listing 4

public class UserRegistrationPage : Page
{
  public abstract IUserInfoControl UserInfo { get; }
}

The ASP.NET code-behind file overrides the property and returns an instance of the control that exists in the page. This is necessary because the custom page class knows nothing about the actual implementation, and by not doing it this way, the custom page class knows nothing about the User Info control.

Listing 5

public class ASPXRegistrationPage : UserRegistrationPage
{
  public override IUserInfoControl UserInfo
  {
    get { return this.wucUserInfoControl; }
  }
}

The custom page class can then work with the user info control data in any way that it desires.  For instance, it could define code to work with the data below:

Listing 6

public class UserRegistrationPage: Page
{
  public void GetUserInfo()
  {
    UsersTableAdapter adapter = new UsersTableAdapters.UsersTableAdapter();
    UsersTable table = adapter.GetUserInfo(User.Identity.Name);
    if (table != null && table.Rows.Count > 0)
    {
      UsersRow row = (UsersRow)table.Rows[0];
      this.UserInfo.FirstName = row.FirstName;
      this.UserInfo.LastName = row.LastName;
      . .
    }
  }
  public void SaveUserInfo()
  {
    UsersTableAdapter adapter = new UsersTableAdapters.UsersTableAdapter();
    UsersTable table = new UsersTable();
    UsersRow row = table.NewUsersRow();
 
    row.FirstName = this.UserInfo.FirstName;
    row.LastName = this.UserInfo.LastName;
    . .
  }
}

In this way, the custom page class can work with the user control's information in a way that is useful to it.

Practicality

This situation is not practical for every situation. Rather, you may implement it for a small set of features, such as exposing certain properties reused throughout the application, exposing a user control that contains a header or other important information.

However, there may be times when you need to implement something similar to this because of a required duplication, and therefore may be a requirement. Especially when a user control needs to access certain page properties that may be constant throughout the application, a custom page class is useful. This is because a user control cannot convert its Page property to the rightful type of the code-behind page (especially when a user control is used in many pages), but it can convert it to the type of the custom page class.

Custom Libraries

If your application has a custom library compiled as a DLL, all of this code can be embedded here, and a reference added in the web application. Alternatively, rather than creating an interface for the user control, a custom user control class can be created by defining a class that inherits from System.Web.UI.UserControl.

Web Application Project

With the web application project add-on, all of the pages are compiled into a single assembly, as in the .NET 1.x days. This means that all of the files are compiled to the same assembly, and that the code-behind files can be programmed against. What I mean is the ASP.NET page's class can be potentially used within a user control because the user control and page are not dynamically compiled.

In this model, a custom page class would not need defined in the App_Code folder because all of the code-behind files can be programmed against, making less work than the approach above.  Though, it would be wise to research the differences with Web Application Project applications to ensure it is the right model for you.

Conclusion

Though there are other ways to do it, in an application, this may be an approach you have to take depending on the circumstances of the application, meaning that it is useful to understand how ASP.NET pages can work with a custom page class, especially when communicating with inner user controls.



User Comments

Title: a   
Name: a
Date: 2012-11-28 8:21:44 AM
Comment:
a
Title: Use events   
Name: Sowokie
Date: 2008-07-14 7:39:34 AM
Comment:
At my work we implemented a event system that makes you able to register an event(in one control) and listen for that event (in another control). This way you can also send over objects and use them. And you never have to involve the page. You just drop the controls on what page you like and they know how to talk to each other.

When this has been set up once, using it is extreamly easy. This is something i would like to have by default in the framework..

As a rule we try to use this sparingly but we have never had any speed/memory problems at all with this approach!
Title: Great that approves my way   
Name: Muhammad Mosa
Date: 2008-07-11 12:02:07 PM
Comment:
Great Brain, that actually confirm my way I'm currently using.
I faced the issue that I needed 2 user controls to be able to communicate with each others through the Page. And the way you present here is also good for such cases.
Cheers
Title: Nice Article!   
Name: Ehsan
Date: 2008-07-11 11:05:18 AM
Comment:
This article just opened my eyes up to a lot of possibilities.

Product Spotlight
Product Spotlight 





Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2019 ASPAlliance.com  |  Page Processed at 2019-09-20 9:11:22 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search