Cascading DropDowns w/ JQuery ViewState Problem - use the UpdatePanel w/ triggers instead

I spent a lot of time trying to resolve a DOM issue I was having with a cascading drop downs setup on my page.  After mucking around with it for quite a while, I was able to figure out that it wasn't a direct effect of my code, but seemed to be a result of some DOM corruption that was happening from a plugin I was using or something else (that would be very time consuming to uncover).

I was making a web service (POST) call to update the 2nd drop down list...

if ($(someDDObject).val().length > 0) {
    someGlobalVariable = $(someDDObject).val();
    ExecuteCallback('DoneChanged|' + someGlobalVariable);
}

The ExecuteCallBack is tied to a server-side async, non-static function that would parse the input and return the updates. A nice clean way to get server-side data without a postback, right? Right...mostly.

The problem came in trying to update the client side data. In the callback function on the client, I would process the data like so:

function CallBackResult(arg, context) {
// The server side has already bound the new list, so now we do it client side with old fashioned parsing
   if (arg.indexOf("DoneChanged") != -1) {
      var args = arg.split(":");
      var somethings = args[1].split(";");
      $(otherDD).html("");
      $(otherDD).append($("-- Select something! --"));
      $.each(somethings, function (i, v) {
         var details = v.split(",");
         if (details[0].length > 0 && details[1].length > 0) {
    $(otherDD).append($("" + details[1] + ""));
         }
      });
      $(otherDD).show();
   }
}

...which was all well and good.  I now had one drop down list that directly updated the data for the other drop down list.  However, when I reset the 2nd drop down list (all of this client side, with out post backs) like this:

var first = $(otherDD+ " option:first").val();
$(otherDD).val(first);

...the first drop down list was reset to whatever the server had decided was the "selected" value. Meaning, the selection from the first should have placed the "selected" attribute on that item, but it never did (I presume b/c I did not do a post back), and not only that, but when I reset the 2nd drop down, the 1st was reset as well.

Not to give up so easily, I spend waaaayyy too much time digging into this anomaly, and was left to conclude that somehow the viewstate got corrupted (anyone with insight into this, feel free to let me know!).

Solution:

I tried to avoid using the update panel b/c I was trying to go (nearly) strictly javascript for server/client updates, but after watching a nice video here, I gave it a whirl.  Took me 10 minutes to implement and it worked beautifully the first time I tried it.

The obvious moral here is that I need to be more flexible in my web programming and take the best of whatever technology is available to me to fill my needs. If I'm banging my head over something for a couple of hours, it may be well worth my time to look at other options.

In short, sometimes it pays to not doggedly follow one technology (JQuery) over another (ASP.NET). Jquery is an amazing enhancement to javascript and web design in general, but it still requires very careful programming, which usually means that one or more plugins you try to use can have adverse side effects. ASP.NET, on the flip side, seems to offer more 'hands off' programming at the expense of tweaking details and really being able to dive into the control/plugin like you can with javascript.

On a side note, the asp.net UpdatePanel, if used properly, results in a partial post back that really does not impact performance very much. If used sparingly for specific needs, it can be a very powerful tool (as it is for this little page) especially when coupled with an asyncpostbacktrigger.