Programming Microsoft ASP.NET 4 - Dino Esposito [269]
return "redir.aspx";
else
return (String) o;
}
set { ViewState["RedirectPage"] = value; }
}
public new String NavigateUrl
{
get { return base.NavigateUrl; }
set
{
var url = "{0}?page={1}";
url = String.Format(url, RedirectPage, value);
base.NavigateUrl = url;
}
}
}
}
As you can see, the new control has a brand new property—RedirectPage—and overrides an existing property—NavigateUrl. RedirectPage indicates the URL of the intermediate page, where the user is temporarily redirected so that any custom tasks such as click-through tracking can be accomplished. Here’s an example of the code file of such a page:
public partial class Redir : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
// Capture the originally requested page
var url = String.Empty;
var o = Request["Page"];
if (o != null)
{
url = Server.UrlEncode((String) o);
if (String.IsNullOrEmpty(url)
return;
}
// Do something here, such as updating a counter
...
// Redirect the user to the originally requested page
Response.Redirect(url);
}
}
You are assuming that the custom HyperLink control calls the redirector page, passing a Page parameter on the query string set to the original URL. Of course, this trick is arbitrary and you can find any better workarounds if you want.
The navigation URL for a hyperlink is set through the NavigateUrl property. You need to ensure that whenever a new value is assigned to the NavigateUrl property (say, http://www.asp.net), it gets overridden by something like the following:
redir.aspx?page=http://www.asp.net
In this way, the user first reaches redir.aspx, where his action is tracked, and then he is directed to his final destination.
To override the setter (or the getter) of a control property, you need the property to be marked as virtual at some point in the control’s inheritance chain. The HyperLink control has a virtual property—Text—and a couple of public, but not virtual, properties such as Target and NavigateUrl. If the property is not marked as virtual (namely, it is overridable), you can’t override it; however, you can replace its implementation altogether. You do this through the new modifier in C# and the Shadows modifier in Microsoft Visual Basic .NET:
public new string NavigateUrl
{
get { return base.NavigateUrl; }
set
{
var url = "{0}?page={1}";
url = String.Format(url, RedirectPage, value);
base.NavigateUrl = url;
}
}
The new modifier applied to a property instructs the compiler that the current implementation for the member replaces any other implementation available on base classes. If you redefine the NavigateUrl property without using the new keyword, you simply receive a warning from the compiler. The warning informs you that you are hiding an existing member, and it just recommends the use of the new modifier if hiding the member was intentional.
Building Controls from Scratch
There are two main situations in which ASP.NET developers feel the need to create custom controls. At times, developers need a control that simply doesn’t exist in the ASP.NET builtin toolbox. And occasionally, developers need a control that is similar to one of the native controls but not close enough to justify using one. In this case, developers typically derive a new control from an existing one and add or override members as appropriate. Let’s discuss techniques and tricks to design and code completely new ASP.NET controls that address functionalities that ASP.NET doesn’t provide out of the box.
Base Class and Interfaces
Several programming aspects support the development of a custom control in ASP.NET. First, there are base classes such as Control and WebControl. Each class provides a common set of base properties that address and fit into a particular use case. In addition to base classes, interfaces help you to better characterize the behavior and programming model of the control. A few interfaces are worth mentioning. They are INamingContainer, IPostBackDataHandler, and IPostBackEventHandler.
In Table 12-1, you see listed