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

Introduction

In my previous article I talked about attributes 'name' and 'id' length 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

In concerning about attribute 'id' is role ends on client-side, i.e., this attribute it's only used by browsers engines and by programmers to, easily, find an html element in page. This very useful attribute is not required, and thus, is only rendered when programmers explicitly set ASP.NET Controls ID property value.

If you heavily use client-side scripting then you, certainly, thought why this attribute isn't always rendered. Well, try thinking on the opposite scenario, where all html elements have its own id attribute rendered, even elements that usually are not changed by script (like labels) and all the other that in your case are not needed. This last scenario seems to me a waste of resources, valuable resources like network bandwidth.

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

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

This last responsibility adds a new constrain to '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 render 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 its assumed that his 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 'name' and 'id' attributes grow more than we expect and we need to think about reducing their size. Any attempted should always preserve the second responsibility of 'name'. If that is not achieved then you will loose one major ASP.NET benefit:

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