Wednesday, February 24, 2010

IE8-Fix: Disabled select not showing selected options

In this post a small workaround for disabled select not showing selected options in IE8. It's probably not the cleanest fix, but it get's the job done.

Problem

A disabled select does not highlight the selected options.

   1:  <select size="3" multiple="multiple" id="mySelect" disabled="disabled">
   2:      <option selected="selected" value="Option1">Option 1</option>
   3:      <option selected="selected" value="Option2">Option 2</option>
   4:      <option value="Option3">Option 3</option>        
   5:  </select>  



Solution

The following CSS provides a workaround. It looks pretty similar to the appearance we are used to.

   1:  select[disabled="disabled"][multiple="multiple"]{
   2:      background-color:#D4D0C8;
   3:  } 
   4:   
   5:  select[disabled="disabled"][multiple="multiple"] option[selected="selected"]{
   6:      background-color:navy;
   7:  }  



Still not working?

Make sure you are using a transitional doctype.

   1:  <!-- DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" -->

You can also try to force the compatibility mode.

   1:  <meta http-equiv="X-UA-Compatible" content="IE=8"> 

Disclaimer

I tested this on IE8, FireFox and Opera.

Better fix?

Please let me know!

Monday, February 22, 2010

Book review: Object-Oriented JavaScript

Although I've made my feet wet with various JavaScript frameworks, I am not a JavaScript hero at all. This might be one of the disadvantages of being a WebForms developer and having great toolkits at hand like the AJAX Control Toolkit and Telerik RADControls.

Because you really can't call yourself a webdeveloper without having some understanding of JavaScript I decided to order Object-Oriented Javascript by Stoyan Stefanov.

This book really handles the language itself. The first chapters handle the basics: Types, loops, functions and objects. Although these concepts and the syntax resemble C#, JavaScript is a total different beast. After covering the basics, Stoyan goes deeper into OO JavaScript with Prototype and Inheritance. Then he shows the Browser Environment and he finishes the book with Coding and Design patterns.

All these concepts are accompanied by a ton of easy-to-read examples. After every chapter he also gives you some homework, because you learn coding by coding. After finishing this book you can also use the excellent Appendix for your reference.

I thought this was a great and very complete book. Definitely one of the best software books I've read in a while.

Get the book here (Amazon).

Monday, February 15, 2010

Webforms lessons learned the hard way (Part 2)

If you missed part 1, you can find it here.

Use the built-in goodies

ASP.NET Webforms has a lot of good stuff built into it. Do your homework before you start building the next big Webforms thing! A perfect example of this is ASP.NET Membership. ASP.NET provides an out-of-box membership solution. I've seen people who were to lazy to do some research or thought they could do better and ended up with a solution which put its doors wide open to people with bad intentions.

When a feature doesn't exactly match your needs, try extending it. The ASP.NET team are artists as it comes to writing solid extensible frameworks. I'd like to point to ASP.NET Membership again. You can write your own provider, which integrates with ASP.NET seamlessly.

Move as much as possible away from your page

Separating the businesslogic and data-accesslogic from your presentationlogic positively affects the quality of your page and code-behind in so many ways.

One of the big drawbacks of Webforms is that testing your pages isn't easy. That's why it's important to keep the quantity of code in the code-behind as low as possible. Code outside your presentationlogic can easily be covered using unittests.

Dividing your webapplication in multiple layers also makes the code in the page and page-behind easier to grasp (encapsulation etc..).

Let others do it for you

Because most of the ASP.NET Server controls are easy to extend, there a lot of third party control vendors out there.

I've only been using the Telerik RadControls for a few months now, and using this control suite, made my life so much easier. 1000$ might look like a big investment, but you can't believe how many time it has saved me. Especially the RadGrid control is a great time-saver. Binding a list of objects to a RadGrid, and finding out sorting, paging,.. just works is awesome.

What are some of your Webforms lessons learned the hard way?

Sunday, February 14, 2010

Webforms lessons learned the hard way (Part 1)

I've been spending a lot of my days in Webforms the last two years. In this post I want to share some best practices I've learned the hard way over these years. A lot of MVC developers might think this post comes a bit late (who still cares about Webforms?!), I do think (in the real world) a lot of the ASP.NET developers are still using Webforms. This post is directly targeting them.

Keep your pages light

There are a few things where you should pay attention to.

Most of the times the Viewstate is the number one performance killer. Although most developers know storing a lot of ViewState on the page has issues, and that there are numerous alternatives. Most developers don't take the time to think about the Viewstate. I don't blame them. Persisting the ViewState to another medium is not as easy as it should be. The Viewstate is enabled by default, disabling the Viewstate on each control is a hassle.. In ASP.NET 4 the ViewStateMode will make it much easier though. Once the users start complaining about performance, you are too late. I really encourage you to start thinking about the Viewstate as early as possible. Only use it when you need to persist changes across Postbacks. You will be surprised how little you really need to persist.

A Masterpage is great for applying a consistent style to your pages. But be careful with what you put in the head tag of your Masterpage. Often you only need a certain stylesheet or javascript library in a few pages. Avoid including references to these stylesheets and javascript libraries in your Masterpage. Better is to put a ContentPlaceHolder in the head tag of your Masterpage and use that for your conditional resources.

Updatepanels are great controls, but you should apply them wisely. Don't blindly wrap your whole form in an Updatepanel. Think about which part of your page really needs to be refreshed. The less HTML and ViewState (!) coming back from the server the better.

Use javascript. I think to many Webforms developers are uncomfortable leaving their serverside habitat. Avoid a postback whenever you can. That's one of the rules I try to apply.

Stay away from the designer

Creating pages using the designer doesn't work on so many levels.

The Design view doesn't always give a correct representation of how the page will look like when it's rendered by the browser.

Using drag-and-drop, databinding wizards.. does not end well. I have a big problem with defining datasources in the ASPX markup. In my opinion the ASPX markup should be as clean as possible. It should serve as a view, and as a view only. Another downside of defining your datasources in your ASPX markup is that your application tends to be more fragile.

Let me prove this by this example..

In this example I'm binding a List of FireStationEvents to a GridView. Notice the TypeName and SelectMethods are strings.

   1:  <form id="form1" runat="server">
   2:      <div>           
   3:          <asp:GridView ID="gvEvents" runat="server" DataSourceID="odsEvents">
   4:          </asp:GridView>        
   5:      </div>
   6:      <asp:ObjectDataSource ID="odsEvents" runat="server" 
   7:          SelectMethod="Load" 
   8:          TypeName="WFDemo.BusinessLogic.FireStationEvents">
   9:      </asp:ObjectDataSource>
  10:  </form>


A few weeks later I decide to change the methodname Load to LoadAll. I rebuild and all is good. I publish my site to production, and a few hours later I get a critical bugreport assigned to me. After looking into it, I discover I forgot to change the SelectMethod property of the DataSource. Loading the page throws an unhandled Exception at runtime: ObjectDataSource 'odsEvents' could not find a non-generic method 'Load' that has no parameters. One small refactoring made the application fail big time and I didn't even have a clue.

Stay posted for Part 2 tomorrow! What are some of your Webforms lessons learned the hard way?