Here is a challenging question, as I have not found any suitable information on this after two days of searching:
Background:
I have a custom Business Class library that includes custom objects with nullable int and DateTime properties. In order to update this data, I have created a FormView control bound to an ObjectDataSource that retrieves a generic List collection of my business objects. The reflection that is intrinsically called by the FormView/ObjectDataSource combination dutifully builds my basic Select, Update, and Insert templates. Now, when you edit the various (TextBoxes by default) input fields and then call the Update method referenced in the ODS (ObjectDataSource), the ODS attempts to convert the data contained in the input fields to the corresponding Type of the property bound to said input field. This is where we run into our little problem...
Even though I have a nullable Integer property type (let's call it int? ClassNumber), if the corresponding TextBox is empty (since it's not required), an exception is thrown by the ODS since it tries to convert an empty string value to an integer value before trying to set the object's Property. Hah! If ODS was able to determine that the integer is in fact nullable, it should pass in a null value instead! But alas, it throws a System.IndexOutOfRangeException: "Index was outside the bounds of the array" error. And further down the stack: "Exception: is not a valid value for Int32". Hmmm. Since this is a FormView control, we don't have the ability to use a BoundField control with 2 very useful properties: NullDisplayText and ConvertEmptyStringToNull. It would be nice to tell ODS to enable sending null values from any control we want. I wonder, can a TextBox control be extended to implement those two values? But I digress...
I suppose I could use the UpdateButton_Click event handler to evaluate the TextBox (or whatever) input controls in question and if the value is empty, input a default value (like zero), but this has Business Rule implications as well as invalidating the reason for using nullable types in the first place. Since I am creating my global Class Library as flexible as possible for use in many different web/desktop/whatever applications, I don't want to start implementing a hundred specialized case handlers, like if the int? value == 0, set it to null, because what if in other cases, 0 (or -1 for that matter) is perfectly acceptable? Once again, the reason for nullable types. Since I know that other developers may very well use a FormView with an ObjectDataSource, it might be handy to provide a custom (extended) FormView, textbox, or ODS control that can handle null values. Unless I am totally missing something else. DetailsView isn't template-able for Updating and I don't like updating from a GridView if there are a lot of fields. DataView is a pain, too.
Does anyone have any better suggestions?
Thanks,
Joel