What's New in ASP.NET Web Pages
This topic describes important changes and new features added to ASP.NET Web pages for version 2.0 of the .NET Framework.
ASP.NET pages have been enhanced to provide you with more options to control their appearance.
You can create consistent layout for multiple pages by creating a master page and individual content pages. The master page defines the layout, navigation, and controls that you want to share among the pages in your Web application. The master page can also contain code that applies to all pages. You can then define content pages that reference the master page and merge their content with the master page at run time. For more information, see.
You can now use ASP.NET themes to style Web pages. A theme is a collection of control property settings (referred to as skins), style sheets, and graphics that you can apply as a unit to a page or Web site. Themes enable you to define styling that can be applied to a set of pages, and can be changed as a group. For more information, see.
ASP.NET Web pages have been enhanced with new features that give you improved control over how the page functions.
New Code-Behind Model
ASP.NET continues to support the single-file model in which code is embedded in a script block in the .aspx page. In addition, a new code-behind model has been introduced, which is simpler than the code-behind model that was used in earlier versions of ASP.NET. The new code-behind model is based on partial classes, which enables you to define a portion of a class, such as the event handlers, and keep the code in a separate file. The partial-class file is compiled as part of the .aspx page.
The new code-behind model is available only with .NET languages that support partial classes. Some languages, such as J#, do not support partial classes.
For more information, see.
View State and Control State
In version 1.1 of ASP.NET, view state is used to store control state information, the content of controls, and application data. Developers sometimes want to disable view state to reduce the amount of data sent during a round trip. However, in ASP.NET 1.1, disabling view state causes some controls to stop functioning properly.
In ASP.NET version 2.0 you can disable view state without breaking control behavior. Controls that require state persistence across postbacks store their own data in a private store, which is referred to as control state. Control state does not store the entire content of the control. For example, thecontrol does not store the contents of all rows in control state. Instead, control state is used only to store the minimal information that is required by the control to function across postbacks, which reduces the size of the page.
As in earlier versions of ASP.NET, if you disable view state, you must regenerate control content that is generated dynamically. For example, if you are binding controls to data, when you disable view state, you must rebind the controls to data on each postback.
For more information, see.
Managing View State Size
By default, all view state information is stored in a single hidden field in the page. If a hidden field becomes too large, some proxies and firewalls will prevent the page from being posted. To prevent this problem, you can specify the maximum amount of data to store in a view state hidden field. If the view state information exceeds the specified limit, the page automatically creates additional view state hidden fields and splits the information across the fields. The split and reassembly of the view state fields is done automatically by the page.
Persisting Page State
In ASP.NET version 2.0, you can now create your own classes to persist page state. By default, pages will invoke instances of theclass that store information in a hidden field on the page, as in version 1.1 of ASP.NET. Pages that are used with mobile devices instead store page state in session state to reduce page size even further. By creating a class based on the abstract PageStatePersister class, you can create your own mechanism for saving page state.
By default, ASP.NET pages and controls render markup that conforms to XHTML standards. You can disable XHTML rendering if it would cause your existing applications to stop functioning properly. For details, see.
As in earlier versions of ASP.NET, Web pages post back to themselves when users click a button or other control that posts. You can now configure pages to post to another ASP.NET Web page, which is useful for creating multi-page forms. On the target page, you can get information from the source page, such as the values of controls. For more information, see.
New Page Life Cycle Stages
In order to accommodate new features, such as master pages and themes, theclass supports new methods and events that are available during the life cycle of a page. For example, the Page class now supports a event that you can use to set themes or master pages dynamically. For more information, see .
Access to the Page Header
You can now access the page header directly from server code. The Page object exposes aproperty that gives you an easy way to manipulate linked style sheets, the style element, metadata elements, and the page title.
Using new methods on the Page class (or on individual controls ( ), you can manage which control in the browser has the focus when the page renders. ASP.NET Web pages utilize this new functionality to provide an enhanced capability for maintaining scroll position after a postback. For details, see .
Creating Client Script
The methods for injecting client script into a page (for example, RegisterStartupScript) have been moved from the Page class to a newclass and have been enhanced. The methods on the Page class are still available for backward compatibility, but they are deprecated. The new versions of these methods include a parameter that enables you to designate the type with which the script is associated. This enables you to create separate script blocks for the page and user controls.
For more information, see.
Browser-Specific Property Filtering
You can now create browser filters for property values. This enables you to specify different property values on the same control for different browsers. For example, you can specify that theproperty of a control has one value for Internet Explorer and a different value (perhaps a shorter string) for other browsers. You can filter property values based on classes of browsers (for example, Mozilla-class browsers, Ericksson, or Nokia) or by specific major browser release or major and minor browser releases (for example, Internet Explorer version 4, or Ericksson P800 and P800R101). For more information, see .
You can perform server processing in a page without requiring a full round trip. This enables you to request server-based information from client script. For more information, see.