Sunday, March 20, 2011

cDataSource object model

Recently I've begun re-implementing the cControl_Binder / cControlChild_Binding classes (under the moniker cControl_DataSource.

My initial thoughts about the implementation:

  • The DataSource object should be a separate control which maintains an active "data source" (thus far, a DAO.Recordset).

  • The DataSource is manipulated by it's bindings. The data source itself does little more than maintain a SQL query used to generate the recordset.

  • Bindings may be "parameter" or "field" bindings. Parameter bindings have a source control value which, after it updates, causes the binding to write the value to the appropriate QueryDef Parameter object. Field bindings are identical to parameter bindings, except they update a recordset field rather than a querydef parameter.

  • The bindings have a delegate function that is assigned to the source control's AfterUpdate event. This delegate function writes the control's value to the target parameter / field.

  • The data source itself has a delegate function which handles the requery. This function is assigned to each binding source control's AfterUpdate event. The source control's requrey delegate callback must follow all binding delegate callbacks. In the case of the parameter binding, the data source must execute a requery (build a new recordset). In the case of a field binding, the data source need only refresh .

  • The cDataSource control class works with iDataSourceControl objects. This interface supplies a Value property, an AfterUpdate cControlChild_Event object, among others.

  • The requirements of the cDataSource control class suggest it would be better to combine the cControl_EventHandler class into the cControl class. Don't know if that's the route I want to go just yet.

Anyway, that's about where I'm at. This implementation is proving to be more robust and flexible than the cControl_Binder implementation in Alpha 0.

1 comment: