I saw this question on the delphi.non-tech forum from Chris Rolliston and thought it would be interesting to bring the question over here.
I saw this question on the delphi.non-tech forum from Chris Rolliston and thought it would be interesting to bring the question over here.
Do you use LiveBindings?
I've only used it in a demo or two with Delphi XE2/3 but since my workplace only uses Delphi 2007, I've not really used it much. I suppose if I were to build something in FireMonkey then I most likely would use it.
https://forums.embarcadero.com/thread.jspa?threadID=85044
Do you use LiveBindings?
I've only used it in a demo or two with Delphi XE2/3 but since my workplace only uses Delphi 2007, I've not really used it much. I suppose if I were to build something in FireMonkey then I most likely would use it.
https://forums.embarcadero.com/thread.jspa?threadID=85044
Tried it, but the bindings don't have automatic verification or updating, so the first component I renamed just broke the binding I had just made... haven't tried again since.
ReplyDeleteThe UI didn't look very practical either, call me old-fashioned, but writing bindings in plain code or script (both with auto-completion and compiler validation) looks simpler/safer.
Is the Thread gone ?
ReplyDeleteChristian c I think the Embarcadero newsgroup server is down.
ReplyDeleteLive bindings are dead to me. Whoever came up with the concept should be relegated to be working on PHP.
ReplyDeleteThe idea is excellent as it opens oppertunities. The execution is completly useless as it has no direct language support. And as Eric said therefor refactoring support is non existing.
ReplyDeleteLiveBindings make the code too fragile. And it's still faster to implement the necessary validation checks the "good old way".
ReplyDeleteBut I would love to see it being improved. In general I like the idea of having an alternative way for making any component and especially any property of a component DB aware or linking them to other data objects. For me it's definitively the way to go in the near future.
Fred Ahrens If you are following the MVVM pattern for example bindings are excellent and the best way of gluing GUI and BL. In that case it is rather complicated to do it the "good old way".
ReplyDeleteStefan Glienke I absolutely agree.
ReplyDeleteLars Fosdal Lars, Lars, don't hold back; tell us what you really think! ;)
ReplyDeleteAt our recent ADUG Symposium, Malcolm Groves gave a presentation on MVVM in Delphi using LiveBindings to wire-up the GUI. Using the same Model and ViewModel, he created a Windows VCL app and a separate iOS app. He did say you can do this without using LiveBindings but using it did make it easier.
ReplyDeleteColin Johnsun I know that presentation (I think he gave the same presentation at Code Rage 7) and he actually did not went that far with MVVM using convention over configuration, DI and that stuff but wired together his pieces by hand.
ReplyDeleteBill Meyer - In their current form, they are a liability, not an asset.
ReplyDeleteI'll leave it up to you to decide if I mean the LiveBindings, the developers, or both ;)
Lars Fosdal Yet another reason I am glad to be on the sidelines, still using XE.
ReplyDeleteWell, fortunately you don't have to use them.
ReplyDeleteLars Fosdal Or can't. ;)
ReplyDeleteStefan Glienke Actually this was a follow on to the CodeRage session. In the CodeRage session I had 35 minutes, so perhaps not surprisingly it was focussed on introducing the concept. I have taken the MVVM stuff further, including things like convention-based auto-wiring of actions to the viewmodel, and auto-binding of some properties. I'm still undecided on whether that is always a good thing or not. Conventions are great if you know the convention :-) eg. For the actions example, it does reduce the code in your view, but it also reduces the comprehension of what's going on, so still wavering on whether I like it or not.
ReplyDeleteOh, and in terms of DI, I do use it in my MVVM projects (well, actually IoC, not specifically DI). I think I even mentioned in the video that some form of IoC is really useful in MVVM, but not essential.
ReplyDeleteAs to LiveBindings, I think they show a lot of promise, and I use them and have customers using them today. However, like almost every bit of software I own, I have a long list of things I'd like to see added/changed :-)
ReplyDeleteThe concept has promise. The current implementation make them a liability, Malcolm Groves.
ReplyDeleteLars Fosdal can you expand on that?
ReplyDeleteLars Fosdal Yeah, on one part or the other. ;) Or even both.
ReplyDeleteMalcolm Groves - The problem is parsing strings at run time for connections that should have been validated at compile time. As Eric Grange mentions, the bindings are too easy to break. Rename a referenced property and the connection is lost, but you don't discover it until run time.
ReplyDeleteI also would like to know the reasoning for having the binding definitions in a separate file instead of in a form component, similar to the Action controller?
I'd like to see this binding as a deep language feature, where validation is at compile time, and with strong typing without having to go through TValue or Variant. The code does after all reference explicitly typed properties or function results.
Malcolm Groves As Lars Fosdal said, there should be a way to have the binding be leveraging the native compilation, rather than constructing sand castles with RTTI and interpreted formulas. It's not like DFM properties, which lend themselves to natural runtime changes (internationalization f.i.).
ReplyDeleteThose bindings belong in something like a partial class maintained by the IDE & validated by the compiler. Scripting the live-bindings should be an option, not a core requirement imho.
That seems to be my feeling about LiveBindings too. As a feature on its own, the expression engine is useful. But making it a core element in LiveBindings means that performance will always be sacrificed when you have a lot of bound properties. Being highly coupled to the expression engine will always be a limiting factor in my opinion.
ReplyDeleteAnother pet hate for me is that LiveBindings is skewed towards visual bindings (which is the preferred method as described in the documentation). My younger self would probably prefer the convenience of the visual bindings because it would get things done more quickly in the RAD way of doing things. But current (much older) self would prefer to express these relationships explicitly in code for traceability and for better maintainabilty.
ReplyDeleteWhich leads me to the next point. LiveBindings seems like it requires a lot of ceremony to set up when done programmatically which makes me feel like its been over-engineered. This is probably why doing it the visual way is the preferred method.
It seems to me that the effort was put into making it "easy to use" in the RAD way but at the expense of making the architecture more complex. I suppose making a simpler architecture that requires a "harder" programmatic approach isn't a sexy enough feature to market or sell.
Still amazed how many people come to the same conclusion (or did already in the past) as I did when LB were introduced over a year ago.
ReplyDeleteAnd disappointed how the people in charge ignore(d) everyone telling them that their concept it wrong.