ASP.NET

ASP.NET 4.0 ClientID Overview

Introduction

One of the new features being added to version 4.0 of ASP.NET is the ability to control the client side IDs that are generated by the framework. Previously the framework would modify the client side IDs to uniquely identify each control. This some times left you with the ID you defined in markup or sometimes left you with something that looks like this, “ctl00_MasterPageBody_ctl01_Textbox1.”
The Problem

The modification of the client side id property works great to ensure that each element is uniquely identified, however, to anyone that has tried to do any sort of client side scripting this becomes very frustrating. Chances are that if you have worked in ASP.NET for any time at all you have run into this issue. The problem is that until runtime you do not what the client side ID could be, making it difficult to do any kind of client side scripting. In addition any modification of the page, adding removing controls, can result in a different client side ID being generated.
Old Solution

Again if you have worked with ASP.NET for any amount of time you know there is a work around for this issue. Each control has a property called ClientID that is a read only and supplies the unique client side ID. You can use this in a code behind when dynamically adding scripts, or more commonly use inline code (old ASP style) to supply the value to and client side scripts.



ASP.NET 4.0 Solution

First off let me start by explaining why we decided to tackle this problem in version 4.0 of the framework. While we provided a way of supplying the developer with the client side ID, with the growth of client side scripting this solution has become some what hacky. There is not really a clean way to use this with lots of controls and lots of external script files. Also it might have had something to do with the developer asking for control over this. Developers do love to have control of everything, weather they use it or not, it’s just our nature :) The solution that we came up has four ‘modes’ that a user can use giving them everything from existing behavior to full control. The controls ID property is modified according to the ClientIDMode mode and then used as the client side id.
Modes and what they do

There is now a new property on every control (this includes pages and master pages as they inherit from control) called ClientIDMode that is used to select the behavior of the client side ID.



The Mode Types

* Legacy: The default value if ClientIDMode is not set anywhere in the control hierarchy. This causes client side IDs to behave the way they did in version 2.0 (3.0 and 3.5 did not change this code path) of the framework. This mode will generate an ID similar to “ctl00_MasterPageBody_ctl01_Textbox1.”
* Inherit: This is the default behavior for every control. This looks to the controls parent to get its value for ClientIDMode. You do not need to set this on every control as it is the default, this is used only when the ClientIDMode has been changed and the new desired behavior is to inherit from the controls parent.
* Static: This mode does exactly what you think it would, it makes the client side ID static. Meaning that what you put for the ID is what will be used for the client side ID. Warning, this means that if a static ClientIDMode is used in a repeating control the developer is responsible for ensuring client side ID uniqueness.
* Predictable: This mode is used when the framework needs to ensure uniqueness but it needs to be done so in a predictable way. The most common use for this mode is on databound controls. The framework will traverse the control hierarchy prefixing the supplied ID with it’s parent control ID until it reaches a control in the hierarchy whose ClientIDMode is defined as static. In the event that the control is placed inside a databound control a suffix with a value that identifies that instance will also be added to the supplied ID. The ClientIDRowSuffix property is used to control the value that will be used as a suffix (see samples). This mode will generate an ID similar to “Gridview1_Label1_0”

Samples


Legacy Mode

Legacy mode is pretty straight forward, it generates a client side ID the way that it had in version 2.0 of the framework.

markup:



output:



Static Mode

Static is the most basic of all ClientIDMode modes, what you give for the ID is what you get for the client side ID. Once again a warning that if a static ClientIDMode is used inside of a repeated control it is the developer’s responsibility to ensure client side ID uniqueness.

markup:



output:



Predictable Mode

Predictable mode really tackles the heart of the problem. The framework previously generated it’s unique IDs to prevent ID collisions and the most common place for these types of collisions are inside databound controls. Predictable mode is really designed to work with databound controls but does not have to. There is three ways to uses the predictable mode, each one of these is defined through the ClientIDRowSuffix property that specifies the suffix for each instance. The ClientIDRowSuffix uses values from the control’s datakeys collection, so if the control does not have a datakeys collection this property is not viable. If this property is not set or is not available the row index will be used in it’s place.

1. With no ClientIDRowSuffix defined, this is also the behavior for databound controls without a datakeys collection e.g. Repeater Control. Notice that the framework has traversed the control hierarchy and prefixed the ID with the parent’s ID and suffixed the ID with row index.

markup:
















output:











...

ID	Name
1	EmployeeName1
9	EmployeeName9

2. With a ClientIDRowSuffix defined, this looks in the control’s datakeys collection for the value and then suffixes the ID with that value.

markup:
















output:











...

ID	Name
1	EmployeeName1
9	EmployeeName9

3. With a ClientIDRowSuffix defined, but instead of just one value a compound value will be used. Exhibits the same behavior as one value but it will suffix both values onto the ID.

markup:
















output:











...

ID	Name
1	EmployeeName1
9	EmployeeName9

Summary

The ability to fully control the client side IDs that are generated by the framework is a request that has not generated much noise but everyone seems to want it when you mention it. We believe that we have found a good solution to the request and think that it adds some much need functionality for developer that use lots of client side scripting. There is an early preview and a walk through of this feature in CTP build that we released at PDC 2008. For more information and a much more detailed description of this feature read Scott Galloway’s blog post

Source
http://blog.osbornm.com