Date: December 6, 2004
New Features of ASP.NET v2.0 (Beta)...
In this first article on the Beta product I'll start with an overview of the new features in ASP.NET 2.0.
Date: December 6, 2004
Following on from my article 'Coming up in ASP.Net 2.0' (LINK: http://www.dotnetjohn.com/articles.aspx?articleid=99) published over a year ago now on DotNetJohn I've decided it's about time I dipped my toe a little further into the ASP.NET 2.0 waters seeing as the Beta version has been in the public domain for several months now. I also note that other DotNetJohn authors have been busy looking at this latest version of ASP.NET so I'd better catch up!
In this first article on the Beta product I'll start with an overview of the new features in ASP.NET 2.0. In forthcoming articles I'll look at the architectural changes including the compilation and deployment model as well as the new tool support, before proceeding to look at the new features of v2.0 in further detail in subsequent articles.
What was wrong with ASP.NET 1.0 and 1.1? Not a lot! They were a great step forward from ASP. However, as Microsoft had more time to improve the product they have looked at how it could be improved, informed by feedback from us developers. As a result the following aims have been addressed:
Turning to the new features themselves:
ASP.NET 1.x lacked an out of the box architecture for applying a consistent look and feel to sites (aka templating). Several workarounds have been used:
None of these are ideal. ASP.NET v2.0 introduces the concept of master pages, which is an ASP.NET page that provides a template for the look and implementation of other pages. The master page provides placeholders for content, which can be overridden by child pages.
Themes, the second major feature, also deals with look and feel. Themes (aka skins) allow users to create a customised look for the application. The goals of theming in ASP.NET 2.0 are to:
The implementation is based on two concepts: skins and themes. A skin is a set of properties and templates that can be applied to controls. A theme is a set of skins and other associated files (e.g. images and stylesheets). Skins tend to be control specific. There are two types of theme:
The configuration files for skins and themes are located in the Themes directory of the application root. Each Theme will have its own directory in the Themes directory which in turn will contain a skin file defining the skin details for that theme.
You can, for example, define two skins for a particular control (/sets of controls) and load them at runtime as well as design time to provide different look and feels. The power becomes even more significant when combined with the new personalisation features we'll discuss shortly.
Forms authentication in earlier versions was a great step forward. ASP.NET v2.0 extends the out of the box support for security measures via:
Much of this was easy to do in ASP.NET v1.x but v2.0 makes it all even easier! In particular there is the new membership API which abstracts the required membership functionality from the storage of membership information. The API provides support for SQL Server and Access by default and you can create custom functionality by inheriting from the Membership base class, adding new provider details to the configuration file.
In fact the login control interfaces with the Membership API on the developers behalf behind the scenes. The membership API also integrates with other services such as Personalisation.
The personalisation features provide a simple programming model for storing user details (including those of anonymous users) with easy customisation possible. Like Membership, Personalisation can be configured to work with multiple data providers and provides an easy way to define custom properties for each user. This leads to a user profile with strong types, allowing easy access within ASP.NET pages.
Key is that we don't need to know how the data is being stored – this is abstracted for us – we only have to deal with the user profile.
Question: how do we provide a consistent look and feel while still allowing user customisation, not only of style but also of the content and placement of content? This is what the portal features of v2.0 address. Concepts from SharePoint Server and Outlook Web Parts also provide the framework in ASP.NET v2.0. The concept revolves around zone and web part controls. The zone identifies areas on the page in which the appearance or behaviour of the content is consistent (e.g. colours, styles, layout) and the web parts identify the individual content areas or modules within each zone. There are three different types of web part control:
As well as presentation and drag and drop ability, editing is also part of the new portal framework. By default the user can alter a range of layout and appearance properties and this can be extended. Web Parts can also be exported and imported as XML. Other features allow you to add Help popups to each web part, expose custom properties and allow the user to edit them and connect web parts together so they may interact with each other.
Xcopy deployment was a great advance but other management tasks remained awkward in v1.x. For example, editing of the XML configuration files was required to configure an application. Further you could not create an IIS application easily which was almost always necessary at the point of deployment. Three new features of ASP.NET v2.0 address this area:
There are a couple of relatively minor improvements in this area in v2.0:
A new set of controls has been introduced removing the need for an in depth knowledge of ADO.NET. They provide a consistent and extensible method of declaratively accessing data from web pages. As of the Beta several controls exist for different providers: AccessDataSource, SqlDataSource, XmlDataSource and ObjectDataSource. To use you simply provide connection string and command as properties and the new control can then be bound to data controls such as the datagrid.
DataBinding has been simplified in v2.0 with the syntax becoming
<%# Eval("name") %>
and there is also an equivalent XPath syntax for XPath expressions when binding to XML documents:
<%# XPath("name") %>
You may have noticed the ObjectDataSource control listed above. This allows databinding directly to objects, typically BSL (Business Services Layer) objects abstracted from the DAL (Data Access Layer) in the typical n-tier web application.
Finally there is a similar data binding syntax that allows declarative access to certain configuration parameters, such as application settings, connection strings and resources:
<%$ section: key %>
e.g.
<%$ ConnectionStrings: pubs %>
Many developers thought the internationalisation support for ASP.NET v1.x / VS.NET 2003 was ripe for improvement. In ASP.NET 2.0 support for multiple languages is based around global and local page resources. Global resources live in the Resources folder underneath the application root and consist of XML-based resource files (.resx) containing name-value key pairs. Global resources can be accessed by any page in the application.
Thus at page compilation the browser language would be detected and the appropriate resources selected from the global resource file and included within the page declaratively or programmatically.
Local resources are only accessible per page. Like global resources they are stored in .resx files but in a LocalResources directory where the name of the resource file is the name of the page with the code for the culture supported (if not the default) and the .resx extension added.
The problem with the multitude of devices now available from the ASP.NET perspective is the corresponding variety of screen sizes and rendering capabilities that must be supported. In v1.x the Microsoft Mobile Internet Toolkit provided support in this area with a suite of distinct controls. In v2.0 the support is built into the standard controls. This has required an important change: all controls are now built on a control adapter architecture where there is an adapter for each specific device. The adapter has knowledge of a given device and performs the rendering appropriate for its capabilities including markup language and screen size. Thus the control is not doing anything specific to the device as it is the adapter which renders the content. New devices are supported via the addition of a new adapter to support the device.
The architecture is further extended via device filters and device templates. Device filters are adapter-specific filters for controls thus enabling the page designer to provide different content for specific devices, e.g. different stylesheets could be applied. Device templates are templates for specific devices. For example, if rendering to a mobile phone you might need an entirely different layout for a table of information compared to a web browser. As you know you create templates in data controls such as the datagrid to present information. Device templates allow you to create different templates for different devices.
Additionally there are controls specifically designed for mobile devices such as PhoneLink for phone calls and Pager for pages.
There ends our overview of the new features of v2.0 of ASP.NET. In my next article I’ll take closer look at the architectural changes and tool support for v2.0.
ASP.NET v2.0 - the Beta Version
Homer et al.
Addison-Wesley