ASP.NET Controls - Understanding ID Generation

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 WebControls, 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 of UniqueID 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.