Thursday, January 12, 2012

What’s Your Favorite LiveBindings Example?

LiveBindings, which were introduced in Delphi XE2, provide developers with new options for associating objects. And they are only one of a wealth of new features introduced in this groundbreaking version of Delphi. They are also a source of some confusion.

One of the problems is that most of the demonstrations of LiveBindings are simple, in part because LiveBindings are so new. Another way to put this is that it's hard to think differently about object binding when we are so familiar with Delphi's existing mechanisms. As a result, most examples that I've seen so far duplicate much of what we already achieve in Delphi.

But this is bound to change. I believe that once we start to see creative applications of LiveBindings, we, the collective Delphi community, will begin to think about them differently.

I hope to jump start this process by collecting examples of LiveBindings that represent the way that we'll be using them in the future, and I'll publish these here. Of course, I'll give credit if you contribute so that you can bask in the gratitude of your fellow Delphi developers.

So, here is my question. Do you have examples of LiveBindings that go beyond the obvious? Alternatively, have you seen an example that breaks the mold? Is so, please share.

And, in case you haven't given much thought to LiveBindings, here is a short introduction.

LiveBindings

LiveBindings is a general term for Delphi's new object/property binding mechanism first introduced in RAD Studio XE2. It is the only binding mechanism available to the new FireMonkey cross-platform component library (FMX), and is also available for traditional visual component library (VCL) components.

At its core, LiveBindings is a mechanism for creating associations between objects and expressions. Expressions are strings that are evaluated by Delphi's new expression engine, and in the case of LiveBindings, they define what effect the expression will have on an object.

While expressions are strings, they are evaluated by the expression engine at runtime, which is quite a bit different than your Delphi code, which is compiled by Delphi's compiler at compile time. As a result, expressions are different from other string types you normally encounter in Delphi code. For one thing, expression strings can define literal values using either single quotes or double quotes. In addition, the expression engine recognizes special methods that have been registered with it through Delphi's Open Tools API (OTA), and can employ custom output converters to transform data from one type to another.

Another concept critical to LiveBindings is scope. In LiveBindings terminology, scope defines what is visible to the expression engine. Most LiveBindings require a control component (the object to which the expression will be applied), and in most cases a source component as well. In the case of these LiveBindings components, the control and source components are both in scope, making their properties available to the expression engine. Similarly, those custom methods that have been registered with Delphi from a design time package are also in scope, making those methods callable from your expressions.

It's worth noting that while LiveBindings use expressions, expressions can be used without LiveBindings. Specifically, you can create a scope programmatically, adding to it the objects and methods you want the expression engine to evaluate, and then ask the expression engine to perform the evaluation, returning a value based on the expression string. It's an important point, as far as the expression engine is concerned, but not something that you necessarily need to think about when you are using the LiveBindings components.

Do We Need LiveBindings?

I recently spoke about LiveBindings during the "24 Hours of Delphi" broadcast with David Intersimone. One of the listeners asked a question about LiveBindings that I hear pretty often, though he gave a somewhat new twist. "Why do we need LiveBindings?" he asked. "After all, it appears that LiveBindings is just another way of doing what we already do using event handlers. It kind of seems like fishing poles. In older days we had cane fishing poles, and they worked just fine. The new fiberglass and graphite rods are nice, but they don't really do more than the old rods."

I like the analogy a lot, because it actually highlights why LiveBindings are a positive thing. Let's take the fishing pole example. A recent television show on The History Channel called "101 Gadgets that Have Changed the World," the publishers of the magazine Popular Mechanics list the top 101 devices that have had a dramatic impact on our daily lives. And, guess what, fiberglass fishing poles made the list (at 100), beating out duct tape and being edged out by the stapler.

In any case, the point is that while cane poles and fiberglass fishing rods perform the same task, they work differently, and fiberglass rods are functionally better on every level.

I think we are going to be saying the same thing about LiveBindings, once we get our heads around them. Yes, you can do many things with LiveBindings that can be achieved without them, but as we get more familiar with their capabilities, I believe we will discover a whole range of features that are enabled only through LiveBindings.

So, let me hear from you. Post a link to your example, or an example that you find on the Web, as a comment to this posting.

8 comments:

  1. There is just one problem with the fishing poles example. The new ones are easy to use and don't require like tons of extra work to be done like LiveBindings currently do when you want to do more than just bind an edit to a simple string property.

    ReplyDelete
  2. LiveBindings were made for TDataSets and Firemonkey. They
    They fall flat when working TList data in Firemonkey or VCL.

    Just try to create an bidirectional binding of a TList to a TStringGrid (in either framework)

    This is a critical design flaw.

    ReplyDelete
  3. Robert:

    Thank you for your input, but I don't share your observation. While I admit that I have not tried to bind a TList to a TStringGrid, I suspect that such a binding might be the wrong way to go. I am a database guy (as I know you are also), so I am biased when I think about a user interface. Specifically, I pretty much always bind UI controls to DataSets. If you bind the TList (for example, a TListBox) and a TStringGrid to the same BindScopeDB, those objects stay synchronized. Even a TStringList or TList might need to be bound to the same data source that the TStringGrid is bound.

    Again, I thank you for your input. We are all in new territory here, and I am more than a bit excited about what we might discover, and an open discussion about LiveBindings is exactly what we need.

    ReplyDelete
  4. I agree with Robert and Stefan. LiveBindings is an opportunity to move Delphi forward by stimulating modern architecture patterns. If the focus is just on keeping backwards compatibility it is a wasted effort and will even endanger the push towards having Firemonkey as the replacement of VCL.
    I don't want to attack you personally as I highly appreciate what you have been and are still doing for the Delphi community, but if Delphi wants to survive key figures like you should be promoting new ways of thinking and pushing the boundaries of the Delphi architecture.
    Having this discussion regarding LiveBindings is perhaps such an opportunity. Perhaps instead of talking about examples of how to use LiveBindings it would be better to talk about what problems we expect LiveBindings to solve and then find specific examples. Those examples could then perhaps expose the current weaknesses of LiveBindings.

    ReplyDelete
  5. Making the UI dependant to DataSets of any kind is a design flaw also - one most of us have lived with a long time.

    Actually I was hoping LiveBindings will break with that - but obviously they do not.

    Everyone that has ever worked with bindings in .Net (be it WinForms or WCF) knows that you don't need to have some kind of dataset (however you can) if you want to bind simple objects or lists of objects to any kind of controls (however it works better in WCF than in WinForms). Delphi has been lightyears ahead 10 years ago when it came to creating user interfaces and presenting data and at least to me this was a major selling point.

    This still is true for dataset centered applications but not for those where you work with objects and collections of objects. While it is possible to bind them to a stringgrid you have to do some extensive setup and defining several bindings. If I remember there is a sample somewhere how to do so.

    ReplyDelete
  6. Thank you Stefan and Arjan for your input. I value your opinions, and these should certainly be considered as LiveBindings mature. This is the first version of Delphi with LiveBindings, and in this version it provides essential, window-independent data binding in FireMonkey. Will it improve in future versions? I am confident that it will, and input like yours should influence those changes.

    I also want to specifically respond to Stephen's comment about certain bindings requiring "extensive setup and several bindings." Yes, some LiveBindings take time to setup, and many require two or more expressions ,which are elements of a LiveBinding, not LiveBindings themselves. I have some LiveBindings that include eight or more expressions (and several dozen is not inconceivable). However, the more I work with LiveBindings, the less complicated this setup feels, and one of the things I've noticed is that it is easier when you consider that a LiveBinding may have many different expressions working in coordination to accomplish a specific task that would otherwise require code. As I mention in the post, I suspect that LiveBindings require a conceptual shift, and once we make that transition much of the mystery may evaporate.

    ReplyDelete
  7. Well, this conversation is nearly two years old. I was excited to find your comments at the top, since I've been using XE2 since it came out and have struggled to find a reason to get into Livebindings. Today I decided that I needed to 'get my head around it', as you put it Cary, and went through the tutorials etc. At the end I thought: 'I already do this... and with less trouble?'

    So I went searching and thought I'd found something interesting here. But some seem to share my opinion, and the illuminating examples are... not here. Cary, could you share some of your own uses of Livebindings that go beyond what we do with conventional code?
    JD

    ReplyDelete
  8. Somehow I agree with JD Smith. Every time I started to use Livebindings it seems to be easier not to use it

    ReplyDelete