I've just finished up my largest ASP.NET effort to date.   It's nothing huge, but I tried to use standard ASP.NET patterns and practices throughout.   I learned a number of lessons!

We turned off ViewState in order to save bandwidth.   This introduced some problems that I didn't expect.   For one thing, the IsPostback property can't be used for deciding whether or not to databind - always databind!   Since the web is stateless, the values involved in a bind are usually stored in ViewState so you only need to bind once.   Clearly you need to do that manually without it.

That made sense, but what I didn't expect was the lack of many of the events.   A simple button Click event still works, but change events and certain other control events simply don't fire since the runtime doesn't know anything but the current state.   Unfortunately, there is no hint to this in Visual Studio so you'll just have blocks of code that never get hit and you won't know why!

Another lesson I learned was about validators.   I like using RequiredFieldValidator to make sure that text fields are filled in.   For some stupid reason, the ListView has no built-in support for this.   I'd love to be able to just click a €œrequired € checkbox for a field and have it add it.   What I learned though, is that even if I add the validator manually, there are two huge gotcha's:

First, if the user clicks the Cancel button for an edit, the validators still fire!   The fix is quite simple - just set CausesValidation to false on the button and you're ok.   Why wouldn't those buttons be auto-configured for this behavior when auto-generated though?   It doesn't have a downside if you set the property and don't have validators.

My second problem was harder to solve.   In addition to creating validators on the EditItemTemplate, I also added them to the InsertItemTemplate.   Obviously the fields are required on both update and creation.   What I learned though, was that when the user attempts to edit an item, there are now two sets of fields on display at once: new item and edit item.   This is bad when the user tries to save the edited record though, as the new item validators complain about empty fields.

The solution is to hide the insert row on edit.   When the control fires the ItemEditing event, you change the InsertItemPosition   to None, then on the Canceling or ItemUpdated events change it back to LastItem.   This looks cool and prevents two sets of controls from being on-screen at once.   Again though, this isn't that uncommon of a scenario so it should be handled easier.

It seems like so many of the ASP.NET features work great in demos, but once you get into the real-world scenarios you need to do more work than expected to really bring things together.