Month: January 2008

Before proceeding to the implementation details, let’s discuss a little about how ASP.NET handles automatic Id generation.

First of all, the Control.UniqueID property is the key to all major ASP.NET benefits. In fact, ASP.NET gives us unique Id’s for each control which give us a deterministic way of recreating page controls. Without this, Viewstate and Events were impossible to achieve.

ASP.NET also gives us the concept of naming controls, that enable us to easily find the correct control and to write more perceptible code, but [more]it is also here that Microsoft engineers made the mistake:

“They decided to use the given name in the unique Id generation.”

This is why we can find ‘id’ and ‘name’ attributes as long as I’ve shown you earlier.

My naming concept is similar to our real live naming conventions:

“Although we all have a different Identity Card Id it’s possible to exist several citizens with the same name.”

This way, the control will have a:

machine to machine identity (Control.UniqueID )

human to machine identity (Control.ID)

This is not a new concept, attend in the ‘id’ and ‘name’ html attributes roles:

id attribute is there to allow us to find the correct elements (human to machine identity)

name attribute isn’t used by programmer but its value is the one posted to server (machine to machine identity)

So, we understand that, in order to reduce the unique Id length, it’s mandatory to decouple the Control.UniqueID and the Control.ID properties.

Once decoupled, Control.UniqueID will keep its main goal, and even the generation algorithm will stay unchanged.

Our big challenge is to effectively decouple the two properties without changing the ASP.NET paradigm, this mean that changes made should be transparent to programmer.

An important note to keep in mind is that this approach assumes that ‘id’ and ‘name’ attributes wont be human perceptible, and that the only way to uniquely identify a html element that maps a Server control is to use the Control.ClientID property to compose script statements.

Share this:

Some time ago, while developing a large corporate ASP.NET application with high complex layout requirements and thus, many custom composite controls, I was faced with the following problem:

The generated HTML of my pages don’t meet my bandwidth constrain of 50Kb/page, even after applying the traditional ways to reduce page size (compression, viewstate optimization). Looking carefully at the HTML source I found that a big amount of size has due to the large values ‘id’ and ‘name’ attributes. The sum of all this values could be up to 40% of page size, and this became a real issue to me.

So, ASP.NET gives us out of the box a unique strategy to generate the control’s ID values. Although such strategy is most of time a satisfactory approach, there are cases when it can become problematic. [more]

This line of HTML comes from my blog Settings panel (BlogEngine.NET), and, as you can see, the id and name attributes are responsible for a large part of the size of the HTML line. To be precise this two attributes length represent 59.3% of the total length.

What if, somehow, we were able to change the way ASP.NET controls ids are generated? What if we are able to generate something like C0_C3_C1 to represent the some control id?

This way the total HTML length is almost 53% smaller than the standard ASP.NET way. Great improvement!

Now think about all the javascript code that get elements by id, like validator’s generated code do. All this statements will also be smaller. This is getting even better!

It seems that this approach is good enough to try an implementation, but ASP.NET presents a major obstacle to accomplish this task: All the Id generation process is done privately at Control class, without any extendibility point.

Without extension points I was forced to create a specific controls for each control I want to change the ID generation process.