Posted by rbair
on June 28, 2004 at 2:24 PM PDT
Some thoughts regarding the current Binding implementation:
Binding is too narrow in scope. It only allows binding between a datamodel and a component. Why? Why not bind to anything? After all, the Binding is absolutely responsible for knowing how to change the component/object based on the current data anyway. So why limit it to components?
One good reason to consider binding to any object is that you could implement master/detail relationships between datamodels in this way. The master DataModel is bound by an MDBinding to a detail DataModel. When the master DataModel changes, the MDBinding updates the contents of the detail DataModel.
Different MDBindings can be created to do things such as: based on the fieldName, get a collection of objects from the master and put those objects into the detail; based on some RowSet, execute a query to get the detail items from a jdbc DataSource and put the results in the detail; based on the fieldName get a URL and open it, loading whatever is there into the detail DataSource. As long as the MDBindings have a simple API for people to extend (such as a single method, maybe two) you could easily provide any behavior you want. Shucks, a custom binding could open a connection to the datasource and save the user's selection as some preference if it wanted to.
Why is are the methods of this interface package private? Is getFieldName() even necessary?
There should be a read-only property on the binding. Some components/objects will happily display data, but changes in it shouldn't be propagated up. For instance, some MDBindings (such as the sql/rowset variety) don't want to ever push data back up to the master DataModel. On a related note, bindings should provide an enable/disable feature. This is handy in many cases (such as when data is not loaded into the DataModel, perhaps, or when the window is disabled because the data loaded in the model is read-only). It MAY propogate the enable/disable on to its bound object/UI component.