Contact   •   Products   •   Search

Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs

A generic way to find ASP.NET ClientIDs with jQuery


I’ve been using a small hack to deal with the ASP.NET naming container morass that is so prevalent in client side development with ASP.NET. Particularly in Master Pages all server control IDs are basically munged  because the master page place holders are naming containers.

To recap – the problem is that if you are dealing with something as simple as this:

<div class="contentcontainer"  runat="server" id="PageContent">
    <h2>Stock Quote Lookup</h2>
    
    <div class="labelheader" style="margin-top: 20px;">Enter a stock symbol:</div>
    <asp:TextBox runat="server" ID="txtSymbol"  /> 
    <input type="button" id="btnGetQuote" value="Go" />
    
    <div id="divStockWrapper">
        <div id="divStockDetail">        
        </div>
        <img id="imgStockChart"  />
    </div>
</div>

inside of master page or even a container or user control you end up generating HTML output that looks something like this:

<div class="contentcontainer" id="ctl00_MainContent_PageContent">
    <h2>Stock Quote Lookup</h2>
    
    <div style="margin-top: 20px;" class="labelheader">Enter a stock symbol:</div>
    <input type="text" id="ctl00_MainContent_txtSymbol" 
name="ctl00$MainContent$txtSymbol" /> <input type="button" value="Go" id="btnGetQuote"/> <div id="divStockWrapper"> <div id="divStockDetail"> </div> <img id="imgStockChart"/> </div> </div>

Notice the ctl00_MainContent prefixes that are added to the server controls that point to the master page and content container respectively. You get those nice and un-friendly ASP.NET naming container generated ids that are a bitch to use in client side code. You don’t want to use these generated names directly because they can easily change if you rename any of the IDs down the chain – if you change the content placeholder’s id so will the id and your script code might break because of it. Not a good idea to use those ids directly.

Now if you want to access this client code you have to jump through a few hoops. A few common ways to access these values with jQuery look like this:

$("#<%= txtSymbol.ClientID %>")

or slightly better more generic approach that stores all client IDs in an object globally:

var ids = { 
    txtSymbol: "<%= txtSymbol.ClientID %>",
    PageContent: "<%= PageContainer.ClientID %>"
}
// to use it any where in code:
$("#" + ids.txtSymbol)

The latter also partially gets around the main problem with ClientIDs in that they only work in ASPX pages not external .js files. The latter approach lets you declare only the id definitions in the main page, but the IDs can be globally accessed even in a .js file.

I also posted about a ScriptVariables component that can automate this object creation  on the server as part of a component (ScriptVariables component and updated code) so you don’t have to manually map all of the client ids – the component can do it automatically (as well as a few other things like passing any values into JavaScript explicitly with proper formatting ). With this component you have a couple of lines on the server (anywhere in a Page):

ScriptVariables scriptVars = new ScriptVariables(Page, "serverVars");
scriptVars.AddClientIds(Form, true);

which generates a serverVars variable into the client. You can then use the ids like so:

$("#" + serverVars.txtSymboldId)

All of these workarounds are pretty ugly though.

A better Solution

A solution I’ve been using a lot lately is by taking advantage of jQuery itself. We can search for Ids directly from JavaScript since there’s a pretty simple pattern to clientID – at least when dealing with non-repeating values.

Remember a typical client ID that isn’t in a list control of some sort looks something like this:

ctl00_MainContent_txtSymbol

which is actually fairly easy to find with jQuery:

alert( $("[id$=_txtSymbol]").attr("id"));

You can use that directly in your JS code from anywhere that works for most situations, but while it’s not exactly complicated you still have to remember what the format of these controls looks like and how to do an attribute search. It also doesn’t deal with the case where a control might just exist on a page without a master/naming container. How many times have you created a client code page that started out as standalone page and then you later added a Master Page only to find out most of your script code is broken due to the invalid IDs? I know I have.

Knowing the above though it’s easy enough to create a small routine that returns us a jQuery object based on only the id:

function $$(id, context) {
    var el = $("#" + id, context);
    if (el.length < 1)
        el = $("[id$=_" + id + "]", context);
    return el;
}

This code uses jQuery to first do a plain ID search and the behavior of the function is the same as the native jQuery constructor except for the specific selector implementation that only finds IDs. Just as with jQuery you can pass in a relative selector context ( a jQuery object or DOM Element) that limits the search to children of that elements’ level in the DOM hierarchy.

If the function finds a direct match on the ID that’s returned. If not it checks to see if a context was passed. A context is the container context and if passed the search here is limited to that specific container and its immediate children. This is meant to make it easier to isolate naming containers in case there is a possibility of overlapping names so you can drill into a specific user control for example.

So in simple usage to select my ctl00_MainContent_txtSymbol value both of the following work:

alert( $$("txtSymbol").attr("id") );

Or if I want to be specific about the container:

alert( $$("txtSymbol",$("#wrapper")).attr("id") );

This is a low impact approach to dealing with client ids that is easy to type and understand. Obviously you can name this function anything you chose – the $$ just seemed like a good choice to me that doesn’t conflict with anything that jQuery isn’t already conflicting with :-}. I suppose it would also be possible to create a special selector operator in jQuery for this, but I think I actually like the single function implementation better even though it lives outside of jQuery.

Please realize that this won’t address all scenarios where naming container variables might be involved. Specifically this function only deals with the simple ASP.NET variable case – it doesn’t deal with list controls that output sequentially numbered ids, but then that’s not really been an issue for me. I don’t think one often searches for list items by ID directly – they are usually accessed by event behavior or iteration – rarely directly by ID.

Single controls however - I constantly access to get or set values on and manipulate items. While I get more and more away from using server controls at all there are still plenty of times when naming container naming ends up in markup and this makes using these controls a no-brainer.

Performance

Also realize that doing attribute selector searches are fairly slow (but then ‘slow’ is relative). If you have very large documents with lots of elements and you’re doing many lookups using this function you may run into slow performance issues. If that’s the case using the original concept of a global variable that holds all the ids – either manually created or via the ScriptVariables component from the West Wind Web Toolkit –  to get better performance. Because that approach uses direct element ids it’s very efficient as ID lookups in a document are among the fastest lookups the DOM can perform.

So as usual there are trade-offs – you’re trading convenience over performance with the $$() function I showed here.

I hope some of you find this simple solution useful.

Make Donation
Posted in jQuery  


Feedback for this Post

 
# A generic way to find ASP.NET ClientIDs with jQuery
by DotNetKicks.com October 15, 2009 @ 2:08am
You've been kicked (a good thing) - Trackback from DotNetKicks.com
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Benjamin Wegman October 15, 2009 @ 4:09am
You should also have a look at: http://john-sheehan.com/blog/updated-webforms-custom-selector-for-jquery-13/

He creates a custom selector for jQuery, so you can do queries like: $(":asp('txtSymbol')")
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Rick Strahl October 15, 2009 @ 4:33am
Yeah I thought about using a custom selector, but these are effectively filters and quite a bit less efficient, plus the filter syntax requirement is kinda messy to my eye.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by a. October 15, 2009 @ 5:04am
your solution works exactly tge same way as filters in all browsers which does not have native css selector support (or does have but jquery does not support it)

it will enumerate _all_ elements in the document which can be a pretty big performance hit in larger documents
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Peter October 15, 2009 @ 5:45am
It must be possible to use the features documented by ASP.NET AJAX. When using controls, a script control can pass in the ClientIDs to a javascript prototype class in its GetScriptDescriptors method:
protected override IEnumerable<ScriptDescriptor> GetScriptDescriptors()
{
ScriptControlDescriptor descriptor = new ScriptControlDescriptor("Controls.Widget", this.ClientID);
           descriptor.AddProperty("SomeOtherControlsClientID", SomeOtherControl.ClientID);

            return new ScriptDescriptor[] { descriptor };
}

Then the javascript resource "Controls.Widget.js" can use jquery and directly refer to the ClientID via its property "SomeOtherControlsClientID".

Verbose... but its not fighting the system.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Aman Tur October 15, 2009 @ 6:01am
the idea:
var ids = {
txtSymbol: "#<%= txtSymbol.ClientID %>",
PageContent: "#<%= PageContainer.ClientID %>"
}
// to use it any where in code:
$("#" + ids.txtSymbol)

is far better than

$("input[id$='txtComment']")

this later less efficient.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Steve October 15, 2009 @ 6:06am
Great timing! I was -- even now -- trying to this and thinking there must be a better way!
# re: A generic way to find ASP.NET ClientIDs with jQuery
by David October 15, 2009 @ 7:24am
Nice! I need to review my jquery selector syntax again.

I've been using the following function for a while, which doesn't rely on jquery, but now that I use jquery pretty much by default, I may switch.

function getControl(tagName,id,parent) {
    if (!parent) parent = document;
    var els = parent.getElementsByTagName(tagName);
    for (var i=0; i < els.length; i++) {
        if (els[i].id.search(id + "$") > -1) {
            return els[i];
        }
    }
    return null;
}
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Cristovao Morgado October 15, 2009 @ 7:54am
How About using class selector?

on asp.control CssClass="idMyobj OtherCssClass"

on jQuery $(".idMyobj")
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Chris Brandsma October 15, 2009 @ 8:19am
I've used both varieties you outlined. I like the postfix fetch on ID, but it can take a while when dealing with large pages, so I gravitate to the global definition.

But, now I've switched to Asp.Net MVC, so I don't have the Id problem anymore. Instead I have a an AJAX issue. Because I can no longer count on my page being in a particular directory hierarchy, I can't hard-code my Ajax method names (probably a bad idea anyway). So I have Url.Content("Method", "Controller") all over my code.

This would be fine, but I also like having the majority of my JavaScript in separate files, which don't have access to Url.Content. So now I'm back to making global objects for accessing names, just like old times.

Anyone know how to make an jsx just like the aspx we have with mvc?
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Dave Juth October 15, 2009 @ 8:49am
I like that! I went through the simple case of this a while back (http://jutherman.blogspot.com/2007/12/aspnet-control-ids-and-jquery.html) and thought the id-ends-with selector was good enough. But it's a pain and I know it's fragile.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by James Hughes October 15, 2009 @ 10:00am
I think the class selection method is a bit better i.e. $('.someSpecialClass') simply because attribute searching is both slower and less predictable in changing environments. Class selection on large DOM's tend to be significantly faster then attribute parsing plus if someone then introduces a new element, or a new instance of your user control of uses your control inside a repeater you get into trouble.
# A generic way to find ASP.NET ClientIDs with jQuery - Rick Strahl
by DotNetShoutout October 15, 2009 @ 10:05am
Thank you for submitting this cool story - Trackback from DotNetShoutout
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Nicholas October 15, 2009 @ 10:50am
The method you're describing is what I use in my own development. However, I also qualify the selector with the element type I'm looking for, aka:

$('input[id$=MyASPNetID]')

This is actually faster, since jQuery internally can filter down by element name, then run the selector logic. How much faster will depend on your usage, obviously..
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Steve October 15, 2009 @ 10:51am
I could never being myself to deal with this nightmare that is part Master pages, so in spite of much convenience I opted not to use them long ago.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Rick Strahl October 15, 2009 @ 1:09pm
@Chris - I hear you on the MVC issues. Pathing in MVC especially for page relative content is a royal pain - in fact I'm still playing around with what feels right in terms of where to place script related script and CSS files. This is definitely one place where having a fixed page location and folders that can hold related data is easier.

As to selector speed that many mention here: Yes using Attribute selectors is slow and if you do need the extra performance the explicit declarations are more effective. However, I suspect in most situations we're looking for a single ID'd element and that look up and a single lookup likely isn't going to kill perf too badly.

And if you want to use the explicit object scoped client IDs you can check out the ScriptVariables component which will automatically spit out client IDs without manually adding them to the document. I've been using that approach successfully for quite some time and it adds basically two lines of server code.

Prefixing the attribute selector with a specific element prefix ( like input[...] ) will make it more efficient for sure, but that's not going to help if you need to select other controls like labels, Panels, or HTML elements.

This is obviously a convenience function meant to make it easy to retrieve the IDs without having to think about the underlying logistics of how client IDs work.

@Steve - re: Master Pages. Agree. I always contemplate not using them in my apps for the naming container mess they create, but they are so damn useful that I always end up using them anyway.

@Chirstavo - Using class selectors is a good idea but it requires some extra effort on your part to explicitly tag controls with the class name you want for an Id. I suppose ASP.NET 4.0 will let us address this as well via customized ClientIDs (and effectively allowing to turn off ClientID munging).
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Mark Kadlec October 15, 2009 @ 9:11pm
Awesome Rick, very simple to use and makes for easier reading of the actual JQuery portion of the code.

Thanks for sharing!
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Stephen October 16, 2009 @ 5:56am
I still feel that Wilco Bauwer's "ID Override" library is maybe the most under rated piece of ASP.NET code put out ever...

If you are sure that you are only going to have one item on the page with the ID in question you want to use in JavaScript/jQuery, then nothing makes it easier than this:

http://codepaste.net/3vued8

results in

<input type="text" id="txtSymbol" />

and saying/using TextBox1.Text still works perfectly fine in server side script

But again, this won't work for *repeated* controls, but sure takes care of one time controls.... all with no muss and no fuss
# re: A generic way to find ASP.NET ClientIDs with jQuery
by David Carrillo October 16, 2009 @ 9:03am
Well in my JQuery development for ASP.NET I have been using

jQuery("input[id*='txtName']")

This has worked fine for me. Do you think is less efficient this method?
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Stephen October 16, 2009 @ 1:02pm
jQuery("input[id*='txtName']")

There's two major issue with that:

1) jQuery will go through every single <input> object on the page and be asking "does the ID contain 'txtName'" (that's not too efficient)

and possibly more destructive:

2) Say you had <asp:TextBox id="txtName"> in some sort of repeated control, your selector will get *all* <input> tags containing that string..... which who knows, could be desired results, but then again might not....
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Rick Strahl October 16, 2009 @ 1:34pm
@Stephen - wow, never knew Wilco had that ClientID control. At some point I was going to implement something like this for the ScriptVariables control as well.
# links for 2009-10-16
by SKOROZSI.NET October 16, 2009 @ 2:05pm
links for 2009-10-16
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Speednet October 16, 2009 @ 3:03pm
There is one other way to do this, and either not many people know about it, or else nobody is talking about it.

I posted this over at Chris Love's blog about a week ago, but it didn't generate much interest over there.

Instead of trying to place an ID or CssClass attribute directly on the element that you're looking for, simply wrap the ASP.NET control inside a plain DOM element, like so:

<span id="findMe"><asp:TextBox ID="Anything" runat="server" /></span>

Then use the following jQuery:

$(#findMe:first-child")

This can also have a wrapper function like Rick's "$$" above:

function $$(selector, context) {
return $(selector, context).children(":first");
}

~OR~ (maybe a little faster):

function $$(selector, context) {
return $(selector, context)[0].firstChild;
}

When ASP.NET 4.0 comes out, after fixing the ClientID, simply replace instances of $$(...) with $(...).

-Todd
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Rick Strahl October 16, 2009 @ 3:20pm
@Todd - the problem is that you're adding a bit of noise to your document. I think of the 'add anything to the document' approaches I think that a class is the cleanest way as it doesn't interfere with the document in any way. It leaves everything as it is and simply adds a class.

Ultimately I prefer to not have to modify my layout in any way, just my code. Once ASP.NET 4.0 comes out client ids can be overridden at the container level but with this at least the code also doesn't break in that scenario.

Ultimately this is all preference. Interesting how many different ways people have dreamt up for this scenario of dealing with the damned naming containers.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Speednet October 17, 2009 @ 5:47am
I hear you Rick. There are trade-offs with every single approach, except the one coming in 4.0. However, the UPside to using my approach is that it's among the fastest -- certainly faster and more efficient that the CssClass method, in terms of raw performance.

Personally, I use both approaches in my own code. When using "hacky" solutions like all of these, it's important to use the best one given the situation.

I'm not overly concerned about a small wrapper element, although I understand the concern, because they are used so often in other scenarios in the course of common HTML development, mainly to overcome CSS weaknesses, and they are also used extensively by the ASP.NET server controls in their normal output.

For example, if you put an <asp:Checkbox /> control on the page and give it a text label, you will get a <span> wrapping <input> and <label> controls. Other ASP.NET server controls output similar "noise".

Anyway, I thought I'd put this approach out there because it has proved useful to me in several scenarios.

As always, thanks for maintaining such a useful and informative blog.
# A generic way to find ASP.NET ClientIDs with jQuery
by PimpThisBlog.com October 19, 2009 @ 1:20pm
Thank you for submitting this cool story - Trackback from PimpThisBlog.com
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Loris October 20, 2009 @ 2:41am
Hi Rick,
I too have been battling with Naming Containers ad Client IDs lately. In the end, my solution was server side - overriding (control-by-control :( ) the ClientID propery. Coincidentally, it's one of your earlier posts that put me on the right track!
I blogged about it at http://www.gljakal.com/blog/2009/10/06/getting-rid-of-the-naming-container-in-asp-net-2-0-update/
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Mike October 23, 2009 @ 1:27pm
A side benefit to ASP.NET id munging is that it's forced me to work closer to the DOM hierarchy and seed JQuery selectors with ancestor/descendant hints that ultimately improve performance (over the lazier full DOM scan approach).

Great idea. I'll give this wrapper a try.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Andrew Johns November 03, 2009 @ 9:07am
Quote:
"The method you're describing is what I use in my own development. However, I also qualify the selector with the element type I'm looking for, aka:

$('input[id$=MyASPNetID]')

This is actually faster, since jQuery internally can filter down by element name, then run the selector logic. How much faster will depend on your usage, obviously.. "

I agreed with this, which made me wonder if the original function can't just be modified to something like this?

function $$(id, tag, context) {
var el = $(tag + "#" + id, context);
if (el.length < 1)
el = $(tag + "[id$=_" + id + "]", context);
return el;
}

which would mean the examples become:

alert( $$("txtSymbol", "input").attr("id") );

alert( $$("txtSymbol", "input", $("#wrapper")).attr("id") );

Note: Not tested this, it's just musings while reading this post :)
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Peter Kassenaar July 16, 2010 @ 1:42am
The simplest approach (i.e. alert( $("[id$=_txtSymbol]").attr("id"));) worked for me.

Thanks for putting jQuery to the rescue!
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Chris Sullivan February 09, 2011 @ 8:37am
Thanks very much Rick, we had always used

var ids = {
txtSymbol: "<%= txtSymbol.ClientID %>",
PageContent: "<%= PageContainer.ClientID %>"
}

which works well until you come to dynamic content or hidden panels that are made visible in post backs. Another excellent and informative post.
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Lars February 12, 2011 @ 11:29am
Great work!

I was pleased to find your solution to this ID mess in ASP.NET. And it works very well, but it seems like it does not find ids for hidden textfields? Is that something that your function can handle too with some modification?
# re: A generic way to find ASP.NET ClientIDs with jQuery
by Kraki March 07, 2011 @ 5:26am
With the framework 4, you can also use the ClientIdMode to determine how IDs are set to elements.

Fore more details see http://msdn.microsoft.com/en-us/library/system.web.ui.control.clientidmode.aspx

The jQuery method doesn't work with extender (because they don't generate elements).
 


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2014