I just spent a good portion of the day tryoubleshooting why we were getting this javascript error in out prod environment, but not in our development environment.  Specifically, the error was happening with a Telerik Popup control, but judging from a few google searches, I think that it is more specific to the ASP.Net Ajax extensions.

There a probably quite a few different causes of this problem, but I was able to fix it by removing the <xhtmlConformance mode="Legacy"/> node in my web.config file.  The xhtmlConformance setting appears to determine how controls render to the clients browser. The default is transitional.  It does not seem to play well with the Asp.net Ajax extensions if you have it set to legacy.

 UPDATE:
Looks like Scott Guthrie has already posted a gotcha on this.  Amazing that a google search for the error wouldn't pull it up.

I came accross a pretty good post on refactoring today on Basildon Coder.  The post offers some sound advice on when and how to refactor code.  I found the following paragraph quite insightful regarding completely rewriting existing code. 

"The problem is that warty old code isn’t always just warty - it’s battle-scarred. It has years of tweaks and bug-fixes in there to deal with all sorts of edge conditions and obscure environments. Throw that out and replace it with pristine new code, and you’ll often find that a load of very old issues suddenly come back to haunt you."

All too often we come accross code we don't like.  I've come across some real gems in my career, and I am positive that I have created some truly horrible code in my life.  I think that the first reaction that we have when we see ugly code or poorly designed systems is to push for a complete rewrite.   This is a normal reaction, but I think that a complete re-write should really only be used as a last resort.  It will always be a bigger task than it initially seems.  The best choice, and often more challenging is to figure out a way to refactor the problem code.

This has to be one of the coolest things I've seen in a while.  Chris Thrash purchased a Rock-A-Fire-Explosion  stage and apparently holds auctions to program songs into it.  I can't imagine the amount of time that it would take to meticulously program all of those movements, but the end result is very cool.  Check out the video below.

I look forward to more songs from this guy.

I stumbled across a funny VS.Net ad parody while surfing reddit.  If you read MSDN Magazine, you should be all to familliar with this advertisement.  The author switched the before and after photos and provides an amusing commentary on what happened.  Click Here to see the post.

This is my recursive FindControl function.  It works just like the standard findControl, only it doesn't return null if it doesn't find the controlId in the first child, it searches all controls in the heirarchy.  There are performance implications of using a recursive find... which may be why the standard findcontrol functions don't do this.  So I wouldn't use it everywhere.  In any event this works for me.  

Click below to download.

RecursiveFind.txt (1.15 kb)

   1:          /// <summary>

   2:          /// Finds a control within the control paramter

   3:          /// </summary>

   4:          /// <typeparam name="T">Expected control returned</typeparam>

   5:          /// <param name="control">parent control</param>

   6:          /// <param name="controlId">child control id</param>

   7:          /// <returns></returns>

   8:          private T recursiveFind<T>(Control control, string controlId) where T : Control

   9:          {

  10:              T foundControl = null;

  11:   

  12:              if (control.ID == controlId)

  13:                  return (T)control;

  14:   

  15:              foreach (Control childControl in control.Controls)

  16:              {

  17:                  if (childControl.ID == controlId)

  18:                  {

  19:                      return (T)childControl;

  20:                  }

  21:                  else //check child controls

  22:                  {

  23:                      if (Controls.Count > 0)

  24:                      {

  25:                          foundControl = recursiveFind<T>(childControl, controlId);

  26:   

  27:                          if (foundControl != null)

  28:                              return foundControl;

  29:                      }

  30:                  }

  31:              }

  32:   

  33:              return foundControl;

  34:          }

Jeff Atwood recently blogged about XML as "The Bracket Tax".  Jeff usually has some great observations, however labeling XML as a "Bracket Tax" is a bit rediculous. 

"Everywhere I look, programmers and programming tools seem to have standardized on XML. Configuration files, build scripts, local data storage, code comments, project files, you name it -- if it's stored in a text file and needs to be retrieved and parsed, it's probably XML. I realize that we have to use something to represent reasonably human readable data stored in a text file, but XML sometimes feels an awful lot like using an enormous sledgehammer to drive common household nails."

The reason why people use XML is because its a proven standard.  Every modern language has an XML parser.   XML is not used because its "efficient", it's used because its a farily safe bet that most developers will know it and also because its pretty widely supported... Almost every language and framework has an XML parser.    

XML as a language is more than just angle brackets and self describing data, XML offers extended functionality such as XPATH for querying, XSD for schema design and validation, and let's not forget the mighty XSLT for transforming documents.

Contrary to some opinions, XML is a very successful language.  Efficency zealots can go ahead and use SSYN for passing data, ConfigObj for their ini files...  But think about who will eventually be maintaining your code... you think they'll know JSON, SSYN?  Maybe... but my money says thay will know xml.

**Update 6/25/08**
Apparently I wasn't the only person who disagreed with Jeffs post.  He has posted a clarification to his position.  View it here.