I’m not a big fan of ASP.NET. Classic ASP I’m pretty ambivalent to because it’s basically just PHP with VBScript.aspx) and/or JScript.aspx). ASP.NET MVC I actually like, because it actually functions in a web-sensible manner, and I can generate all of the HTML or other output by hand, or by whatever means I want. But the standard ASP.NET model is confusing and irritating to me.
ASP.NET was designed around the assumption that it would be used by Windows Application Developers who suddenly found themselves needing to develop for the Web. This is clear in that ASP.NET controls resemble in many ways the Windows.Forms controls found in .NET, particularly in their event handlers. They seem to be attempting to create state in a stateless environment, which is interesting, but serves as quite the anti-pattern to anyone who has ever done much work on the Web.
As I’ve talked about before, I’ve been working on an ASP.NET WebPart to be placed into Microsoft Office SharePoint Server 2007. Due to the final destination of the code, I really have no choice but to follow the ASP.NET Web Forms model, and I didn’t expect it to be that problematic, as I was merely converting a Web Part written (sloppily) for SharePoint 2003 to run on 2007. I probably could have just dropped the DLL into the new SharePoint, but we also wanted to add some additional security features, so we took the problem a bit further, and I’ve been trying to update the Web Part to compile against the .NET 3.5 Libraries.
As nearly as I can tell, this should have been a seamless upgrade. However, I’ve run into a few problems that are either bugs in the Microsoft code, or my own lack of understanding of the ASP.NET Page Life Cycle.
As nearly as I can tell, ASP.NET begins a postback by trying to rebuild the state of the page before the postback, running the event handlers, and then resetting up the page with the new state and rendering it. If I’m wrong about this, please let me know, but it really does seem like the most likely explanation for what I’m witnessing. This would probably be less frustrating if the initialization methods didn’t require special if blocks to handle the differences in execution paths between a postback event and a fresh page view.
Running on my assumption about ASP.NET’s execution flow, I’ve had a hell of a time nailing down two odd bugs. The first, centered on a DataGrid which was bound to a SqlRecordSet. We’d set the DataKeyField property of the DataGrid to “Id”, one of the values from the SQL statement, but one that was not bound to a column for display on screen. For some reason, the DataKeys member of the DataGrid simply wasn’t being filled in. I finally figured out that accessing the DataKeys.Count field right after the DataGrid.DataBind() function call seemed to fix this issue. Absolutely no idea why, as the Count field is read-only, and I don’t actually do anything with the value. But it worked, and frankly that was enough for that one.
The current issue that I’m having revolves around a DropDownList. The application is a fairly simple database front-end, not unlike what you could build with Microsoft Access. We offer three modes of search, but Student ID (which must be exact), Student Last Name (which can be partial), or Sport the student is playing. The application is used to help ensure that Student Athlete’s are meeting their NCAA requirements, hence the sports part. For some reason, when searching by student last name, or by certain (but not all, frustratingly enough), it becomes impossible to lookup any but the first student on the search results list. The search results are used to populate a DropDownList, which has its AutoPostback property set to true, so that a JavaScript event is fired whenever its value is changed. It defaults to the first student on the list, so data will always come up.
The problem that I’m having is that, save for a few oddball cases, the postback is happening, but the system is convinced that the DropDownList has no items, at least during the Event Handler which handles the DropDownList’s OnChange event. By the time the page renders, this list is populated again with the information it should have. Attempting to access the Items.Count property on the DropDownList immediately after population has failed to fix the issue this time. Though I’m okay with that really. It honestly bothers me that it worked previously.
I’m very, very close at this time to just looking in the Request.Form collection to pull the data that I need from there in the Event Handler, though I’ve refused so far in an attempt to properly follow the ASP.NET model. I just can’t help but feel that the standard ASP.NET Web Forms model is deeply flawed. Not only because it assumes a particular methodology, but also because it’s very difficult to debug these Web Parts because I can’t easily deploy a debuggable Web Part DLL, particularly when said Web Part depends on running within SharePoint, and would not likely run elsewhere.
If anyone can help me with this, please leave a comment. And if you’re a Microsoftie who happens to work on ASP.NET, maybe you can drop some knowledge on me and my readers about what the hell is going on in the ASP.NET execution pathway.