Scott Allen asks: in your code-behind, do you prefer Page_Load or OnLoad? Those who read my article on “remastering” web forms know how uneasy I feel about the template VS.NET dishes out when you create a new web form.
Take Control of Initialization
These days, whenever I create a new form, I skin it to this:
using System;
using System.Web.UI;
namespace Playground
{
public class WebForm1 : Page
{
override protected void OnInit(EventArgs e)
{
base.OnInit(e);
}
}
}
I have a good reason to remove InitializeComponent (see default template) and move event wires-ups into OnInit. The culprit here is VS.NET. Suppose you have a couple of controls with their events wired in InitializeComponent:
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
this.Button1.Click += new System.EventHandler(this.Button1_Click);
this.List1.SelectedIndexChanged +=
new System.EventHandler(this.List1_SelectedIndexChanged);
this.Load += new System.EventHandler(this.Page_Load);
}
I don’t know what happens, but at times, when you remove some control, then add another one, etc, VS.NET quietly gets rid of wired events. The compiler won’t report it, because—technically—it’s not an error, but your controls won’t function. It’s very embarrassing.
Since there hasn’t been a single service pack for VS.NET, I do not trust it. Fool me once—shame on you, fool me twice… Therefore I move event where VS.NET won’t touch them and wipe out InitializeComponent:
override protected void OnInit(EventArgs e)
{
this.Button1.Click += new System.EventHandler(this.Button1_Click);
this.List1.SelectedIndexChanged +=
new System.EventHandler(this.List1_SelectedIndexChanged);
this.Load += new System.EventHandler(this.Page_Load);
base.OnInit(e);
}
If you leave page initialization in the hands of VS.NET 2003, you’re playing with fire.
OnLoad or Page_Load?
Scott has described pros and cons of both. To me, the way the template is set up right now is odd. You override Page.OnInit, but wire an event handler for Page.Load and end up with different method signatures. The Control class also has a PreRender event, but we’re always taught to override OnPreRender. All OnXxxx methods do is call wired handlers of their respective events. There’s not much more to it.
For the sake of consistency I choose to override OnXxxx methods. It’s only a matter of personal preference.
Do You Wire Events in HTML Designer or Code-Behind?
Suppose you have a simple Button control. You learn from books to set up its Click handler right in the HTML designer:
<asp:button id="Button1" Runat="server" OnClick="xxxx" />
Again, it’s a matter of personal likes and dislikes, but in my book doing so is impractical. These definitions are hard to maintain, and you do not get compile-time error resolution should you type something wrong. Another issue with this—VS.NET again. It shuffles attributes back and forth without warning, so control declaration is not guaranteed to stay the same. Do it at your own risk.
Do You Even Need Page_Load?
If your page is mainly static or has view state turned off, do you really need Page_Load? If not, get rid of it and reduce visual pollution.
A General Note On Localization
One of the reasons I leave ASPX markup free of event handlers and other logic is awkward localization. If you ever tried to present DataGrid’s header text in multiple languages, you’ll know the pain—it’s next to impossible without building the whole grid in code-behind and filling its headers with resource strings. Other controls follow suit. It’s plain messy to inject localizable text into ASPX markup.
Where Are the Templates?
VS.NET does a fine job scattering page and class templates all over the hard drive. Those cryptic configuration files with GUIDs and other mythical entries aren’t very friendly. I’m hoping in VS.NET 2005 it would easier to add my own templates (like the one above) to the lineup.
Conclusion
I merely presented my opinion on a minimalist template skeleton in this post. I’m surely not criticizing anybody’s approach. I always prefer code-behind to markup because I’m a control freak: I want a debugger, IntelliSense, compile-time checking, etc. “But in 2.0…” I know, I know.