ASP.NET Controls - The Bridge between Client and Server-Side

Introduction

In my previous article, I talked about the length of attributes 'name' and 'ID' and why their size can easily grow. In this article, I will focus my attention answering "Why they are rendered and what are their roles in ASP.NET?".

Background

As far as the attribute 'ID' is concerned, its role ends on the client-side, i.e., this attribute is only used by browser engines and by programmers to easily find an HTML element in a page. This very useful attribute is not always required, and thus, is only rendered when programmers explicitly set an ASP.NET control's ID property value.

If you heavily use client-side scripting, then you certainly have thought about why this attribute isn't always rendered. Well, try thinking of the opposite scenario, where all HTML elements have their own ID attribute rendered, even elements that usually are not changed by script (like Labels) and all the others that in your case are not needed. This scenario seems to me as a waste of resources, especially, valuable resources like network bandwidth.

The role of the 'name' attribute is far more complex. In fact, most of the richness of the ASP.NET user experience is built on top of its uniqueness. Unlike 'ID', the 'name' attribute is almost always rendered, and even when it is not rendered directly to element attributes, it could still be in use on script statements (usually in the popular __doPostBack). The 'name' attribute has two tasks to accomplish:

1. The first comes from the old ASP times, and is the fact that the 'name' value is used as the key in POST values in the server-side collection (HttpContext.Current.Request.Form).
2. The second, a new responsibility added by ASP.NET, is to delegate on the 'name' value the responsibility of identifying uniquely the element source of the current post back.

This last responsibility adds a new constraint to the 'name' attribute value: it must be unique, but it also must be something that maps directly to a single Server-Side control, the same that previously rendered the 'name' attribute value.

To achieve this task, every ASP.NET control has a UniqueID property that is built based on the control hierarchy. In order to ensure that a control always has the same UniqueID, it's assumed that its parent hierarchy is always built the same way; even dynamic controls should always be added at the same point of the Page Life Cycle.

Conclusion

As exposed in my previous article, sometimes the 'name' and 'id' attributes grow more than we expect, and we need to think about reducing their size. Any attempts should always preserve the second responsibility of 'name'. If that is not achieved, then you will lose one major ASP.NET benefit:

The bridge between client and server-side that allows raising server-side control events like OnClick and OnChange (OnTextChange, OnSelectIndexChange, etc.).