Practical ASP.NET

Displaying and Updating Dynamic DataBound Columns with ObjectDataSource

Peter continues his series on integrating cascading DropDownLists with databound controls. But this time, he looks at what's different when you're using the ObjectDataSource.

• By Peter Vogel
• 03/04/2009

"Databinding methods such as Eval(), XPath() and Bind() can only be used in the context of a databound control."

In the first column of the series ("Integrating Dynamic DataBound Columns with SqlDataSource"), I laid the groundwork for a solution and showed how to get the data to display correctly in both Edit and Insert modes with the SqlDataSource. In the second column ("Updating Dynamic DataBound Columns with SqlDataSource"), I looked at what you needed to do handle updates and inserts, again with the SqlDataSource. In this column, I'll cover the differences when working with the ObjectDataSource.

Displaying Data
As with the SqlDataSource, the first two steps are to: 1) remove the databinding from the DropDownList that actually displays the value from the DataSource, and 2) add code to the FormView's DataBound event to move the data into the control on the page from the FormView's DataItem property. With the Object DataSource, the DataItem must be cast to whatever object type the FormView is displaying. If the FormView is bound to an OrderDetails object, for instance, then you must case the DataItem to an OrderDetails object, as this code does:

Dim ordd As OrderDetail
ordd = CType(Me.FormView1.DataItem, OrderDetail)

After that, it's just a matter of working with the property on the object that the DropDownList should have been bound to. For my example, that's the ProductName property:

ddl.SelectedValue = ordd.ProductName 

Inserts and Updates
For inserts, the code for the ObjectDataSource is identical to the code for the SqlDataSource. For updates, the code is different and simpler for the ObjectDataSource: In the FormView's ItemUpdating event (which fires just before the update is performed), you just need to set the value of the unbound field from the DropDownList through the NewValues collection that's passed to the event on the e parameter. The three lines of code shown in Listing 1 do the job.

One Last Problem
Back in the first column of this series, I ensured that the value inserted into the DropDownList was in the list of values for the control by adding the value to the DropDownList's Items collection. There are at least three problems with that solution.

First, the value pulled from the FormView's DataSource will often be the "primary key" value for the data and not the text value that would normally be displayed in the DropDownList. For instance, for a list of Products, you'll find that you typically have the ProductId but not the ProductName -- and it's the ProductName that should be displayed in the DropDownList. Second, the DropDownList will now have an inconsistent list of values: Most of the values will be driven by the category DropDownList but the list will also have the one value you've added which will be from some other category. Finally, of course, the item displayed in the FormView will be out of sync with the category displayed in the category DropDownList.

A better solution is to force the category DropDownList to the correct category for the value in the DataSource. Essentially, the process is to use the "primary key" value retrieved through the DataSource to retrieve the complete record. Once that record is retrieved, you can use data from it to set the current value in the category DropDownList. The final step is to refresh the DropDownList so that it's filled with the matching values from the category DropDownList.

In my case, because I use the Factory Method pattern to return Lists of my business objects, typical code looks like Listing 2 (in this example, the category DropDownList is called DropDownList2).