Click here to Skip to main content
Click here to Skip to main content

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

, 7 Feb 2007
Rate this:
Please Sign up or sign in to vote.
A simple article about how client-side data and events are made available on the 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.).

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Nuno M. F. Gomes
Software Developer (Senior)
Portugal Portugal
Nuno Gomes currently works as a Senior Developer for one of the major portuguese banks.
 
Gomes graduated from Instituto Superior Tecnico with a Electronics and Computers degree in 1999.
 
His daily work main focus is, since 2003, on ASP.NET. A true .NET developer with great passion for the simple solution.

Comments and Discussions

 
JokeRE: PinmemberJF_ROCHA8-Feb-07 0:37 
Seems clearly a infrastructure problem Laugh | :laugh:

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140721.1 | Last Updated 7 Feb 2007
Article Copyright 2007 by Nuno M. F. Gomes
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid