Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Data source controls shield the retrieval and interfacing of data from the display of that data. ASP.NET 2.0 provides all sorts of data sources, for example:

  • An SqlDataSource provides tabular data stored in an SQL database. A GridView or FormView can bind to (i.e. get data from) such a data source for displaying the tabular data.
  • A SiteMapDataSource provides hierarchical data representing the hierarchy of a website. A tree-control can bind to such a data source for navigating the website.
    In other words: data source controls relay data to other controls for display. Data source controls keep configuration details (database connection, type of database) out of the application code. Data source controls are usually invisible, because they are supposed to work in the background for an application.
    re-bind comes with its own set of data sources, and it is the binding from data sources to BOC controls that give re-bind its name. In contrast to most ASP.NET controls, re-bind provides two -way data-binding: data sources cannot only relay data to a control, but also modify data based on user input into the bound controls.
    re-bind expects data source controls binding to business objects to implement the IBusinessObjectDataSource interface. Currently there are two concrete implementations for this interface:
  • BindableObjectDataSource - provides data stored in a BindableObject for BOC controls
  • BusinessObjectReferenceDataSource - behaves like a data source towards a control; behaves like a control towards a data source (more about that in a minute)
BindableObjectDataSource

The BindableObjectDataSource is the bread and butter for every re-bind hacker, because the all-important BOC controls (BocTextValue, BocEnumValue, etc.) expect to get their data from a BindableObjectDataSource. A BindableObjectDataSource always knows the type (class) of object instance it binds to. After association of the data source with an instance, controls can retrieve property values from that object, or update properties based on user input. You don't need to look far to find examples for this. A BindableObjectDataSource is a regular staple on every re-call page/function generated by uigen.exe. If you look at EditLocationControl.ascx (part of the re-call page/function EditLocationForm.aspx) you will find this declaration for a BindableObjectDataSource:

...

In the illustration above, a Company object references a SpokesPerson object. For user convenience, the property values for the spokesperson - name and phone-number - are displayed on the same page as the company property values.
In this example, the page for display has two data sources:

  • the usual BindableObjectDataSource provides the property values for the Company object
  • the BusinessObjectReferenceDataSource tells that BindableObjectDataSource that it is a control (like a BocTextValue, for example) and needs the value stored in the reference property SpokesPerson.
    The BusinessObjectReferenceDataSource follows the reference to worm its way through to the two property values of the referenced object. These values are then provided to the controls on the form for display. When dealing with these controls, the BusinessObjectReferenceDataSource acts just like a regular data source for the controls that bind to it (Name and Phone, in this case). For these controls the BusinessObjectReferenceDataSource can transparently be used just like a regular data source (BindableObjectDataSource), complete with property paths.
    The beauty of this scheme is that no matter where the SpokesPerson property in the Company object points to, the BusinessObjectReferenceDataSource and the BindableObjectDataSource will always do the right thing and retrieve the corresponding values for the referenced spokesperson's name and phone-number.