Page and User Control Communication
page 3 of 7
by Brian Mains
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 37855/ 106

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.


View Entire Article

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-15 6:39:45 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search