Client side devevelopment in ASP.NET

We ASP.NET developers know how much of a pain it is writing javascript in any app we have today because of naming container madness! You've probably done something like this:

function DoSomeThingCool() {
    var textBox = document.getElementById('ct100_contentplaceholder1_TextBox1');
}

or something not so hardcoded

function DoSomeThingCool() {
    var textBox = document.getElementById('<%= TextBox1.ClientID %>');
}

Matthew Osborn, QA on the ASP.NET team has a great post on a new ASP.NET 4.0 feature that gives developers more control over how ClientIDs are generated.

9 Comments

  • Doesn't the ScriptManager help with this?

  • That is a good idea. Before ASP.NET 4.0 though I like the way some of the AJAX Control Toolkit Extenders used a BehaviourID, which was an attribute that did not change dependant on the container, and target for client code.

  • I gave up on asp controls for client side ages ago. The only control I use is the script manager to easily obtain my .asmx proxy stubs, and asp content placeholders if I'm using master pages.

    The remainder of my client markup is pure xhtml. If I need to reference a client control from my serverside code, which is rare then I just set runat="server". E.g.

    The ASP.NET 4 ClientIDMode looks like a great improvement but I still haven't found any compelling reason to use the tags instead of standard xhtml tags.

  • Yeah I feel also somewhat biased against asp.net controls, sometimes easy and quite good, and OFTEN a pain in the ass!!!

  • ASP.Net MVC still seems like a pretty lackluster effort on the part of Microsoft. In this example

    Lets say you want to refactor Person. No Refactoring tool will pick the changes up because its defined in a string and your code will still continue to complile. Only at runtime will you find your error.

  • Well thats true for asp.net in general not just mvc. The markup and code behind are 2 different worlds. You can use an ms build task to help rectify this. Check out scott gu's post on the MVC RC http://weblogs.asp.net/scottgu/archive/2009/01/27/asp-net-mvc-1-0-release-candidate-now-available.aspx and look for the section titled:

    MSBuild Task for Compiling Views

  • Thanks for sharing this! This is another reason to look forward to 4.0 (besides Linq to Entities perhaps actually working!) LOL

  • That's what I used to do before I knew better. Now I have a server class called JavaScript which writes it for me and I use RegisterClientScriptBlock().

    It's still a mystery why I need to do that for every postback including the Ajax ones.

    You could always use Script#, which I'll do when I need to write my next bit of complex client code.

    As for the MVC to come - useless telling me about it unless I'm going to use it and I won't be using for any existing sites I'm maintaining.

    But we could always start coding java, use GWT and never write another line of Javascript in our lives - that's surely the easiest solution? I wish Microsoft would just copy GWT.

  • @ Will Yea that works good for dynamic controls, but what happpens when you want to write your code in a separate js file? doesn't get processed anymore.

Comments have been disabled for this content.