Just discovered a "quirk" that I thought I would share in case anyone else runs into the same situation and becomes a perplexed as I did over the cause.
In a number of places in my ASP.NET 2.0 app, I am making use of the FormView control with a CslaDataSource. In the page, I use the state of the data-bound BO to determine if we are creating a new object or editing an existing one and set the FormView's mode accordingly. What I struggled with was none of the FormView fields seemed to be set to the default values defined in the BO's properties.
For example, my Contact BO has a PreferredContactMethod property that is of an enumerated type. The default, set to the private variable backing up the property at instantiation, is ContactMethod.Any. When I bind the FormView to my Contact BO and put the FormView in InsertMode, the drop-down list I have displaying the enumeration values that is bound to the BO's PreferredContactMethod does not appear set to the Any item.
I witnessed this same behavior in other controls bound to properties that had a default value set in the BO.
So, as part of my trial and error process, I decided to pull a fast one and instead of setting the FormView to InsertMode for a new object, I reused EditMode. And, viola! Everything bound!!!
A little closer examination and I discovered that even though the data-binding related events occur (FormView_DataBound, for instance), the FormView is not actually binding to the BO.
My thought is that MS created this behavior intentionally. Afterall, if we were using the SqlDataSource, they would be no record in the database to bind to, so the thought of needing default values wasn't considered. This is definitely unique to the CslaDataSource because we expect to have a BO as our data source so if that BO has default values set for any of it's properties, I at least, assumed that the FormView would reflect those values. That's not the case.
So, for me at least, now I have an explanation. I don't like the problem and don't agree that we should have to define our default values twice - I want them in my BO and only in my BO. Afterall, this means that my UI developer could decide he wants a different default value than what I have coded into my BO! Fortunately for me, in this application there is no difference between the InsertTemplate and EditTemplate, so I am able to simply remove the InsertTemplate and just use the Edit and ReadOnly modes for the FormView.
This latter decision also has the side benefit of simplifying the code-behind as well because originally we were handling the state of the object twice: once with the FormView to decide if we needed to call the FormView.Insert() or FormView.Update() methods. Now we only need one. AND, we can get away with this because even though we handled the CslaDataSource's InsertObject and UpdateObject events, they both did the exact same thing: call the BO's Save() method where we, of course, check the object's state to decide which CRUD operation to perform. Why do it inside the BO and at the FormView level? Redundant! So, the solution I was able to implement simplified this as well. So win, win.
Anyway, hopefully this will help anyone else who runs into this and saves you some time and gray hair.
This issue exists with the GridView and DetailsView controls as well. If you look at the current ProjectTracker (2.0.3+ I think), you'll see one solution that I picked up from the ASP.NET forums. It involves handling an insert event on the control, and manually copying values from your object into the UI elements.
It is relatively ugly, in that you need to get at the individual UI elements yourself, but the end result is pretty much exactly what you want - or at least what I was after.
Thanks SonOfPirate.
I just had exactly the same problem.and as my InsertObject and UpdateObject are pretty much the same I have combined them into the UpdateObject. I now just have the EditItemTemplate on my formview and change the settings for some controls that vary depending on Insert or Update in the FormView_DataBound.
As I had 25 default values to set this method seemed more elegant than the one in Project Tracker.
Copyright (c) Marimer LLC