When a Codebase Sucks There's Always JavaScript

In working on some inherited code in a very large and complex website I was a little bit skeptical of touching the code.  Let's just say the codebase was dubious at best.  This presented a problem as I had 3 days to make a lot of changes in the admin section of the site.  When inheriting code there is always a learning curve.  Unfortunately I didn't have this luxury as I spent 1.5 days getting the code running locally (still haven't COMPLETELY finished this).  This left me with about another half-day to learn the handful of tables I was to be using.  One day to actually write the code.  No problem. 

So the client relayed to the PM what needed to be done which was ultimately relayed to me.  "When a manager selects a value from the whatever dropdownlist the values for the FileUpload control disappears and the user has to re-enter this value (which is by design as this would be a huuuuge security risk. Think if you could programmatically set the postedfile for the FileUpload control!).  Different sections are displayed depending on the value of such-and-such dropdownlist, etc..." I then ask myself, "WTF are there so many postbacks to simply hide / show sections?"  This sounded  like a perfect opportunity to utilize my new favorite property: Control.ClientID.  The goal was to move the functionality from server-side to client-side while making minimal changes to the server-side code ( VB* ;-) ). Half of the dropdownlists had AutoPostBack enabled.  I expected to see a handful of handlers when I viewed the code-behind. Nope. Why is it that developers feel the need to always post back to the server even if nothing is happening? Maybe they were planning to implement the handlers in the future?  A postback is kind of a big deal and I believe they should be used sparingly, but that is just me.  Anyway, my server-side code consisted of maybe 6 lines where I added Attributes to server-side controls similar to:

dropdownlist.Attributes.Add("onchange",

   string.Format("clientSide('{0}', '{1}', this.value)",

   someDiv.ClientID, anotherDiv.ClientID))

With ClientID I am shoving the ID of the rendered control into my dropdownlist's onchange event so I can guarantee the control Id on the client-side.  This is extremely important since this particular site uses a series of nested masterpages and you can never be too sure what the output control id will be.  I then wrote some utility JavaScript functions to set CSS display style to "none" or "" depending on the values selected.  I also use client-side JavaScript to enable / disable appropriate validators (which is pretty cool).

ValidatorEnable("validatorId", false); // disable
ValidatorEnable("validatorId", true); // enable

It may seem like a bit more work solving problems on the client-side, but in the end it definitely makes the user experience more fluid.

* I have found that VB can be quite pleasant when written correctly.  I am not the definitive authority on correct programming but I'm pretty sure immuting a string object while enumerating an ArrayList with a series of nested if statements and for loops is not the correct way to display SQL data in tabular form.  I also can't think of a good reason to have 400+ lines in Page_Load. These practices aren't language-specific and would probably piss me off in any .NET platform.