Programming Microsoft ASP.NET 4 - Dino Esposito [119]
This wouldn’t be too bad except that you need to figure out yourself what the actual ID of a bound element is going to be. The autogenerated ID ensures that each ID is unique, but the actual name is not always predictable.
Until ASP.NET 4, you had no way to change the naming algorithm. In ASP.NET 4, you can choose from a few options.
Client ID Modes
The default algorithm entails that the name of each repeated element be scoped into the naming container. This explains the first token of Repeater1. Note also that controls that are not assigned an explicit ID are given a system-provided progressive ctlXX string. In the previous example, each bound element is wrapped in an implicitly created RepeaterItem control with a ctlXX ID. This explains the progressive ctlXX token. Finally, the common name of the element is appended. Note that what makes two IDs unique is just the presence of implicitly named controls such as the RepeaterItem. In ASP.NET, any data-bound, template-based control follows a similar schema.
As mentioned, in ASP.NET 4 the base Control class features the ClientIDMode property. The property is declared to be of type ClientIDMode—an enumerated type. Table 6-3 lists the feasible values for the property.
Table 6-3. Values in the ClientIDMode Enumeration
Value
Description
AutoID
The control generates its child IDs using the legacy algorithm used by previous versions of ASP.NET.
Inherit
The control doesn’t define its own policy for ID generation. The control inherits any policy valid on its parent. This is the default option for individual controls.
Predictable
Any ID is generated by simply concatenating the IDs of parent elements. This is the default option for pages and automatically propagates to controls unless you make some changes to the code.
Static
No mangled ID is generated; the assigned ID is emitted in the markup as is.
The value for the ClientIDMode property can be set at various levels: for individual controls, or for all controls in the page via the @Page directive. Finally, you can even set your preference for all pages in the application by storing the setting in the ... When the Static option is selected, ASP.NET doesn’t apply any name mangling to the original ID. The ID is emitted without concatenating the IDs of parent naming containers. In the case of repeated templates, however, you end up having multiple IDs in the client page. As mentioned, this violates the HTML standard, but it won’t generate any run-time error in most browsers. The Static option is not a good one to use with iterative, data-bound controls such as GridView, ListView, and list controls. On the other hand, the Static option is useful when you write user controls devoid of data-bound child controls. Because a user control can be located on different pages and in different container controls, the default algorithm for IDs will generate different IDs each time. Clearly, this makes it quite difficult for you to write client script for embedded elements. Although you can work out some tricks and solve the issue, the Static client ID mode makes it more direct and simpler to do so. A more interesting scenario is when you set the ClientIDMode property to Predictable. In this case, ASP.NET still guarantees that unique IDs are generated but it uses a different algorithm. How is this new algorithm different from the legacy one that was the only option up to ASP.NET 3.5? The legacy algorithm that generates the client ID of a control is generated by concatenating the ID values of each parent naming container with the ID of the control. Each segment is separated by an underscore character (_). With the Predictable option, the client ID of a control is generated by concatenating the value of the ClientID