Server Controls Improved - 30 Oct 2009

What’s New in the Building Blocks of ASP.NET 2.0 Applications

CoreCoder

LANGUAGES: C# | VB.NET

ASP.NET VERSIONS: 2.0

 

Server Controls Improved

What s New in the Building Blocks of ASP.NET 2.0 Applications

 

By Dino Esposito

 

Server controls are the building blocks of any ASP.NET application. Any change to a control s architecture may have ramifications on the whole application which can be both good and bad. New features added to a base class can benefit a slew of top-level controls; changes in the internal behavior of a base control can affect the programming style of other controls. In worse cases scenarios but thankfully not in ASP.NET changes to building blocks like this can also break applications. For this reason, it s important to take a look at the structure of ASP.NET 2.0 server controls to see what s new and what has changed.

 

In the transition from ASP.NET 1.1 to ASP.NET 2.0, server controls gained some new programming features, such as themes, browser-specific rendering, and support for input focus. This is the tip of the iceberg, though. Below water, in fact, and invisible at the page-authoring level, you ll find a number of other improvements with a more architectural connotation, including XHTML 1.1 conformance, adaptive rendering, and control state. Let s take a look at each of them, one at a time.

 

XHTML Compliance

XHTML is a World Wide Web Consortium (W3C) standard that admits Web pages only if tagged as well-formed XML documents. This approach guarantees that the elements in the pages of a Web application are more forward-compatible with browsers in the near future and, more importantly, should be able to work in the same way regardless of the browser. It is common today to have quite forgiving browsers to guess and replace a missing tag, while others, more rigorously, don t render the page if there s something wrong or missing. This is the historical heritage of HTML, designed to be simple, but de facto made even simpler by certain browsers one name, Internet Explorer even though with the best intentions. So join me in heartily welcoming XHTML in ASP.NET 2.0.

 

ASP.NET 2.0 defaults to XHTML 1.1, but you can also opt for XHTML 1.0 Strict or Transitional. The rendering engine of some controls has been reworked to make them produce compliant output. As a result, in ASP.NET 2.0, each control s markup includes a closing tag. Furthermore, the viewstate hidden field comes surrounded by a

tag and the form is only identified by the ID attribute. XHTML, in fact, prohibits the use of the name attribute in the
tag:

 

  

   id="__VIEWSTATE" value="..." />

  :

 

Another point of XHTML weakness for ASP.NET 1.x pages are script tags. In ASP.NET 2.0, a script tag always includes the type attribute and is rendered inside a CDATA element.

 

For the most part, these changes won t affect migrated applications. There might be some exceptions, however. For example, think of a page that relies on the now ceased name attribute of the form. To turn off XHTML 1.1 compliance, add a new setting to the web.config file:

 

 

 

It forces ASP.NET 2.0 to render controls as in ASP.NET 1.x, ignoring the XHTML compliance directive. In this way, you allow yourself time to rework the various pages to XHTML while keeping the application working. You should not abuse this setting, though, as it might not be supported in future versions of ASP.NET.

 

It is essential to note that ASP.NET 2.0 guarantees the generation of XHTML-compliant output for the vast majority of core ASP.NET server controls, but not for all. HyperLink, BulletedList, and AdRotator controls are at risk because of their internal and required use of the target attribute. For example, the following markup fails W3C validation:

 

Click Here

 

In general, all controls and custom controls that incorporate a child hyperlink with the target attribute set automatically break the XHTML compliance of the host page. In some cases, GridView and TreeView might also not be XHTML 1.1-compliant. If you make use of third-party controls, check with the vendor to see what they say about XHTML.

 

ASP.NET is, per se, unable to fix static text in the page that breaks compliance. To help developers inserting XHTML-compliant HTML elements, Visual Studio.NET supports validation of XHTML markup for static elements, as shown in Figure 1.

 


Figure 1: Choosing the target validation schema for markup in Visual Studio.NET 2005.

 

While your management and marketing people welcome the XHTML support because it can open up new possibilities for ASP.NET applications, as a developer you might be concerned that XHTML 1.1 support ends up generating markup hard to digest for some browsers. Internet Explorer 6.0, for example, is not XHTML 1.1-compliant, but recognizes well XHTML 1.0 Transitional. The same holds true for Netscape 7.x and Opera 7.x. What will happen when an ASP.NET 2.0 page gets hit by one of these?

 

Internally, the adaptive rendering engine of ASP.NET 2.0 controls checks the browser s capabilities and generates markup that works around the browser s XHTML shortcomings. As a side note, consider that the markup of ASP.NET 2.0 controls is also fully compatible with Section 508 accessibility guidelines.

 

Adaptive Rendering

Adaptive rendering is the process that enables controls to generate different markup for individual browsers. This result is obtained by delegating the generation of the markup to an external component: the adapter. When each control is about to render, it figures out its current adapter and hands the request over to that adapter.

 

The adapter for a control is resolved by looking at the browser s capabilities as configured in the ASP.NET configuration folder. If the browser record includes an adapter class for that control, the class is instantiated and used. Otherwise, the adapter for the control is an instance of the base ControlAdapter class. The ControlAdapter class is a generic adapter and simply generates the markup for a control by calling the rendering methods on the control itself.

 

In ASP.NET 2.0, browser information is stored as a list of text files with a .browser extension. Text files are located under the ASP.NET installation folder on the Web server; following is the exact path:

 

%WINDOWS%\Microsoft.NET\Framework\[build]\CONFIG\Browsers

 

A control holds a reference to the mapped adapter instance through the Adapter property (a protected property). Each control has an associated adapter unless it is a composite control that defers to its children for rendering.

 

Browser-sensitive Rendering

In ASP.NET 2.0, control properties can take values that change according to the underlying browser. To do so, you use a special syntax that consists of a browser-specific prefix added to the property name:

 

    ie:Text="Hello from IE"

    mozilla:Text="Hello from Firefox" />

 

The Text property of the button will contain Hello from IE if the page is viewed through Internet Explorer and Hello from Firefox if the page gets hit with the Firefox browser (see Figure 2). If another browser is used, the value of the unprefixed Text attribute is used. All properties you can insert in a tag declaration can be flagged with a browser ID. Each supported browser has a unique ID. As in the preceding code, ie is for Internet Explorer and mozilla is for Firefox. Unique IDs exist for various versions of Netscape browsers and mobile devices. The most common prefixes are listed in Figure 3. Look at .browser files for more information on other devices or for guidance on how to register a new browser ID.

 


Figure 2: Browser-sensitive control rendering.

 

Browser ID

Browser Name

IE

Any version of Internet Explorer

Netscape3

Netscape Navigator 3.x

Netscape4

Netscape Communicator 4.x

Netscape6to9

Any version of Netscape higher than 6.0

Mozilla

Firefox

Opera

Opera

Up

Openwave-powered devices

Figure 3: ID of most common browsers.

 

Controls and Themes

In ASP.NET 2.0 jargon, a theme is a named collection of property settings that can be applied to controls to make them look consistent across pages. You can apply theme settings to an entire Web site, to a page and its controls, or to an individual control. A theme is identified by name and consists of cascading style sheet (CSS) files, images, and control skins. A control skin is a text file that contains predefined values for some control properties. Applied together, these settings contribute to change the look and feel of the control and give the whole site a consistent (and, you hope, appealing) user interface. In addition, because themes are a sort of monolithic attribute, you can easily export that look from one application to the next. With themes enabled, if the developer adds, say, a DataGrid control to a page, the control is rendered with the default appearance defined in the currently selected theme. For more on themes, see Author Once, Theme Always.

 

Server controls can dynamically accept or deny theming through a Boolean property named EnableTheming. The property is set to true by default. As a general rule, themes affect only properties that relate to the control s appearance. Properties that explicitly specify a behavior or imply an action should not be made themeable (and shouldn t be themed anyway). Each control has the power to state which properties are themeable and which are not. This happens at compile time through attributes; in particular, the Themeable attribute:

 

[Themeable(false)]

public string Text {

:

}

 

 

Public Property Text As String

:

End Property

 

Obviously, you can use the Themeable attribute only when writing a custom control. As for built-in controls, most of them have marked non-visual properties as not themeable. DataSource and DataSourceID are two examples.

 

Input Focus

A useful feature that ASP.NET 1.x lacks is the ability to quickly assign the input focus to a particular control when the page is displayed. This feature can be coded in no time by a seasoned developer and can be easily engineered into a company-wide framework for building controls and pages.

 

The Page class of ASP.NET 2.0 provides the SetFocus method to assign the input focus to any control you want. The following code shows how to set the focus to a TextBox control named TextBox1:

 

void Page_Load(object sender, EventArgs e)

{

 if (!IsPostBack)

     SetFocus("TextBox1");

}

 

 

Sub Page_Load(sender As Object sender, e As EventArgs)

 If Not IsPostBack Then

    SetFocus("TextBox1")

 End If

End Sub

 

The SetFocus method caches the ID of the control and forces the Page class to generate ad hoc script code when the page is rendered. Each control can also reclaim the input focus for itself by calling its new Focus method. All controls in the ASP.NET 2.0 framework benefit from this feature.

 

Control State

Some ASP.NET controls require that some state be kept across requests. Aside from server-side storages, such as session or cache, in ASP.NET 1.x, there is only one container in which this data can be stored: the viewstate. However, the viewstate is primarily designed to maintain settings set by the application, and, more importantly, it can be turned off at the application level for a particular control. What happens at this point depends on the type of information. If it can be reproduced, it will be reloaded and the page works as usual; otherwise, the information is lost and the page might fail.

 

For this reason, ASP.NET 2.0 introduces the notion of the control state and keeps it separate from the viewstate to make clear that control state is a vital piece of the control infrastructure. Control state is a collection of critical viewstate data that controls need to function. Because of its critical role, control state data is contained in separate member variables from normal viewstate and is not affected when viewstate is disabled. The control state is persisted in the same hidden field as the viewstate. Unlike the viewstate, though, it requires extra implementation steps to be persisted. I covered control state in Maintain State Control.

 

Conclusion

ASP.NET 1.x pages don t validate their output against any W3C standard neither HTML 4.01 nor XHTML 1.x. As a matter of fact, this prevented some companies from adopting ASP.NET and also created the perception that ASP.NET generates bad HTML. Whatever your position with regard to standards compliance, the entire community can welcome XHTML support in ASP.NET 2.0. This is perhaps the most important change in the control s infrastructure, but not the only one. Themes and adaptive rendering are two other important milestones on the way to delivering a fully functional and easy to use environment.

 

ASP.NET 2.0 is celebrated as a feature-rich and greatly enhanced platform for building powerful Web applications. Who could deny that? But changes and improvements this time begin at a lower level from the building blocks. Server controls in ASP.NET 2.0 are now a more powerful component.

 

Dino Esposito is a trainer and consultant who specializes in ASP.NET and ADO.NET. Author of Programming Microsoft ASP.NET and Introducing ASP.NET 2.0, both from Microsoft Press, Dino also helped several companies architect and build effective products for ASP.NET developers. Dino is the cofounder of http://www.DotNet2TheMax.com, a popular portal for .NET programmers. Write to him at mailto:[email protected] or join the blog at http://weblogs.asp.net/despos.

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish