ASP.NET 2.0 (II) New Controls...

In the last article we looked at the enhancements to existing controls. In this article we'll proceed to provide an overview of the new controls that have been introduced...

By: Chris Sully Date: January 22, 2006 Printer Friendly Version

Introduction

This article is the second in a series looking at ASP.NET 2.0 though it follows on from my earlier overview articles on the subject. In the last article we looked at the enhancements to existing controls. In this article we’ll proceed to provide an overview of the new controls that have been introduced.

Note that the information presented is based on the Beta product so minor changes may have been introduced in the final product release.

The unified control and adapter architecture

The first concept to get one's head round is the fact that the core controls no longer just produce HTML. This is to extend the power of these core controls to not just cater for standard web browsers on traditional computers but also for mobile devices using different markup languages. Historically such support has been segregated, most recently in version 1.1 as the ASP.NET mobile controls. In .NET 2.0 Microsoft introduce a new architecture to make life easier for developers and bring in this increased support into the core control set.

The ASP.NET mobile controls and its forerunner the Microsoft Mobile Internet Toolkit went a long way towards solving the issue of sending the right output to the all the possible clients that could request content. It did this by providing support for a large number of popular devices. The MMIT uses device adapters to generate the output with one per markup language. All of the controls can use these device adapters to generate output suitable for a particular device. The device adapter overrides some of the events in the lifecycle of the control, in particular the render event. There are other events that may require overriding as well due to the differences and limitations between devices but you get the idea that such issues are moved from the control itself to a device adapter.

So the culmination of Microsoft’s planning in this area is to move this concept into the ASP.NET server controls to a new unified control and adapter architecture. Effectively the new page framework of version 2.0 works like the MobilePage class of the MMIT. It does so using a page adapter that exposes a full range of information about the capabilities of the current client from the markup language supported to whether it will accept cookies. Then each control that produces device tailored output uses a control adapter to generate appropriate markup to suit the current device.

What does this mean to the developer? Relatively few changes you’ll be glad to know – basically the addition of a few extra properties to the controls. One other change from MMIT is that the required browser definitions that used to be located in machine.config (browserCaps) are moved to separate XML files that have the .browser file extension and are located into the standard .NET directory under Config/Browsers/. A file named default.browser defines the default values and capabilities for the base browser type as well as the more common manufacturer specific values (i.e. IE and Mozilla).

Note that all these files are compiled when the Framework is installed. Thus if a definition is updated recompilation must be manually initiated via the aspnet_regbrowsers.exe utility. One would imagine this would be replaced with an automated process sooner rather than later.

Finally on this sub-topic we should mention device filters which allow the developer to adjust the output of controls. In version 2.0 of ASP.NET this is accomplished by filtering on specific devices or on classes of devices. Further, a similar approach can be employed to change the output of databound controls via device specific templates much like the templates you have with databound controls currently but device specific. Thus for a repeater you might have one item template for HTML browsers which renders a table and another for WML browsers which renders more simply.

New Controls

There are many new controls in ASP.net 2.0! Below is an overview in 6 categories. Please see subsequent articles for a consideration in greater depth (you will get to see some code eventually!). With the exception of some specialist controls, such as the Web Parts controls, all the server controls are implemented in 2 namespaces: system.web.ui.htmlcontrols and system.web.ui.webcontrols, as in v1.X.

Rich Controls

Where 'rich' means that they generate multiple different elements often also including client side code as well. An example from 1.X would be the calendar control. New ones in 2.0 are:

• DynamicImage automatically translates an image into the correct format
• ImageMap (self explanatory)
• Multiview and View allow developers to create different blocks of UI and insert into the page at runtime
• Wizard provides multi page wizard type interfaces
• Web parts (of which more in a subsequent article)

Login and Authentication

Again we'll come back to these in a subsequent article but the new controls extend the built in authentication and authorisation facilities of v1.X.

• Login presents the user with the customary username and password textboxes
• LoginName displays the name of the currently authenticated user
• LoginStatus displays the login status!
• LoginView provides 2 templates in which the UI for a section of the page is specified and the appropriate content displayed depending on the authentication status of the current user
• PasswordRecovery displays a 3-step wizard so the user can have their forgotten password sent to them

Navigation Controls and Counters

In 2.0 new controls are introduced to make it easier to build menus and other types of site navigation UIs.

• TreeView generates a collapsible tree view
• SiteMapDataSource exposes hierarchical XML data in a suitable format for databinding to navigation controls such as the TreeView
• SiteMapPath displays the hierarchical path through the sites page hierarchy to the current page
• PostBackURL: used with the Button controls to force the page to be posted to a different

Data Access and Display

Abstract DataSources make server side data binding to data of differing types and sources much easier to achieve and new display controls are also introduced.

• SqlDataSource and AccessDataSource
• ObjectDataSource provides access to data exposed through a strongly typed data layer, thus supporting n-tier techniques
• XmlDataSource for databinding to control that can display such hierarchical data
• DataSetDataSource for 'flat' XML documents
• GridView, DetailsView and FormView are databound controls like the DataGrid of v1.X.

Mobile Device Controls

As stated above there has been a major shift in mobile device support but there are also some new controls:

• ContentPager helps divide pages into separate sections for small screen devices
• PhoneLink can be used to initiate a phone call

Minor Miscellaneous

These all allow programmatic access to their HTML equivalent and as long as you are familiar with the HTML equivalents their use will be clear.

• HtmlHead, HtmlTitle and HtmlLink controls.
• HtmlInputPassword, HtmlInputReset and HtmlInputSubmit controls
• BulletedList (<ul> and <ol>)
• FileUpload (<input type="file">)
• HiddenField (<input type=”hidden”>)

As stated in the start of this section many of the above sets of controls I'll cover in subsequent articles. Many of the rest are straightforward but I'll spend the rest of this article taking a look at a couple of controls which fit into neither category.

The DynamicImage control

As already introduced the server controls in v2 will automatically adapt their output to the client device. This doesn't include images, which is where the DynamicImage control comes to the fore and allows for the fact that many devices don’t recognise the common image types such as gif, png and jpg.

The DynamicImage control uses the Image Generation Service, accessed via a special .axd HTTP handler to dynamically generate a suitable stream of bytes for the image, rather than the common technique of specifying a src attribute of an <img> element. By providing the correct MIME type when it responds to the request for the image stream, the dynamicImage control mirrors the effect.

The DynamicImage control can also accept as its image source an array of bytes that represents the image, or a reference to an ImageGenerator service that provides an image that has been created using drawing commands. You can also create classes that inherit from ImageGenerator and that create an image, then use these as input to DynamicImage. You can also use DynamicImage to convert images between different types, as well as resize an image either on the server or on the client.

The MultiView and View Controls

You may have seen the Internet Explorer Web Controls of v1.X. This included a MultiView control which allowed declaration of several sets of UI elements which could be displayed on demand. The Web Controls version also exploited IE capabilities to minimise postbacks. However, the v2.0 version does require a postback each time.

The MultiView control chooses which View to display based on the ActiveViewIndex property. There is automatic naviagation between the indexes via buttons or any control that supports the CommandName and CommandArgument properties. Both the View and Multiview expose events you can code against, e.g. ActiveViewChanged for the MulitView and OnActivate and OnDeactivate for the View.

Lastly we'll take a quick look at the Wizard. You won’t be surprised that this is aimed at making it easy for developers to allow users to complete multi-step tasks easily. The Wizard control has the following aims:

• the control should look after as much standard 'plumbing' as possible, e.g. handling viewstate, navigation, etc.
• to provide both linear and non-linear navigation through the Wizard steps
• support the UI provision using styles, templates and themes
• support user controls allowing code reuse

You also won’t be surprised that the Wizard control uses postbacks to the same page until the task is completed. It does not support cross-page posting. The wizard control is quite complex, exposing many properties and methods. Basically you define content for the steps of the Wizard which can be done via styles and templates and you define these steps of a steptype (start, step or finish) so the control knows how to handle them.

Summary

In this article we’ve looked at the controls new to ASP.NET 2.0 in overview. In the next article we’ll proceed to cover the architectural changes of ASP.NET 2.0 as well as the tool support available.

References

ASP.NET v2.0 – the Beta Version
Homer et al.
Addison-Wesley