In der DP gibt es ja mal sporadisch Fragen zu den LiveBindings ... mit seltenen hilfreichen Tipps.

Mich würde mal interessieren, ob jemand inzwischen ersthaft mit den (visual) LiveBindings arbeitet und in welchem Zusammenhang (Plattform, Zugriffsart, Datenmengen)...

Nur rudimentär um eine flache Tabelle auf ein TListView zu binden, unter FMX.
Das geht so gerade noch mit dem visuellen LB Designer.

Aber ich möchte auch die Bindings per Code machen, das erscheint mir irgendwie sicherer und übersichtlicher.
Dazu müsste man aber ein paar Klassen schreiben damit es einfacher wird.
Die Videoserie von Steven Ball zu den LiveBindings finde ich ganz hilfreich, und zeigt das man doch theoretisch
einiges damit machen kann.
Ob es aber für größere Projekte auch performant läuft wage ich zu bezweifeln.
Wäre mal gut wenn Emba da ein DB-DemoProjekt in die Samples stellt, um zu zeigen ob und wie man damit
komplexere Dinge hinbekommt.

Ach ja, den ExpressionParser von LB benutze ich für einen Calculator auch, das funktioniert ganz gut und
ist erweiterbar.

Ich denke LB wird kommen mit der Zeit, denn unter Fmx gibt es ja nicht viele Alternativen.

Rollo

LiveBindings hmm

Nur für Prototypen oder um mal eben "dem" Kunden ein Formular mit seinen Daten zu zeigen...
Dafür kann man sehr schön eigene Demo-Daten Generatoren schreiben. Vorsicht die kompletten Daten sind im Form, daher nicht für endgültige Produkte geeignet.

Im Code kann man die LiveBindings auch sehr nett für eine ViewModel->View Bindung nach "Nick" benutzen.
Aber davon bin ich wieder abgegangen.

Bei großen Forms wird das Stricheziehen einfach zu unübersichtlich.

Im code schon eher...

Zitat von Rollo62:

Dazu müsste man aber ein paar Klassen schreiben damit es einfacher wird.

@Rollo62 kannst Du dazu etwas mehr sagen... Wäre das etwas, was ich in meinem FDK haben sollte?
Praktisch? Erfahrungen? Performance? ggf. als Bindeglied Thread->Sync-> UI?

Mavarik

Evtl sollte man DSharp als Alternative mit betrachten

http://www.delphipraxis.net/164573-d...nd-hoeher.html

http://www.delphipraxis.net/155623-m...ml#post1286767

Mich würde da mal ein Vergleich zu den LiveBindings von Delphi interessieren.

Generell hätte ich gern LiveBinding eingesetzt, bin aber noch unschlüssig. Mir fehlt ein praxistaugliches Beispiel, was im Code erstellt wird (visuelle Designer möchte ich nicht nehmen). Auch habe ich eine gewisse unbegründete Abneigung gegen die Delphi-eigene Variante.

Ja vielleicht bräuchte man eine gute Wrapperklasse zw. den Controls und Datasets.
Eigentlich sollen das die LB Klassen ja schon machen, aber ich denke das ist noch verbesserungsfähig.

Also wenn man von einem Dataset --> auf Wrapper --> (diese nutzt womöglich ganz oder teilweise die LB Klassen) --> auf das Control,
so das man sich relativ leicht vom Dataset zum Control kommt:
Dataset --> Wrapperklasse --> Control

Das würde ich zuminest mal sehr hilfreich finden um evtl. auch größere Projekte damit anzulegen.

Im Prinzip macht das TDataSet und der, wie heist der noch?, TDataLink-Adapter, genau das: Verbinden von Dataset zu Control.
Nur das es da eben spezielle DB-Controls gibt.

Ich denke es spricht eigentlich nichts dagegen das auch FMX von DB zu Controls einen zuverlässigen Weg hinbekommt, die LB sollten das ja sein.
Wo die Performance wirklich draufgeht lässt sich so einfach vielleicht nicht sagen, aber der Wunsch wäre natürlich die Controls wie DB-Controls nutzen zu können.
Womöglich bleibt via RTTI einiges an Performance auf der Strecke.

Vielleicht kommt auch jemand auf die Idee und baut die DB-Controls alle wieder nach für FMX, aber das sollte schon eine Art LB besser hinbekommen.

Einen grafischen Editor ala LB Designer finde ich nicht wirklich sinnvoll, aber wenn man Wrapperkomponenten hätte die DataSet mit Control verbinden können,
ganz in der Art wie es bei Delphi immer war, hätte man zumindest mal einen Anfang.

Das LB dann noch wesentlich mehr als DB zu Control kann ist schon klar, aber ich bräcute eben das in 90% der Fälle.

Rollo

Die Livebindings funktionieren schon erstaunlich gut, wenn man bedenkt, dass diese keine richtige Compilerunterstützung haben. Wenn es die geben würde, würden wir die auch sofort nutzen.
In der aktuellen Form ist der Nutzen für uns viel zu gering, wenn man die Performancenachteile anschaut.

Wow, das schreit ja geradezu danach mal bei G+ nachzuhören. Ich hab jetzt Feierabend, aber falls bis morgen nichts in der Delphi-Gruppe steht, leite ich diese Frage gerne mal weiter

Sherlock

Vielleicht interessiert euch wie MSEgui die Datenanbindung löst. Dort gibt es zusätzlich zu den DB-Komponenten und DB-Edit-Widgets die "ifi"-Komponenten. ifi-Komponenten verbinden Daten- und Event-Endpunkte. Jedes MSEgui Edit-Widget hat auch eine ifi-Property für die bidirektionale Datenanbindung. Mittels ifi-remote ist es sogar möglich, die Verbindung über pipes oder sockets zwischen verschiedenen Prozessen aufzubauen, siehe
http://mseide-msegui.sourceforge.net...ifiremote.mpeg
Durch die Verwendung von Datamodulen und ifi-Komponenten lassen sich RAD und Trennung von GUI und Programmlogik perfekt kombinieren, ich bin richtig happy. Etwas entsprechendes lässt sich sicher auch für Delphi entwickeln.
Zur Illustration MSEkicadBOM, ein Komponentendatenbank- und Produktionsdateien-Generator-Programm für KiCad, das gerade entsteht:
https://gitlab.com/mseide-msegui/mse...ools/kicad/bom
Das Hauptdatamodul: mainmo.png
Das zugehörige Hauptformular: mainfo.png
Das Basisformular für Edit-Dialoge: base.png
Und ein davon abgeleitetes Dialog-Formular: component.png

Zitat von mse1:

Mittels ifi-remote ist es sogar möglich, die Verbindung über pipes oder sockets zwischen verschiedenen Prozessen aufzubauen, siehe
http://mseide-msegui.sourceforge.net...ifiremote.mpeg
Durch die Verwendung von Datamodulen und ifi-Komponenten lassen sich RAD und Trennung von GUI und Programmlogik perfekt kombinieren, ich bin richtig happy.

Das klingt super. Wie es umgesetzt ist habe ich mir nicht angesehen, aber die Idee dahinter und das Beispiel im Video ist super.
An etwas ähnlichem arbeite ich auch gerade.

Mal sehen was bei G+ für Antworten kommen: https://plus.google.com/106768347380...ts/GTS5v94SZKG

Sherlock