Banner Display Using the ASP.NET AdRotator Control

Classic ASP provided an AdRotator component that allowed developers to easily display banners, as described in a previous article. Now, with the advent of ASP.NET, there is still, as you might expect, an AdRotator component, but it's been seriously upgraded.

As with any banner display mechanism, you'd like to be able to show banners on your web pages without having to manually edit every web page that comprises your site. Additionally, you'd like to have a way to automatically rotate the banners, and even control how often some of the banners display. Ideally, all information about the banners to be displayed would be located in one central location for easy maintenance.

Using ASP.NET, this can easily be accomplished. ASP.NET is a technology supported by Microsoft's Internet Information Server (IIS), one of the most common web servers around.

ASP.NET is essentially a component-based technology, supported by server-side execution of code. What this means is that programmers include components, known as controls in ASP.NET, on their web pages mixed in with the HTML. The web server ensures that the code (generally VB.NET or C#) associated with a control is executed on the server, generating the content that will be displayed by the control. A control can display things like a line of text, a drop-down listbox populated with data from a database or even a fully functional mini-application.

AdRotator Control

One of the standard components provided by ASP.NET is the AdRotator control. This component will display a different banner each time a web page is displayed.

The AdRotator depends on a configuration file, referred to as a rotator schedule file, to specify the banners that will be displayed, as well as any other information that is required. In Classic ASP, the rotator schedule file had a simple text format; in ASP.NET, the rotator schedule file is an XML file.

XML Rotator Schedule File

For each banner, the AdRotator needs to know the following things:

• The location of the banner image.
• The destination to go to when the banner is clicked.
• The alternate text to be displayed if the user hovers their mouse over the banner.
• A "weight" that defines how often the banner should be displayed.
• An optional keyword, to support filtering of banners by keyword.

This information is recorded in an XML file known as a rotator schedule file. A sample file is shown in Listing 1.

This is a fairly simple file, considerably simpler than the AdRotator file provided by Classic ASP. The following XML elements clearly define the necessary information:

• ImageURL: The location of the banner image. Unlike Classic ASP, there's no need to specify the dimensions of the banner.

• NavigateUrl: The destination to go to when the banner is clicked.

• AlternateText: The alternate text to be displayed if the user hovers their mouse over the banner.

• Impressions: A "weight" that defines how often the banner should be displayed in relation to other banners.

• Keyword: An optional keyword, to support filtering of banners by keyword.

Note that XML files are case-sensitive. Using the improper case in the XML file is one of the simplest mistakes when using the AdRotator control.

The Impressions element provides a relative weight, which governs how often a banner will be shown in comparison to other banners in the file. In the example, the weight of the first banner is twice that of the second banner, so the first banner will be displayed twice as often.

Displaying a Banner Using the AdRotator

The code to display a banner is straightforward, as shown in Listing 2. Simply include the control on the web page, passing in the location of the schedule file.

The AdRotator control also supports filtering of banners based on the Keyword element defined in the XML file. See Listing 3 below for an example of how to do keyword filtering.

The AdRotator will only show the banner for the real estate agent, since that is the only Ad with its Keyword element set to "Real Estate".

With keyword filtering, the ASP.NET AdRotator is considerably more powerful than the AdRotator in Classic ASP. Previously, programmers often resorted to schemes where different categories of banners were defined in different schedule files. Keyword filtering eliminates this by providing a simple mechanism for identifying the banners that should be considered for display.

Extensibility

In ASP.NET, controls often offer hooks that allow programmers to extend the functionality of a control. Essentially, there are events that occur during the life cycle of a control; programmers can define code to be executed when certain events occur, thereby extending the capability of a control.

As an example, suppose you'd like to display a caption underneath each banner. To do this, first add a new Caption element to the XML file.

To use the new Caption element, some VB.NET code will be needed. We'll create a subroutine called "AdCreated." We'll also add the OnAdCreated parameter to the AdRotator control, and give it the name of the new subroutine. By doing this, we've basically told the AdRotator control to call the subroutine when the AdCreated event occurs. The Ad object will be passed into the subroutine as the "E" parameter, which can be interrogated to retrieve property values for the caption and the navigation URL. Those values can then be used to define the caption that will be displayed below the banner; as a bonus, the caption will be a link to the same destination as the banner.

Handling the Banner Redirection

In Classic ASP, the AdRotator actually redirected users to a "redirection web page." This web page would receive parameters including the URL of the destination and the name of the banner image (this last parameter was typically never used). The progammer then had to provide the code that would forward the user to the appropriate destination. Of course, the programmer could also do other things with the redirection page, such as record click-throughs in a database.

To summarize, in Classic ASP the AdRotator basically handled the display of banners, but everything else was up to the programmer. In ASP.NET, there is no longer a requirement for a redirection page. The programmer doesn't have to worry about forwarding users to the destination designated by a banner because the ASP.NET AdRotator now handles that.

But here again, the extensibility provided by the new and improved AdRotator control can benefit developers. One thing the new Ad Rotator control does not do is track click-throughs when users click on banners. So, how can the Ad Rotator be extended to track click-throughs?

It's actually a simple task, as illustrated in Listing 6.

The AdCreated subroutine is called when the Ad is created. The subroutine substitutes the URL of the redirection web page for the URL provided in the XML file, but appends the original destination to the URL as a parameter. When the banner is clicked, the user will be redirected to the redirect.aspx web page, which can record a click-through and then transparently forward the user to the expected destination.

This is, of course, similar to the classic ASP approach. The distinction is that the developer is not required to do this, as in Classic ASP. The ASP.NET AdRotator is extensible, so the developer retains the option of using this approach to meet specific requirements.

Conclusion

The ASP.NET AdRotator control provides an easy way to add rotating banners to a web site. It also represents a considerable improvement over the original AdRotator component provided in Classic ASP. In particular, enhancements such as using an XML file to define Ad properties, keyword filtering and extensibility make the AdRotator control a powerful tool for savvy developers.