LiveBindings in Action, 1

Acknowledgement

The author thanks Damien Bootsma, who gave the proper impulse by his  post, as well as some good ideas.

LiveBinidings

gives a developer more freedom in binding objects. This is a principally new mechanism, which is not complicated at all. I think, most Delphi developers have no hard feelings in using primarily complicated component links like "Connection-DataSet-DataSource-DBAwareComponents". These links can be set both in run-time, and design-time, and of course some experience needed.

Just the same is valid for LiveBindings. If you have good examples and prototypes, you will feel new capabilities in creating really live bindings. The examples should be of practical values, rather than abstract. But first some abstract theory.

LiveBindings

is a mechanism to bind objects/components on the base of (text) expressions. There is nothing unusual and tricky. How do we establish links between some application and database? Using SQL-queries. A query is some "text" expression, which is then processed and help us to get data from the database to the application taking into account we can manage this text (static text in design-time, query with parameters, dynamically concatenating text in runtime.

Can we link the application and database without SQL command? Yes, we can, as we all used to use TTable. Everything was rather rigid, and after receiving data we processed it by procedural technique. Why did we stop this? Why SQL-based technology is dominant? Because it’s more flexible and universal (and many other things, that allow us saying "more technologically effective"). Do you miss TTable? May be, especially, if we create a desktop application with local file data storage.

Architecture

of the application, which clearly distinguishes "model" and "GUI", needs universalization of the bindings. The quality of the architecture is measured by its flexibility, and the very flexibility calls for flexible (or live) bindings. At minimum, these bindings should be localized in some isolated place in the project, and if we imply component-based IDE, there should be a group of corresponding components.

We all have many-year-habit to think in terms of rigid "links" (associations, bindings etc.) in the form of direct references compiled, which prevents us from easy use of LiveBindings, as it has various from the viewpoint of both components/classes, and combinations of possible values of properties. So let’s take a simple, but interesting project with elements of 3D modeling.

Setting the problem

represents graphically the following diagram below.

• Some object as a part of a model, which has a number of properties
• GUI
• Visual component for changing the object (red arrow)
• Visual component for visualizing the whole object (green arrow)
• Visual component for visualizing/changing the object property

Obviously, the bindings, marked by the arrows, have directions. Do you see here a place for LiveBindings with all its flexibility? I hope so, as:

• There can be a number of different visualization patters or models (spacial, projection on different planes, schematic etc).
• The visual components to control the model can be replaced depending on the interface metaphor/user requirements
• The model must be easy to be separated from the interface (for example, if we will then use the core of the system for calculations etc without GUI)

Implementation

is kind of "test-drive" for LiveBindings. Is it possible to use it for these purposes? Is it hard? And, of course, what are practical recommendations and tips?

To some extent this is a "text-drive" of LiveBindings intuitiveness, as I haven’t specially diven into theory, as I believe into the same model of common sense both creator, and user. I was specially interested into binding objects, which were not derived from TComponent or TControl. Plainly speaking, objects, which are stupid rude custom children of TObject. I’d like to keep you away from meditation, staring on the properties and their possible values, and will write some practical recommendation if you reproduce the example on your own.

Primarily we have an object MySphere : TMySphere, which has nothing to do with visual FireMonkey’s 3D TSphere. Let’s think MySphere is necessary to model some domain with some calculations. TMySphere doesn’t know at all, that there is something aside from maths.

Object Sphere1 : TSphere is a standard 3D ball. It’s a pity the class has no "LiveBindings" property, but our intention to bind it is so strong, that we’ll manage to make binding and in this case also.

edX : TEdit is a dual-purpose component, it can both change, and visualize the object’s property value (changing the X-coordinate, moving to the right).

Simple "button" provides the "old-fashion" interaction between objects by means of direct reference. To compare only.

MySphere (model object) and Sphere1 (visual object) are associated by one-direction binding, and as the objects are of "wrong genes", we will introduce them into the world of LiveBindings with 2 additional BindScope components.

edX : TEdit is a "good-pedigree" component, we don’t need BindScope for it, and we use its comonent name for bindings. The association is bi-directional.

How it works

Some "time-savers"

• LiveBindings can be established by clicks visually in design-time or can be coded, but in this case we used mix approach (which is rather typical for Delphi development); if we can, we use design-time, if not - coding for realization in runtime;
• The first made binding will live in the automatically added BindingsList; if you need second, just click on LiveBindings and then New->BindExpression;
• Two components are easy to link, numerous demos show that; right click, then New LiveBindings…;
• Bindings are easy to modify in Object Inspector;
• If you need to bind a simple TObject derivative, design-time is not good; use BindScope, which is visual, can be charged in design time for formation some LiveBindings; then you can modify it in runtime;
• Managed-bindings need direct notification (if you bindings don’t work, add more notifications in code);
• Bindings can be "from-source-to-control", "from control-to-source" or "bi-directional"; the meaning is self-explanatory (see arrows in the picture above or think arrows for your case);
• BindingsList, there you can find your bindings;
• Sometimes it’s better not to call for "wizard" in BindingsList, but simply find your bindings in the panel "Structure" and modify it in Object Inspector.

Comments

are useful, if they are in code.

Posted by Vsevolod Leonov on June 27th, 2012 under C++Builder XE2, Delphi XE2 |