History of the Sliding Doors Method and the HTML Button Element

About a year ago, the button element was rediscovered by Particletree as way to add consistency to your website's buttons.  A few months later the filament group took the button element a step farther with sliding doors. We really liked both of these articles and wanted to use them in our latest projects but we ran into a problem with the rendering of the asp:button control.   

The Problem with Standard asp:Button and Form Input Controls

 A basic asp:button control renders as an input element with type="submit" (<input type="submit" name="btnAddChoice" value="Submit" onclick="__doPostBack('btnAddChoice','');" />). In order to render our asp:Buttons in more flexible, skinnable way with sliding doors,we needed to alter the HTML output  of the asp:Button control to render like this: <button type="submit" id="btnAddChoice"  onclick="__doPostBack('btnAddChoice','');"><span>Submit</span></button>.

For more info on the benfits of sliding doors and the HTML button, please read the following articles:

• Rediscovering the Button Element
• Styling the button element with sliding doors

The Solution

We decided to write a Control Adapter to change the rendering of the asp:button to render as a button element. A Control Adapter allows you to override the rendering of any ASP.NET server control. The best part about using a control adapter is that it will render every asp:button the way that we tell it to; we don't have to rewrite any of our old asp:buttons. For more info on control adapters check out this post on Scott Gu's blog.

(Or insert your favorite Regular Expression enabled text editor here).
This is part one of a multi-part series of tools that we use to get the job done, whatever that job may be.
Oftentimes our work is not always "here's a spec, create it", but at other times that work is "here's an export of our database for you to work with". In an ideal world, we would like to receive this in something that is easily imported into a relational database., but more often than not we just get a straight "dump" (usually multiple CSV files) of the production data. The major challenge that we often face in this scenario is of how to maintain the original data integrity, and how we do it without blowing our budget. That's where using the regex replace functionality that is part of EditPlus comes in very handy.

Here's a sample of what the data dump might look like:

Where ID (the first column) might be the Primary key of the item on their system, and foreign keys always refer to different IDs than what's on your local system. At first this was impossible to do while keeping the data accurate, so I had to ask for the data that the foreign keys referenced. So now we're all set.  Read on for the solution