This is just another example of fancy tools making things easier while at the same time taking away power and flexibility. It’s great that ASP.NET can generate all kinds of fancy markup based on serverside code, but if it’s going to mangle the ids to keep conflicts away, it really should have included a map – like yours – so that we can still operate clientside. Otherwise, all that markup doesn’t do us much good, does it?

Keep up the good work!

I thought that asp.net control IDs would be available in JavaScript (JS) in VS 2008, though they don’t seem to be (either that or I haven’t clued in to how this is achieved in VS08 without 3rd party help).

Then I found this tool. Works great! I caution its use, perhaps to internal web apps, as it exposes too much of the code-behind in the ClientIDs array; e.g. actual asp.net control ID names.

Also, ClientIDs array has *every* control in it, whether I use it in JS or not; I prefer only those controls which I want exposed in JS. I could hardcode something, use generally global IDs, or put an identifier in the .NET ID, such as “JAG” at the end of the controlID [a form of recognition for James' solution, per se].

I first opted for putting JAG at the end of the .NET ID. I then modified ServerControlIDs.GetMappedIDs to only process those controls wherein the .NET ID ends with “_JAG”.

This may work for the most part for most programmers; however, I was adding/removing this tag more than I wanted, so I implemented a more generic tag in the .NET ID that I already use.

For years I’ve append a prefix to my .NET IDs, such as ‘txt’ for Textbox, ‘btn’ for Button, ‘chbx’ for checkbox, ‘ddl’ for DropDownList. You may see where I’m going with this. Rather than suffixing “_JAG” (sorry, James!!), I merely changed ServerControlIDs.GetMappedIDs to look for my already used prefixes at the beginning of the .NET ID. That way, I don’t have to add/remove “_JAG” (again, sorry James!) to the .NET ID.

So, James, your code has made my life easier, yet more complex! I’m now doing double validation coding! client-side now (via leveraging your solution) and server-side (which, in reading other blogs, it seems to be a ‘best practice’ to be doing double-validation anyway . . . )

Thanks, James.

Cheers!

GaryN

Naz: Glad you found it of some use!