Visual LiveBindings - Chancen und Grenzen

[TiGü]

Ich habe versucht mich mit den Visual LiveBindings (VLB) in XE3 zu beschäftigen.
Irgendwie werde ich daraus nicht schlau.

Da ich nicht mit klassischen Datenbanken arbeite, erscheint mir der Nutzen sehr begrenzt zu sein.
Viele Tutorials zielen explizit auf die Verbindung von Grid-Komponenten mit Datenquellen ab (z.B. das von Delphi-Treff).

Aber was ist mit der GUI-Logik?
Ich bin es von VEE, LabVIEW oder Simulink gewohnt mit visuellen Programmiersprachen zu arbeiten, aber in den VLB steige ich nicht durch.

Wie kann man zum Beispiel sich gegenseitige ausschließende Bedingungen erstellen?
Also wenn ich auf A klicke, soll sich B aktivieren aber C und D disabled werden (siehe Projekt im Anhang).

Wie und wo kann ich die Konvertierung von Edit-Eingaben beeinflußen?
Also das der String zum Integer, Bool oder Date wird?

Also irgendwie erscheint mir das noch nicht ganz fertig zu sein?
Oder denke ich zu kompliziert?
Hat wer sich damit schon eingehender beschäftigt?

[stahli]

Für den Fall, dass Du es noch nicht kennst, mal mein Thread zu dem Thema: http://www.delphipraxis.net/172249-d...ml#post1196272

Das wesentliche Thema ist m.E. die Trennung von Businesslogik+Daten von der GUI und die Bindung der beiden Schichten.

Die Bindung der GUI-Controls untereinander (Edit.Enabled entspricht CheckBox.Checked) sollte m.E. maximal als Nebeneffekt angesehen werden.
Diese GUI-Bindungen lassen sich sehr einfach und übersichtlich auch mit Code in Eventhandlern umsetzen.

Die Bindungskomponenten (insb. die LB) können zu Problemen führen, die man mit "richtigem Code" nicht hat.

Bindungskonzepte bedingen die Untersuchung von Objekten und Eigenschaften anhand deren Namen. Wenn ich also an die Eigenschaft "Text" des Objektes "Edit1" binde, müssen die Eigenschaften des Objektes durchsucht werden, ob eines den Namen "Text" hat. Dann muss ggf. der zu übertragende Wert konvertiert werden und kann dann zugewiesen werden. In dieser Kette kann es diverse Probleme geben (wovon die LB regen Gebrauch machen).

Wenn man die Zuweisung im Code durchführt hat man u.U. ein paar Zeilen Quelltext zu schreiben, allerdings funktioniert die Zuweisung schnell und sicher.
Eine grafische Bindung von Controls im Designer wirkt natürlich auf den ersten Blick interessant, allerdings taugt das letztlich nicht wirklich für größere und komplexere reale Projekte.

Eine Eigenschaftsbindung ist vor allem dann sinnvoll, wenn die Eigenschaften dynamisch zur Laufzeit ausgewählt werden müssen. In anderen Fällen würde ich die Regelung im Projektcode vorziehen.

Bei den LB kommt als Problem hinzu, dass die Wertkonvertierungen oft nicht funktionieren (Checkbox und true/WAHR) und das das Löschen von gebunden Controls aus der IDE zu Zugriffsverletzungen führt.


Anders würde ich die Bindung der GUI-Controls an eine Datenschicht bewerten. Dort ist es sinnvoll, einen solchen Weg zu nutzen. Allerdings ist das Konzept der LB m.E. dafür ungeeignet.
Ich stelle mir eher vor, dass die Controls wissen müssen, WAS sie darstellen sollen und sich die Daten aus der Datenschicht (über einen Manager) abrufen.
Außerdem sollten Listen und Gitter nur die aktuell sichtbaren Daten abrufen (und nicht alle 500T Datensätze) und der Weg über die Prototype-Generatoren (oder wie das hieß) ist für mich auch nicht zweckmäßig.


In 1-2 Wochen will ich mal eine Preview meines Frameworks vorstellen, das m.E. der deutlich effektivere Weg ist (und auf Wunsch auch ein Binding zwischen GUI-Controls ermöglicht).
Bin ja schon mal echt gespannt...

[TiGü]

Zitat:

Zitat von stahli (Beitrag 1203297)

Die Bindung der GUI-Controls untereinander (Edit.Enabled entspricht CheckBox.Checked) sollte m.E. maximal als Nebeneffekt angesehen werden.

Also hatte ich recht mit meiner Vermutung:
Es geht dabei "nur" um die Anbindung von visuellen Komponenten an Datenbanken.

Das ist schade, weil das visuelle Programmieren recht eingängig ist.
Eine Oberfläche visuell zu programmieren fände ich recht nützlich.
Aber nun gut, es hat halt nicht sein sollen.
Vielleicht werden die nächsten IDE-Versionen dahingehend ausgereifter sein.

Es gibt auch eine Handvoll Bugs im Umgang mit den VLBs (trotz Update 2), z.B. das Verbindungen zur PrototypeBindSource noch in der DFM stehen, aber in VLB-Designer schon gelöscht wurden.
Auch ein oder zwei Exceptions kamen hoch, und das nur in kleinen Beispiel-Projekten mit vier bis fünf Komponenten!

Schade, da war meine Erwartung höher...

[bernau]

Zitat:

Zitat von TiGü (Beitrag 1203301)

Das ist schade, weil das visuelle Programmieren recht eingängig ist.
Eine Oberfläche visuell zu programmieren fände ich recht nützlich.

<glaubenskrieg ein>
Ich finde es klasse den Quellcode zu dokumentieren um später nachzulesen, weshalb nun die CheckboxA disabled ist und die CheckboxB nicht. Deshalb setze ich nur die nötigsten Properties im Objektinspektor. Alles andere wird gecodet. Deshalb fehlt mir auch der Zugang von Visual Livebindings. Kann mich einfach nicht damit anfreunden.
<glaubenskrieg aus>

[stahli]

Zitat:

Zitat von TiGü (Beitrag 1203301)

Also hatte ich recht mit meiner Vermutung:
Es geht dabei "nur" um die Anbindung von visuellen Komponenten an Datenbanken.

Das ist nicht ganz richtig.
Grundsätzlich sollen sich Bindungen an Objekte (also auch zwischen Controls) und an Datenmengen durchführen lassen. Grundsätzlich funktioniert das auch.

Allerdings sind m.E.
- zu viele Fehler enthalten
- das Konzept der Bindung an Datenmengen nicht zweckmäßig
- die graphische Darstellung und Definition von Bindungen nicht sinnvoll wenn es über ein paar Democontrols hinaus geht



Bernau würde ich mich in der Konsequenz auch nicht anschließen wollen. Da liege ich irgendwo dazwischen.

[Sir Rufo]

Zitat:

Zitat von bernau (Beitrag 1203308)

Zitat:

Zitat von TiGü (Beitrag 1203301)

Das ist schade, weil das visuelle Programmieren recht eingängig ist.
Eine Oberfläche visuell zu programmieren fände ich recht nützlich.

<glaubenskrieg ein>
Ich finde es klasse den Quellcode zu dokumentieren um später nachzulesen, weshalb nun die CheckboxA disabled ist und die CheckboxB nicht. Deshalb setze ich nur die nötigsten Properties im Objektinspektor. Alles andere wird gecodet. Deshalb fehlt mir auch der Zugang von Visual Livebindings. Kann mich einfach nicht damit anfreunden.
<glaubenskrieg aus>

Das ist IMHO kein Glaubenskrieg sondern die Trennung von Logik/Daten und Anzeige.

Wenn die Darstellung eines Controls abhängig von den Daten ist, dann sollte dieses immer per Code (bzw. durch die Logik) erfolgen. Ich würde sogar noch weiter gehen und sagen, dass es völlig unerheblich sein muss, wie diese Eigenschaften durch den OI festgelegt wurden. Die Logik drückt das einfach durch.

@TiGü

Im Anhang habe ich ein winziges Progrämmle gepackt, dass einmal den Unterschied zwischen VLB und dem klassischen Vercoden zeigen soll. Die Echsen sind auch mit dabei.

Bitte keine Debatten warum die kompilierten Programme mit VLB mehr als doppelt so groß sind ... je größer ein Projekt, umso weniger fällt das ins Gewicht.

Ob VLB oder nicht, muss man selber entscheiden (ich bin erst mal ohne - Ausnahme FMX mit DB)

[TiGü]

Zitat:

Zitat von Sir Rufo (Beitrag 1203407)

Im Anhang habe ich ein winziges Progrämmle gepackt, dass einmal den Unterschied zwischen VLB und dem klassischen Vercoden zeigen soll. Die Echsen sind auch mit dabei.

Sehr interessant, vielen Dank Rufo.

Anhand deines MVVM-Beispiels (eigentlich ja VVM, weil Model fehlt:wink:) habe ich mal weiter experimentiert.

Ich wüsste zum Beispiel nicht, wie man das mit VLB umsetzen könnte.