ASP.NET Controls - Understanding ID Generation






2.84/5 (21 votes)
An article about how IDs are generated and why they can increase the network bandwidth.
Introduction
Any reader of this article should have, at least once, looked at the source of an HTML page with a simple DataGrid
or a UserControl
and noticed the length of the 'id
' and 'name
' attributes. The purpose of this articles is to understand the "How?" and "Why?" of them sometimes being really long.
Background
These attributes are always unique, and therefore isn't a surprise saying that they are the visible face of the control server-side property called UniqueID
.
The Control
is the base class for all WebControl
s, and supplies three ID properties:
ID
- Which can be set by the programmer.UniqueID
- A generated read-only ID used for server-side and postdata management. This property renders the attribute 'name
'.ClientID
- A special read-only transformation ofUniqueID
for client-side exclusive purposes. This property renders the attribute 'id
'.
A systemic analysis of Control
code shows that the ClientID
value is a UniqueID
value transformation, and this last one is a composition of its NamingContainer.ID
and its own ID.
This relation between properties shows us that it's possible to manage both 'id
' and 'name
' attributes through a simple manipulation of the server-side property ID of all the involved controls.
A potential problem
We should have in mind that almost all corporate ASP.NET solutions require high customization levels and therefore a reasonable number of composite custom controls. Those custom controls are heavily used and increase the parent hierarchy depth significantly. In addition, we cannot forget:
- that naming business entities isn't as simple as that;
- that a name that fully describes the intended functionality will substantially increase the readability and maintainability of code (are we ready to pay this price to simply minimize our pages size?);
- the amazing naming creativity that a programmer is capable of.