Code mangling’s always been a problem with ASP .NET — the VS .NET 2002/2003 used to mangle the HTML badly when you switched between design and code views, and while that’s been fixed in VS .NET 2005 (aka, The-Shiznit-For-Web-Development-2005), there’s still the problem of element name mangling while rendering. So, for example, a FormView element named FormViewElement might be rendered on the client-side as ctl00_ContentPlaceHolder1_FormViewElement.
Technically, it’s not mangling; VS .NET is qualifying the element name to prevent name clashes. Still, it’s irritating, because client-side Javascript can’t directly reference these elements, and finding them through some hack involving getElementByID() risks being broken if/when the format for mangling is changed. This guy ran into this problem, and the responses he got are fairly typical of the advice normally given.
The correct way to do it is to use the ClientID property of the control underlying the element you will be referencing. You can then form the Javascript at compile-time to accurately reference the rendered element.
So, for example, if you’re working with a FormView defined like this:
<asp:FormView ID="FormView1" runat="server" DataSourceID="DataSource">
On the client-side, this is rendered within a table something like this:
<table id="ctl00_ContentPlaceHolder1_FormView1">
To address this element, form and register your Javascript like this:
string js = "<script language='javascript'>document.getElementById('"
+ FormView1.ClientID + "').style.visibility='hidden'</script>";
Page.RegisterStartupScript("Invisibility", js);
Update: Bleh, use ClientScriptManager.RegisterStartupScript(...)…Page.RegisterStartupScript(...) has been deprecated.
Why go to all the bother of declaring a ClientScriptManager when you could just embed the following inside your own script block within the .aspx itself?
var MyField = document.getElementById(”<%= MyField.ClientID %>”);
I’m relatively new to ASP.NET, so I could be missing something here, but ClientScriptManager seems like an oversized sledge-hammer for a very simple job.
True… if you use code blocks. Don’t try to seperate your javascript into its own file. :o
Well, you can put the majority of the logic in a .js and expose it with a function that takes the id as input. Then you could use
var mydata = dowork(”<%= MyField.ClientID %>”);
But I digress because I dont like to use inline code blocks. Using the new client script manager has an advantage in that you can simple tell it to include the script elements instead of having to include them manually every time in your code.
Well I just set this in my JS like so:
But I’ve been very pissed off that MS did this. It would have taken very little effort to track the element IDs a diff way. Not only have they made it difficult to use getElementById (a staple in JS), but they hosed us when using #elementID in CSS. What were they thinking? Obviously they didn’t. Thanks Microsoft – way to backtrack
Sorry that didn’t convert over :
var menuID = “<%=MainMenu.ClientID%>_tblMenuBar”;