Event Handler Declarations in Whidbey
Teemu and Andy have started an interesting discussion about event handler declarations in ASP.NET Whidbey, particularly relating to VS/VWD 2005. Since I originally voted on the bug report that started it, I thought I'd chime in with further clarification for my part.
First of all, I think I may have misunderstood what Teemu was saying when he directed me to the bug report. I was under the impression that it was stuffing the actual handler methods inline in the ASPX (in a server-side script block) instead of in the code separation file. Since I'm lazy (err.. efficient), I haven't bothered actually testing it out. :) I hope we can all agree that this would be a bad thing, and that's what I was thinking when I acquiesced and voted. I still think the report indicates that, but based on Andy's comments, I'm not so sure.
Anyways, I would still suggest that the designer can only be responsible for the initial declaration, i.e., where we first say "hey, I want to handle x event for this control." At that point, it knows exactly where in the control hierarchy that the control is, so it should be able to correctly attach the event in code for us.
Typically, we are talking about a top-level control, so it's a simple matter of myControl.MyEvent += new MyEventHandler(this.DoMyEvent); in the OnInit method (or Handles myControl.MyEvent, if you prefer). However, let's say it's in a repeater template. In that case, it can create an ItemCreated handler in which it attaches the appropriate event handler in code for each item. In any case, if you move the control in the hierarchy after the fact, I don't think the designer should adjust it for you (simply because I tend to think it would screw up).
Having said all of that, the ASP.NET model has grown ever more towards putting controller code into the ASPX tags with this new version. I used to be something of a purist when it comes to separating UI design from control, but I think I have to move on, since that is the direction of things. More often than not, going with the flow makes your job easier, so instead of raging against the machine, I will just become one with the borg. After taking that plunge, it is easy to see that letting ASP.NET parse out my event handler hookups is the easier way to go. At least, if we can't agree on anything else, we should be consistent.