Tips and Tricks

What's New in 2.0

Cross Page Posting - ASP.NET 2.0 allows you to post back from one page to another and you can obtain the source page values from the target page.
Wizard Control - The wizard control allows you to easily add multi-step form entry scenarios to your pages.
Validation Groups - Validation groups allow multiple forms on a page to be separately validated.
Focus API - The Focus API enables you to set focus to any control on the page, specify default buttons to submit for input controls, and more.
Compilation Build Providers - ASP.NET 2.0 includes support for compiling declarative file formats when they are placed in the App_Code directory.
No Compile Pages - Pages in ASP.NET 2.0 can be excluded from the compilation process, to be interpreted at runtime instead.
Securing Non-ASP.NET content - Under IIS 6, you can easily secure non-ASP.NET files such as static images or classic ASP pages from within an ASP.NET application.
Client-Script Features - ASP.NET 2.0 includes several new features that take advantage of client-side script.

This section describes tips and tricks for using several new features in ASP.NET 2.0.

Cross Page PostBack

By default, button controls in ASP.NET pages post back to the same page that contains the button, where you can write an event handler for the post. In most cases this is the desired behavior, but occassionaly you will also want to be able to post to another page in your application. The Server.Transfer method can be used to move between pages, however the URL doesn't change. Instead, the cross page posting feature in ASP.NET 2.0 allows you to fire a normal postback to a different page in the application. In the target page, you can then access the values of server controls in the source page that initiated the post back.

To use cross page posting, you can set the PostBackUrl property of a Button, LinkButton or ImageButton control, which specifies the target page. In the target page, you can then access the PreviousPage property to retrieve values from the source page. By default, the PreviousPage property is of type Page, so you must access controls using the FindControl method. You can also enable strongly-typed access to the source page by setting the @PreviousPageType directive in the target page to the virtual path or Type name of the source page. Note that if you intend for multiple pages to post to a single target page, you cannot use the strongly-typed accessor (leave the PreviousPage directive unset).

C# Cross Page PostBack






Cross page posting works by the following technique:

Cross page posting sets action of the form in Page 1
When the Button is clicked, the post goes from Page 1 to Page 2
Page 2 retains viewstate from Page 1
When PreviousPage accessed, viewstate is re-populated to an instance of Page 1
Page 1 then executes up to its LoadComplete phase (excludes rendering)
At this point, Page 2 may access the values of controls in Page 1

Because Page 1 will execute (up to LoadComplete) in response to a cross-page post, it is sometimes necessary to special-case code in the page to only execute when the request is not a cross-page post, but a normal request to Page 1 instead. You may use the IsCrossPagePostBack property in Page 1 to handle this situation.

function doClick(index, numTabs, id) {
document.all("tab" + id, index).className = "tab";
for (var i=1; i

td.code {
padding-left:10px;
padding-right:10px;
padding-top:0px;
padding-bottom:0px;
border-left: 1px solid #B1B1B1;
border-bottom: 1px solid #DADADA;
border-top: none;
border-right: 1px solid #DADADA;
}
td.tab {
text-align:center;
font: verdana;
width:15%;
border-top: 1px solid #B1B1B1;
border-bottom: none;
border-left: 1px solid #B1B1B1;
border-left: 1px solid #B1B1B1;
cursor: hand;
background: #F0F0F0;
padding: 3px;
}
td.backtab {
text-align: center;
font: verdana;
width: 15%;
border-top: 1px solid #B1B1B1;
border-right: none;
border-bottom: 1px solid #B1B1B1;
border-left: 1px solid #B1B1B1;
cursor: hand;
background: #E3E3E3;
padding: 3px;
}
td.space {
width:70%;
font: x-small verdana;
padding: 0px 0px 0px 0px;
border-top: none;
border-right: none;
border-bottom: 1px solid #B1B1B1;
border-left: 1px solid #B1B1B1;
background: white;
}

C#	VB
if (!Page.IsCrossPagePostBack) { // handle a normal request } If Not Page.IsCrossPagePostBack Then ' handle a normal request End If

You can also post back to another application, however the PreviousPage property is null in this case. You can also transfer in code, while still preserving viewstate through the PreviousPage property using

Server.Transfer(IHttpHandler, preserveViewState)

.

Wizard Control

The Wizard control is used to create a multi-step form entry process in a web page. To specify the individual steps , place a WizardStep object for each entry between the opening and closing tags of the WizardSteps element of the Wizard control. There are many benefits to the Wizard control:

Easily enable multi-step forms and data collection
Handles all aspects of navigation, linear or non-linear
Enables commit-at-finish or commit-as-you-go (AllowReturn=false)
Controls automatically retain viewstate across posts to different steps
Can use built-in UI, or customize through properties or templates

C# Wizard Control

Validation Groups

You can use the ValidationGroup property when you want to perform separate validation scenarios on the same page. Set the group name on validator controls and on the button or other postback control that causes validation. This is useful with Wizard control, MultiView or data controls (for editing scenarios). To enable validation groups, set this property to the same value for all validators that should belong to a common group. On a Button control in the form with CausesValidation set to true, you also set the ValidationGroup property to the name of the group that should be validated when the Button is clicked. By default all validators are in the "" group (default group), for backward compatibility. The Page object also exposes a GetValidators("group") method and Validate("group") method for retrieving a collection of validators in a specific group. Page.IsValid reflects validity of all controls (cumulative) that have had Validate called.

The example below demonstrates the ValidationGroup property. To view the behavior, click the first (Search) button in the page, then click the second button on the page. Notice that a different set of validators fires for each click.

C# Validation Groups

Focus API and DefaultButton

The Focus API allows you to declaratively or programmatically set focus to specific controls on the form. You can use the Page.SetFocus method to pass the ID of a control that should receive focus or you can call the Focus method on the control directly. You can also set the DefaultFocus property of the Form element to the ID of a control that should receive focus when the page is first loaded. Similar to DefaultFocus, you can set the DefaultButton property of the Form element to the ID of a Button control that should submit when the Enter key is pressed inside of any input control on the form. If your page should have different default buttons depending on the input control that has current focus, you can wrap specific input controls in a Panel control and set the DefaultButton property of the Panel instead. Any input control in the Panel will use the Panel's DefaultButton property to submit the form when the Enter key is pressed from within the input control. A validation feature that depends on the Focus API is SetFocusOnError which is set on validator controls to cause the first invalid control to receive focus. The following example shows the Focus API, DefaultButton, DefaultFocus, and SetFocusOnError features in use on a single form.

C# Focus API, DefaultButton, DefaultFocus, and SetFocusOnError






For composite controls, the Focus method sets focus to the first focusable control in the composite control rendering by default, but individual controls can override this behavior to set focus to another element. This example shows the focus given to the first input control in a DetailsView when the Focus method is called when the DetailsView is in edit mode.

C# DetailsView Focus

Compilation Build Providers

A compilation build provider in ASP.NET 2.0 is a type that is registered to "compile" or "build" a declarative file format into something that can be used from your pages. A build provider is registered in configuration and is associated to a specific file extension. When files having this extension are placed into the App_Code directory, ASP.NET invokes the registered build provider to compile the file. ASP.NET 2.0 includes support for several compilation build providers out-of-the-box or you can also create and register your own types (refer to the Extending ASP.NET section for more information. In addition to standard class files in various languages, the following declarative types can be automatically compiled in ASP.NET:

.wsdl - builds a Web Service proxy object
.resx - builds a resources file that can be used for localization
.xsd - builds a strongly-typed DataSet object

No Compile Pages

No Compile Pages enables improved scaling for large sites with 1000s of pages, as windows has limit on number of DLLs loaded into an app and perf degrades as you hit this limit. Set

<%@ Page CompilationMode="Auto" %>

directive to compile conditionally to obtain the scaling benefits without limitations on code. You can also set CompilationMode to "Never" to prevent the page from ever being compiled. You can set this property on the

<pages/>

section in Web.config to apply to all pages in an application. A no-compile page will throw an error when it contains user code. However, you may still use declarative ASP.NET syntax such as data bindings (

<%# Eval %>

and

<%#Bind %>

only) and expressions, such as

<%$ ConnectionStrings:Pubs %>

.

C# NoCompile page






The CompilationMode property only applies to pages, but you can still use types from within the Code directory (for example base classes for pages). If you prefer for no-compile pages to be excluded access to compiled types from the Code directory, lock this directory down in configuration.

C# NoCompile page with a base class






A complementary feature is the pre-compile tool, aspnet_compiler.exe, which allows you to pre-compile an entire site using a command-line tool, to protect your intellectual property (code) in pages and enable deployment without an initial compilation hit.

Securing Non-ASP.NET Files

ASP.NET handles requests for file extensions that are normally associated with ASP.NET, while IIS handles requests for all other file extensions. By default this means common file extensions such as .aspx and .asmx are processed by ASP.NET. This processing includes authentication and authorization to ASP.NET files. Sometimes though, a developer wants non-ASP.NET resources to be processed by ASP.NET. One reason for processing non-ASP.NET files through ASP.NET is to allow ASP.NET authentication and authorization to control access to these types of files.

The combination of IIS6 on Windows Server 2003 and ASP.NET 2.0 provides the most flexibility for running the ASP.NET pipeline as part of processing a request for a non-ASP.NET resource. IIS6 includes support that allows ASP.NET 2.0 to perform authentication and authorization steps, and to then hand off the remainder of the processing of a non-ASP.NET resource back to IIS6. For example, it is possible to authenticate access to an ASP page using ASP.NET forms authentication, authorize access with ASP.NET's Url authorization and still allow the ASP ISAPI extension (asp.dll) to execute the ASP page. This support is possible because IIS6 introduced a new server support function for ISAPI extensions:

HSE_REQ_EXEC_URL

.

Assume that a directory structure contains a mix of both ASP and ASP.NET files. The ASP.NET pages are used to log a user in with forms authentication, while the ASP pages represent the rest of the application. Using the IIS6 MMC, right-click on directory and create an application (this is the same step that is necessary when setting up a standard ASP.NET application). After an application has been created, click on the Configuration button that is located on the Directory property page. This will cause the Application Configuration dialog to be displayed. New to IIS6 is a feature called wildcard application mapping. The bottom of the Application Configuration dialog allows you to configure this feature.

First determine the path for the ASP.NET ISAPI extension that processes ASP.NET files such as .aspx files. You can find this path by looking at the extensions that are listed in the Application Extensions list shown in the top half of the Application Configuration dialog. Click on the row in the list that maps the .aspx extension, and select the Edit button. In the dialog that pops up, highlight the text in the Executable textbox and copy it to the clipboard. Then cancel out of the dialog.

Next, click the Insert button that is in the bottom half of the Application Configuration dialog. A dialog box titled Add/Edit Application Extension Mapping will be displayed. In the Executable text box, enter the path to the ASP.NET ISAPI extension that you copied to the clipboard earlier. The end result should look something like the screenshot below.



Click OK to close out all of the dialogs. Now whenever a request is made for any file, the request will first be processed by ASP.NET. If the web.config for your ASP.NET application has enabled forms authentication, an unauthenticated request for a .asp file will first trigger a redirect to the login page configured for forms authentication. After a user has successfully logged in, they will be redirected back to the original .asp page. When the now-authenticated user requests the .asp page, ASP.NET will first run through the

FormsAuthenticationModule

to verify that the forms authentication cookie exists and is still valid. If this check passes, ASP.NET will hand processing of the .asp page back to IIS6, at which point IIS6 will pass the request on to the ISAPI extension that normally process .asp pages. In this case the extension is asp.dll and the ASP page will then run to completion. The reason ASP.NET will pass the request back to IIS6 is that non-ASP.NET resources will fall through the list of configured

<httpHandlers>

to the following entry:

<add path="*" verb="GET,HEAD,POST" type="System.Web.DefaultHttpHandler" validate="True" />

The

DefaultHttpHandler

is responsible for handing requests back to IIS6 for further processing.

A similar technique with some constraints is available on IIS5 and IIS5.1. These versions of IIS require that for each file extension that a developer wants processed by ASP.NET, an explicit mapping to the ASP.NET ISAPI extension must be added to the Application Extensions list described earlier. The second constraint is that IIS 5.x does not allow a request to be passed back from ASP.NET to IIS 5.x. As a result, only static files requested using the GET verb can effectively be protected by ASP.NET. After the first half of the ASP.NET pipeline executes (which includes authentication and authorization), ASP.NET will process the resource using an optimized

StaticFileHandler

rather than attempting to pass the request back to IIS 5.x. Attempts to process the POST verb, or to request .asp files will result in a 405 (invalid method) or 403 error (forbidden: access denied) respectively.

Client-Script Features

ASP.NET 2.0 includes a number of features that rely on client-side script in the browser. For example, the OnClientClick property of Button control allows you to programmatically run client-side script when the Button is clicked. The Button renders the client-side

onclick

attribute along with the button's own javascript.

C# ClientClick Event






There are cases where an application requires the position of the page in the browser to remain after post-back to the server. For example, if data entry causes post-back in a large page, the end-user would be required to scroll the page to the position that they were editing at in order to continue. Page developers can simply mark their form to maintain scroll position by setting the MaintainScrollPositionOnPostBack property to true in the

@Page

directive or by setting this in Web.config to apply to all pages in an application.

C# Maintain Scroll Position






An exciting new feature for controls are Client-side CallBacks, which allow a control to execute an out-of-band request back to the server to obtain additional data, without posting the entire page. This feature relies on browser support for callback handling (usually through XMLHTTP), as specified by the

SupportsClientCallbacks

property in browser capabilities.

The TreeView control takes advantage of this feature to enable populating tree nodes on-demand when a parent node is expanded on the client. GridView and DetailsView also take advantage of this feature to implement paging and sorting when EnableSortingAndPagingCallbacks is set to true. A control registers itself as being able to receive callback events by implementing the

ICallbackEventHandler

interface. This interface allows the page to invoke registered delegates for returning callback data to the client. There are two methods of the ICallBackHandler interface,

RaiseCallbackEvent

and

GetCallbackResult

. RaiseCallbackEvent accepts an argument for context (args passed from the client), which can be used to process the event. GetCallbackResult returns a String that represents the data to return to the client. The reason this interface is separated into two methods is to allow for asynchronous processing, for example to retrieve data from a data source control. The control then registers a client-side callback function that knows how to create the arguments to pass to the server-side delegate, and an error handling function to be invoked when an error in callback processing occurs. Finally, the control emits references to callback events using

Page.ClientScript.GetCallBackEventReference

. An example below demonstrates the use of client-side callbacks to implement a cascading DropDownList scenario. In this case, the Page itself implements the ICallbackEventHandler interface, for demonstration purposes.

C# CallBack Event Handlers