hcOPF Object Bindings

Binding an object graph poses a few challenges.  Namely that an object may have children including lists, and if a parent object is refreshed, the child lists may have a different number of items and each item is a different object instance.

hcOPF uses an MGM pattern supporting design-time bindings.  The core component in this mechanism is the ThcUIObjectBinder.  At design-time the developer populates a collection of ThcUIBindingItems that specify the MediatorClass, and the bound Control.  Additional properties may be specified that are dependant on the class of the mediator, such as the attribute name if the mediator is a ThcAttributeMediator descendant.

At run-time, when the ThcUIObjectBinder has been streamed in from the DFM, it’s Loaded method gets called.  The binder checks that all bindings are correct by calling the Mediator’s IsValid method.  If one or more bindings are invalid, an error message will be displayed and the program terminated.  This prevents scenarios like in typical Delphi apps where a field name changes and nothing shows up in the db-aware controls.  No error is raised, so the developer has no idea that the form is not working as expected unless they happen to notice the absence of display item.

Immediately after the Mediator’s Loaded method, the Initialize method is called.  While this method is not currently used in hcOPF I felt it might be of some valid for initializing controls using values from the database, and that is why it takes a FactoryPool argument.

The Mediator’s Bind method is then called.  This method is used by ThcObjectLists and descendants who bind to their controls using a complex mechanism.  Simple attribute binding is accomplished by pairing the control to the attribute in the mediator which is accomplished by the streaming system, followed by setting the mediator’s Subject and calling Mediator.Bind() which is done by the ThcUIObjectBinder.

Now that I’ve spent a great deal of time on Object Binding, EMB has introduced LiveBindings.  After I get some time to evaluate that technology I might add support to hcOPF for LiveBindings.  Time to listen to the CodeRage presentations…

Tags: ,

2 Responses to “hcOPF Object Bindings”

  1. Ron Says:

    Do you use copious amounts of magic strings in your bindings? My gripe with LiveBindings is that when you change a property name in your class all the live bindings code has to be checked by hand because property names are set using string values.

  2. Larry Hengen Says:

    @Ron,

    Object Attribute Names are used in my bindings the same way FieldNames are used in normal TDataSet/TDataSource bindings. The difference is, I have coded checks to ensure that if an attribute cannot be found because the name was changed or the attribute was removed, the developer gets an error message rather than a blank control.

    hcOPF bindings use the MGM pattern and all transformation logic, is performed by the ThcCustomMediator descendant classes. This means if you want to do something specific, you have to write a new mediator, register it with the IDE, and then create the design-time binding. If you want to do it in code, you don’t have to install a package with the mediator into the IDE but that limits the re-usability of the mediator.

Leave a Reply