A2Z Dotnet
4.0 and Visual Studio 2010 Web Development Beta 1 Overview
Many exciting changes for are coming in the .NET Framework version 4.0. This document gives an overview of many of the new features that are included in the upcoming Beta 1 release of .NET 4.0 and in the Visual Studio 2010 release.
Contents
Core Services 2
Extensible Output Caching 2
Auto-Start Web Applications 4
Permanently Redirecting a Page 5
The Incredible Shrinking Session State 6
AJAX Functionality in 4.0 6
Client Template Rendering 7
Instantiating Behaviors and Controls Declaratively 9
Live Data Binding 11
Using the Observer Pattern with JavaScript Objects and Arrays 13
The DataView Control 14
The AdoNetServiceProxy Class 16
The DataContext and AdoNetDataContext Classes 16
Refactoring the Microsoft AJAX Framework Libraries 17
Web Forms 20
Setting Meta Tags with the Page.Keywords and Page.Description Properties 20
Enabling View State for Individual Controls 21
Changes to Browser Capabilities 23
Routing in 4.0 27
Setting Client IDs 31
Persisting Row Selection in Data Controls 34
FormView Control Enhancements 35
ListView Control Enhancements 36
Filtering Data with the QueryExtender Control 36
Dynamic Data 38
Declarative DynamicDataManager Control Syntax 39
Entity Templates 39
New Field Templates for URLs and E-mail Addresses 41
Creating Links with the DynamicHyperLink Control 41
Support for Inheritance in the Data Model 42
Support for Many-to-Many Relationships (Entity Framework Only) 42
New Attributes to Control Display and Support Enumerations 42
Enhanced Support for Filters 42
Visual Studio 2010 Web Designer Improvements 43
Improved CSS Compatibility 43
HTML and JScript Snippets 43
JScript IntelliSense Enhancements 43
Web Application Deployment with Visual Studio 2010 43
Web Packaging 44
Web.Config Transformation 45
Database Deployment 45
One-Click Publishing 45
Resources 45
Disclaimer 47
Core Services
4 introduces a number of features that improve core services such as output caching and session-state storage.
Extensible Output Caching
Since 1.0 was released, output caching has enabled developers to store the generated output of pages, controls, and HTTP responses in memory. On subsequent Web requests, can serve content more quickly by retrieving the generated output from memory instead of regenerating the output from scratch. However, this approach has a limitation — generated content always has to be stored in memory, and on heavily trafficked servers, the memory consumed by output caching can compete with memory demands from other portions of a Web application.
4.0 adds an extensibility point to output caching that enables you to configure one or more custom output-cache providers. Output-cache providers can use any storage mechanism to persist HTML content. This makes it possible to create custom output-cache providers for diverse persistence mechanisms, which can include local or remote disks, cloud storage, and distributed cache engines.
You create a custom output-cache provider as a class that derives from the new System.Web.Caching.OutputCacheProvider type. You can then configure the provider in the Web.config file by using the new providers subsection of the outputCache element, as shown in the following example:
By default in 4.0, all HTTP responses, rendered pages, and controls use the in-memory output cache, as shown in the previous example, where the defaultProvider attribute is set to AspNetInternalProvider. You can change the default output-cache provider used for a Web application by specifying a different provider name for defaultProvider.
In addition, you can select different output-cache providers per control and per request. The easiest way to choose a different output-cache provider for different Web user controls is to do so declaratively by using the new providerName attribute in a page or control directive, as shown in the following example:
Specifying a different output cache provider for an HTTP request requires a little more work. Instead of declaratively specifying the provider, you instead override the new GetOuputCacheProviderName method in the Global.asax file to programmatically specify which provider to use for a specific request. The following example shows how to do this.
public override string GetOutputCacheProviderName(HttpContext context)
{
if (context.Request.Path.EndsWith("Advanced.aspx"))
return "DiskCache";
else
return base.GetOutputCacheProviderName(context);
}
With the addition of output-cache provider extensibility to 4.0, you can now pursue more aggressive and more intelligent output-caching strategies for your Web sites. For example, it is now possible to cache the "Top 10" pages of a site in memory, while caching pages that get lower traffic on disk. Alternatively, you can cache every vary-by combination for a rendered page, but use a distributed cache so that the memory consumption is offloaded from front-end Web servers.
Auto-Start Web Applications
Some Web applications need to load large amounts of data or perform expensive initialization processing before serving the first request. In earlier versions of , for these situations you had to devise custom approaches to "wake up" an application and then run initialization code during the Application_Load method in the Global.asax file.
A new scalability feature named auto-start that directly addresses this scenario is available when 4.0 runs on IIS 7.5 on Windows Server 2008 R2. The auto-start feature provides a controlled approach for starting up an application pool, initializing an application, and then accepting HTTP requests.
To use the auto-start feature, an IIS administrator sets an application pool in IIS 7.5 to be automatically started by using the following configuration in the applicationHost.config file:
Because a single application pool can contain multiple applications, you specify individual applications to be automatically started by using the following configuration in the applicationHost.config file:
When an IIS 7.5 server is cold-started or when an individual application pool is recycled, IIS 7.5 uses the information in the applicationHost.config file to determine which Web applications need to be automatically started. For each application that is marked for auto-start, IIS7.5 sends a request to 4.0 to start the application in a state during which the application temporarily does not accept HTTP requests. When it is in this state, instantiates the type defined by the preloadProvider attribute (as shown in the previous example) and calls into its public entry point.
You create a managed auto-start type with the necessary entry point by implementing the IProcessHostPreloadClient interface, as shown in the following example:
public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
public void Preload(string[] parameters)
{
// Perform initialization.
}
}
After your initialization code runs in the Preload method and the method returns, the application is ready to process requests.
With the addition of auto-start to IIS 7.5 and 4.0, you now have a well-defined approach for performing expensive application initialization prior to processing the first HTTP request. For example, you can use the new auto-start feature to initialize an application and then signal a load-balancer that the application was initialized and ready to accept HTTP traffic.
Permanently Redirecting a Page
It is common practice in Web applications to move pages and other content around over time, which can lead to an accumulation of stale links in search engines. In , developers have traditionally handled requests to old URLs by using by using the Response.Redirect method to forward a request to the new URL. However, the Redirect method issues an HTTP 302 Found (temporary redirect) response, which results in an extra HTTP round trip when users attempt to access the old URLs.
4.0 adds a new RedirectPermanent helper method that makes it easy to issue HTTP 301 Moved Permanently responses, as in the following example:
RedirectPermanent("/newpath/foroldcontent.aspx");
Search engines and other user agents that recognize permanent redirects will store the new URL that is associated with the content, which eliminates the unnecessary round trip made by the browser for temporary redirects.
The Incredible Shrinking Session State
provides two default options for storing session state across a Web farm: a session-state provider that invokes an out-of-process session-state server, and a session-state provider that stores data in a Microsoft SQL Server database. Because both options involve storing state information outside a Web application's worker process, session state has to be serialized before it is sent to remote storage. Depending on how much information a developer saves in session state, the size of the serialized data can grow quite large.
4.0 introduces a new compression option for both kinds of out-of-process session-state providers. When the compressionEnabled configuration option shown in the following example is set to true, will compress (and decompress) serialized session state by using the .NET Framework System.pression.GZipStream class.
With the simple addition of the new attribute to the Web.config file, applications with spare CPU cycles on Web servers can realize substantial reductions in the size of serialized session-state data.
AJAX Functionality in 4.0
The AJAX functionality in 4.0 enables new client data scenarios for page and component developers that allow JSON data from the server to be rendered as HTML in a highly manageable and efficient way. To enable these scenarios, 4.0 includes the following major features:
Client-side template rendering.
Declarative instantiation of client-side behaviors and controls.
Live data binding.
Use of the observer pattern with JavaScript types.
An AdoNetServiceProxy class for client-side interaction with Data Services.
A client-side DataView control for data-bound UI in the browser.
DataContext and AdoNetDataContext classes for interaction with Web services.
Refactored AJAX framework libraries.
Client Template Rendering
In client-based development, templates are the most manageable way of creating UI from data. 4.0 includes a new template engine for client development that meets the following requirements:
Performance — The engine must be able to render a typical number of items using a reasonably complex template before users perceive an interruption in their interaction with the application.
Simplicity — The template syntax must be very readable and must be optimized for the most common scenario, namely one-way/one-time binding.
Expression language — Templates must support an expression language to go beyond the simplest cases. The expression language should use familiar syntax, ideally JavaScript syntax.
Interspersed code and markup — It must be possible to perform conditional rendering or to loop over markup by using code that surrounds HTML.
XHTML compliance — The template should be able to render XHTML-compliant markup.
Components — When using the template syntax, the developer must be able to instantiate client-side controls and behaviors that attach to HTML elements in the page or within templates.
Template Example
The following example shows a typical client template that you can create using 4.0.
{{ Name }}
{{ Description }}
The class attribute of the outer div element is set to sys-template, which is a convention that is used in order to hide the initial template from the user. You should define this class in your CSS style sheet as {display:none;}.
When the template is rendered, it has a data item as context. Fields or properties of that data item can be included in the template markup by using {{ }} expressions — for example, {{ Name }}, if the data item has a Name field. These expressions can be placed anywhere in text content, or you can use them as the value of an attribute. In addition to fields or properties, the expression blocks can also contain any JavaScript expression that can be evaluated as a string.
You can set up DOM events by using the $addHandler method. The DOM on* attributes of elements (for example, onclick=method) also work from within templates.
Instantiating a Template by Using the DataView Control
The most convenient way to use client templates in 4.0 is through the DataView control. The content of a DataView control is used as a template that renders the data item that is provided to the control. If you set the DataView control's data property to an array, the template is rendered once for each item in the array. The DataView control binds to live data, meaning that the control is automatically updated when the data changes, without the need to rebind. This provides a dynamic data-driven UI in the browser. The following example shows the declarative markup for a DataView control that binds to an array named imagesArray.
{{ Name }}
{{ Description }}
Instantiating a Template by Using Code
You can also create a compiled template from code by using the Sys.UI.Template class, as shown in the following example:
var t = new Sys.UI.Template($get("myTemplate"));
The constructor takes the parent element of the template as its argument. You can then render a compiled template into the DOM by calling its instantiateIn method and specifying an HTML container element and a data item as context. The following example shows how to do this.
t.instantiateIn(
$get("targetContainer"),
{
Name: "Name",
Description: "Description"
}
);
Using Pseudo-Columns in a Template
In addition to providing access to fields and properties of the data item, the template rendering engine also provides access to pre-defined "pseudo-columns" such as $index and $dataItem. These pseudo-columns give you access to values from the rendering engine at render time. You can use pseudo-columns the way you use any JavaScript variable in the template instance. The first example applies a different CSS class to the div element for alternating items that are rendered by the dataView control. The second examples passes the pseudo-column $dataItem, which represents the data for the current row, to a custom function named nameConvert for processing.
{{nameConvert($dataItem)}}
Incorporating Code into a Template by Using the code:if, code:before, and code:after Attributes
You can add the new code:if, code:before, and code:after declarative attributes to any DOM element within a template in order to render the element conditionally (code:if) or to render arbitrary code before (code:before) or after (code:after) the element. The following example shows how to use the code:If attribute to render an hr element as a separator between items. The code:if attribute uses the value of the $index pseudo-column to ensure that the hr element is rendered only between items, and not before the first one or after the last one.
{{ Name }}
{{ Description }}
Instantiating Behaviors and Controls Declaratively
4.0 introduces a way to declaratively instantiate client-side controls and behaviors and attach them to HTML elements. The declarative markup is achieved without adding any new HTML elements, simply by including additional namespaced attributes which are XHTML compliant.
Declarative Instantiation Within a Template
Suppose that you want to add a Contoso.DatePicker control to a div element. In 4.0, you can start by declaring a namespace prefix in the opening tag (or in a template's parent tag), similar to the way the @ Register directive works in server-based files. The following example shows a namespace declaration.
The javascript:Sys namespace (typically mapped to the sys: prefix, as shown in the example) is used for a number of system attributes. One of those system attributes is sys:attach, which is used to specify a comma-separated list of controls or behaviors to attach to the element, as shown in the following example:
{{ Name }}
{{ Description }}
The example shows how to instantiate a Contoso.DatePicker control that is attached to a div element and how to set the control's date property to the value of the CreatedDate field of the current data item.
Declarative Instantiation Outside a Template
Declarative instantiation of controls will only work if the declarative markup is within an element that has been configured, or activated, for this purpose. Templates themselves are already activated, so declarative markup to instantiate and attach controls works within a template. But to declaratively instantiate controls outside a template, you must first configure the page to ensure that sys:attach markup is within an activated element. You do this by including a sys:activate attribute on the opening body tag, and setting its value to a comma-separated list of element IDs for the elements that you want to allow declarative instantiation in. The following example activates elements whose IDs are panel1 and panel2:
This causes the AJAX framework to scan the children of those elements for any sys:attach attributes, and to instantiate the corresponding controls.
You can also activate every element in the document. However, doing so can cause a small delay when the page is initialized, so the technique should be used with caution on large pages. The following example shows how to activate the whole document.
A DataView control is typically attached to an element that is not already within a template. This is a common reason to use sys:activate, as in the following complete example:
{{ Name }}
{{ Description }}
Activating Elements Declaratively from the ScriptManager Control
4.0 introduces the ClientElementsToActivate property of the ScriptManager and ScriptManagerProxy controls. This property lets you specify a comma-separated list of elements to activate, much like the sys:activate attribute does on the body element. By using this property, you can specify elements to activate in cases where you do not have access to the tag (such as in a content page). The following example shows how to use the ClientElementsToActivate property.
In the example, the elements with ID panel1 and panel2 are activated. This example also shows references to MicrosoftAjaxTemplates.js and MicrosoftAjaxAdoNet.js, which contain most of the new AJAX features. For more information about these scripts, see Refactoring the Microsoft AJAX Framework Libraries later in this document.
Live Data Binding
The template examples shown earlier include several examples of data binding that uses the one-way/one-time binding syntax: {{ expression }}. This is illustrated by the following example:
{{ Name }}
This type of binding is referred to as one-time binding because the expression is evaluated only once, at the time that the template is rendered. With one-way/one-time binding, if the source data changes after the template has been rendered (in the previous example, if the Name field changes), the rendered value will not be automatically updated.
You can use an alternative live-binding syntax in order to ensure that the target value is automatically updated whenever the source value changes. This is shown in the following example:
{binding Name}
With this binding syntax, if the Name field of the current data item is changed, the rendered value will automatically be updated in response.
This example, where the binding is to a text node (the content of the h3 element), illustrates one-way live binding. The source value (in this case, the data) binds one-way to the target (in this case, an HTML text node), so when the source value changes, the target is updated. But there is no binding from the target back to the source.
Another form of live binding is two-way live binding, which is useful when a text box is provided that enables users to modify the value of underlying data, as in the following example:
In two-way live binding, the binding works in both directions. If the target value is changed (in this case, the value in the UI), the source value is automatically updated (in this case, the underlying data item). Similarly, if the source value is changed (in this case, if the underlying data value is updated externally), the target value (the value in the UI) is updated in response. As a result, target and source are always in sync.
In the following example, if the user modifies the value in the text box, the value that is rendered in the h3 element will automatically be updated to reflect the new value that is provided by the user.
{{ binding Name }}
The live-binding syntax is similar to binding syntax in WPF (XAML). It can be used for binding between UI and data, as in the above examples, as well as directly between UI elements, between data and properties of declaratively attached controls and components, and so on. The syntax also supports additional features, such as providing functions for converting data values to rendered values, or converting back from values entered in UI to an appropriately formatted data value. The following example shows how to provide conversion functions:
A similar syntax can be used to specify a binding mode (one-way or two-way) explicitly:
However, in most cases this is not necessary, because the default binding behavior is that text boxes and other input controls automatically use two-way binding, and other bindings use one-way binding. In the previous example, this default behavior is overridden so that if the data value changes, the value in the text box will change, but if the user modifies the value in the UI, the underlying data value will not be updated correspondingly.
The underlying technology that enables live bindings is the AJAX observer pattern, which is used internally by the Binding class and is described in the next section. For more information about binding, see The DataView Control later in this document.
Using the Observer Pattern with JavaScript Objects and Arrays
The observer pattern enables an object to be notified about changes that occur in another object. (The term observer pattern is often misused in JavaScript frameworks to describe event handling based on the addHandler method and similar techniques.) 4.0 implements the pattern completely. It adds observer functionality to ordinary JavaScript objects or arrays so that they raise change notifications when they are modified through the Sys.Observer interface. (In the present state of JavaScript, changes that are made directly, without going through the interface, will not raise change notifications.) The observer pattern can be used to establish live bindings between UI elements and objects or arrays, such as those you might get from a JSON Web service.
In the following example, the Sys.Observer class is used to add items to the imagesArray array in a way that raises CollectionChanged notifications. As a result, the DataView control will automatically update and display the inserted item after the user has clicked the Insert button. This is possible because the DataView control is bound to its source data (in this case, the imagesArray array that the data property is set to) by using live binding.
var imagesArray = [];
Sys.Observer.makeObservable(imageArray);
function onInsert() {
var newImage = { Name: "Name", Description: "Description" };
imagesArray.add(newImage);
}
Insert
{{ Name }}
{{ Description }}
The DataView Control
The DataView control can bind to any JavaScript object or array, or to any AJAX component.
Providing Data to the DataView Control
Data can be provided to the DataView control in a number of ways. One way is by setting the data property of the DataView control. The following example shows how to set the DataView control’s data property through declarative binding:
{{ Name }}
{{ Description }}
The following example shows how to set the DataView control’s data property through code:
function pageLoad() {
imagesService.GetImages(querySucceeded);
}
function querySucceeded(result) {
$find("imagesList").set_data(result);
}
{{ Name }}
{{ Description }}
Another way to provide data is to specify a WCF or Web service directly in the dataProvider property of the DataView control, as shown in the following example:
{{ Name }}
{{ Description }}
When the DataView control’s dataProvider property is set, the DataView control will use the provider (in this case, the Web service) to fetch data by using the operation specified in the fetchOperation property. For other examples in which the dataProvider property is set to an instance of the DataContext class (used for read-write scenarios) see The DataContext and AdoNetDataContext Classes later in this document.
Additional Features of the DataView Control
The DataView control provides a number of features that are not shown in the previous examples, such as support for layout templates and external templates, built-in selection support for use in master-detail scenarios, command bubbling, and so on. The following example illustrates how to use some of these features to configure linked master-detail views, using two DataView controls that are linked through live binding.
{{ Name }}
Name:
Description:
The Select command in the master view template ensures that when the user clicks one of the items rendered by the master view, that item becomes the selected item. As a result, the CSS class specified in the selectedItemClass property of the master DataView control is applied to the markup for that item. In addition, the corresponding data item becomes the value that is returned by the selectedData property of the master DataView control.
The detail DataView control uses live binding so that its data item is dynamically set to the current selectedData value of the master DataView control. In the example, the detail view provides an edit template with two-way binding that lets users modify the fields of the data item.
The AdoNetServiceProxy Class
The AdoNetServiceProxy class enables read-write interaction with Data Services from JavaScript. The class enables access from JavaScript to a broad range of features of Data Services. It provides direct programmatic access to the basic REST operations provided by Data Services (insert, query, update, and remove), as well as many advanced features such as verb tunneling (custom HTTP methods) and optimistic concurrency.
The AdoNetServiceProxy class is used by the AdoNetDataContext class in read-write scenarios, as explained in the next section.
The DataContext and AdoNetDataContext Classes
For read-write scenarios that use Web services or data services, 4.0 provides a DataContext class that provides full support for change tracking in the browser. This enables complete end-to-end AJAX-based data scenarios.
Typically, data is fetched from the server through JSON services such as a WCF AJAX-enabled service or data services. The data is displayed to the user through dynamic data-driven UI, using the DataView control. Declarative live-binding markup in the template provides users with an edit UI, which enables them to modify the data. The AJAX DataContext class tracks all changes to the data automatically. All changes can then be sent at once to the server by calling the SaveChanges method of the DataContext class. A single DataContext instance can manage change tracking for data returned by different operations on the server, even if the operations return different types of objects.
The following example shows how to use the DataContext class.
var dataContext = new Sys.Data.DataContext();
dataContext.set_serviceUri("../Services/imagesService.svc");
dataContext.set_saveOperation("SaveImages");
dataContext.initialize();
Save Changes
If you are using an data service, you should use the AdoNetDataContext class instead of the more general-purpose DataContext class. (AdoNetDataContext derives from DataContext.) The AdoNetDataContext class provides additional support for features that are specific to , such as identity management, links and associations between entity sets that are returned in different fetch operations, hierarchical data, and optimistic concurrency.
Refactoring the Microsoft AJAX Framework Libraries
As noted earlier, the two important script libraries that contain the new AJAX features in 4.0 are MicrosoftAjaxTemplates.js and MicrosoftAjaxAdoNet.js. As the name suggests, MicrosoftAjaxTemplates.js includes the template-rendering engine and most of the other new features described in this document. The MicrosoftAjaxAdoNet.js file includes classes that are specific to data services, such as the AdoNetServiceProxy class. Therefore, to use all the new AJAX features of 4.0, you can use a ScriptManager control that is configured as in the following example:
4.0 also introduces the ability to use only parts of the AJAX framework for efficiency, as well as the ability to use the ScriptManager control without using the AJAX framework at all. The ScriptManager control provides services such as centralized management of references, support for debug and release modes, support for localization, and script combining. These services can be useful to all client-script developers, even those who use JavaScript libraries other than Microsoft AJAX, such as jQuery. Until now, the ScriptManager control included the Microsoft AJAX library automatically, without providing a simple way to opt out of it. As a result, when developers used the ScriptManager control in their pages, the effect was to include the whole Microsoft AJAX library in their applications.
In 4.0, the default behavior for the ScriptManager control is to include the complete AJAX library. However, the ScriptManager control supports a new MicrosoftAjaxMode property that lets you choose a subset of the framework by using only portions of the library in the form of split script files. The MicrosoftAjaxMode property can have one of the following values:
Enabled — All Microsoft AJAX scripts are included (legacy behavior). This is the default value of the property.
Explicit — Each split script file must be added explicitly; it is up to you to make sure that you include all scripts that have dependencies on one another.
Disabled — All Microsoft AJAX script features are disabled and the ScriptManager control does not reference any scripts automatically.
When you use Explicit mode, the scripts that are available are as follows:
• MicrosoftAjaxCore.js
• MicrosoftAjaxComponentModel.js
• MicrosoftAjaxSerialization.js
• MicrosoftAjaxGlobalization.js
• MicrosoftAjaxHistory.js
• MicrosoftAjaxNetwork.js
• MicrosoftAjaxWebServices.js
• MicrosoftAjaxApplicationServices.js
• MicrosoftAjaxTemplates.js (New for AJAX 4.0)
• MicrosoftAjaxAdoNet.js (New for AJAX 4.0)
The following chart shows the dependencies between split scripts. The violet boxes that are labeled Templates (AdoNetDataContext) and Templates (DataContext) indicate that only these classes in MicrosoftAjaxTemplates.js have the indicated dependency. Thus, MicrosoftAjaxTemplates.js does not require MicrosoftAjaxWebServices.js unless you use the DataContext class, and it does not require MicrosoftAjaxAdoNet.js unless you use the AdoNetDataContext class.
[pic]
The WebForms box for the MicrosoftAjaxWebForms.js script is green to indicate that it is included automatically when you set EnablePartialRendering to true (which is the default setting for the ScriptManager control).
As an example, to use the AJAX browser history feature with no partial rendering and with MicrosoftAjaxMode set to Explicit, the ScriptManager control must be configured as in the following example:
In the example, EnablePartialRendering has been set to false so that MicrosoftAjaxWebForms.js is not included automatically, and EnableHistory has been set to true so that the ScriptManager control can use the AJAX browser history feature. Order is important when you include split scripts — if a script has dependencies, the ScriptReference elements for those dependencies must be listed before the ScriptReference element for the script itself.
Note that split script files should be used only by developers who are concerned about optimizing for very high performance. When split script files are used, they should be used together with script combining to minimize the numbers of requests that are required in order to download the scripts.
Web Forms
Web Forms has been a core feature in since the release of 1.0. Many enhancements have been in this area for 4.0, including the following:
The ability to set meta tags.
More control over view state.
Easier ways to work with browser capabilities.
Support for using routing with Web Forms.
More control over generated IDs.
The ability to persist selected rows in data controls.
More control over rendered HTML in the FormView and ListView controls.
Filtering support for data source controls.
Setting Meta Tags with the Page.Keywords and Page.Description Properties
One of the smaller additions that has been made to 4.0 Web Forms is the addition of two properties to the Page class, Keywords and Description. These two properties represent corresponding meta tags in your page, as shown in the following example:
Untitled Page
In this case, the value of the route parameter searchterm will be used for the @companyname parameter in the Select statement.
Setting Client IDs
The new ClientIdMode property addresses a long-standing issue in , namely how controls create the id attribute for elements that they render. Knowing the id attribute for rendered elements is important if your application includes client script that references these elements.
The id attribute for Web server controls is generated based on the ClientId property of the control. The algorithm up to now for generating the id attribute from the ClientId property has been to concatenate the naming container (if any) with the ID, and in the case of repeated controls (as in data controls), to add a prefix and a sequential number. While this has always guaranteed that the IDs of controls in the page are unique, the algorithm has resulted in control IDs that were not predictable, and were therefore difficult to reference in client script.
The new ClientIdMode property lets you specify more precisely how the client ID is generated for controls. You can set the ClientIdMode property for any control, including for the page. Possible settings are the following:
Legacy – This is equivalent to the ClientID property behavior for earlier versions of . This is also the default if no ClientIdMode property is set in the current control’s hierarchy.
Static – This lets you specify an ID to be used as-is, no matter what naming container the control is in. (This is sometimes referred to as the "you set it, you get it" option.) The Static option gives you the most control over the ID, but is the least safe, in that does not prevent you from generating duplicate or invalid IDs.
Predictable – This option is primarily for use in data controls that use repeating templates. It uses ID attributes of the parent control's naming containers, but generated IDs do not have names that contain strings like "ctlxxx". Only a user-defined ID will be included in the resulting control ID. This setting works in conjunction with the RowClientIdSuffix property of the parent control to allow you to define values that create unique IDs for each instance of the control. A typical example is to use the primary key of a data record as part of the client ID.
Inherit – This setting is the default behavior for controls; it specifies that a control's ID generation is the same as its parent. Explicitly setting ClientIdMode to Inherit specifies that this and any child controls whose ClientIdMode property is either not set or is set to Inherit will take the ClientIdMode value of any parent control. This includes the settings made for the page and in the configuration file.
You can set the ClientIdMode property at the page level. This defines the default ClientIdMode value for all controls in the current page. You set the page-level value in the @ Page directive, as shown in the following example:
You can also set the ClientIdMode value in the configuration file, either at the machine level or at the application level. This defines the default ClientIdMode setting for all controls in all pages in the application. If you set the value at the machine level, it defines the default ClientIdMode setting for all Web sites on that computer. The following example shows the ClientIdMode setting in the configuration file:
As noted earlier, the value of the ClientId property is derived from the naming container for a control’s parent. In some scenarios, such as when you are using master pages, controls can end up with IDs like those in the following rendered HTML:
Even though the input element (from a TextBox control) shown in the markup is only two naming containers deep in the page (the nested ContentPlaceholder controls), because of the way master pages are processed, the end result is a control ID like the following:
ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1
This is a long ID. It is guaranteed to be unique in the page, but is unnecessarily long for most purposes. Imagine that you want to reduce the length of the rendered ID, and to have more say in how the ID is generated (for example, you want to eliminate “ctlxxx” prefixes). The easiest way to achieve this is by setting the ClietnIdMode property as shown in the following example:
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.