On Tue, 15 Sep 2009 10:44:40 am Greg Brown wrote: > > > DataContext does > > represent a row but it also can represent a single field in that > > row. It > > overrides toString so it can also be used in ListView/ListButton. > > That is an interesting approach. If it is not too much to explain, I > would be interested to learn more about how it works.
First of all I use business objects which abstract database tables/rows/fields into EntitySet/Entity/Attribute. But I will translate things to database speak. Also I am stating things you already know but the only way I can think through the process is to walk the pathways and describe them :-) DataContext has three roles; To represent a row in the TableView, to be an item in ListButton/ListView and to be bindable to a Form. Internally it keeps reference to a database table and the row index within that table. It also holds a defaultKey and defaultDisplayKey the last of which is used when toString() is called. When used with a Form, DataContext simply accesses the table/row using the given key with get() or put(). The only tricky thing it does is that it has the ability to transform field data to/from the data type the database field uses to the type the Form expects. These automatic transforms cut out a heap of boilerplate code. When bound to a TableView a DataContextList is required. This generates DataContext items and passes them as the row data. For read only TableViews DataContext provides the same data as for the Form. For editable TableViews DataContextList can be put into "dataItemMode". This then passes a DataContext that is also in dataItemMode as row data to the TableView. When in dataItemMode, the DataContext returns a new DataContext bound to a single field from a get(); Now for the ListButton. A DataContextList can be the listData for the ListButton. If the ListButton is part of a TableViewRowEditor then the DataContextList will have to be in dataItemMode. When the editor is invoked on a TableView row it grabs the DataContext for the row and then uses get() on that DataContext which returns another DataContext bound to a single field. This is then passed to indexOf() on the ListButtons' ListData which is different DataContextList. The DataContext from the TableView won't be in the ListButtons DataContextList, they may even have different database tables as sources. The DataContextList will match the DataContext given in the call to indexOf() to it's list of DataContexts based on the value defaultKey references in each DataContext. So it doesn't care if the field names are different, just as long as the values are the same. All that just to accommodate foreign keys ... sigh ... What a convoluted mess, but it works ;-)
