Welche Konsequenzen zieht ihr aus den Features für XE2?

[Stevie]

Zitat von bernerbaer:

Ich habe auf der Seite von David Intersimione folgenden Kommentar gefunden:

Zitat:

Delphi 64-bit compiler is worse than 32-bit one. It produces inefficient and much slower code (64-bit code optimizer is scheduled for XE3, as I see over QC). It doesn’t support Extended type, only 64-bit emulation (QC #92342). So only purpose of 64-bit compiler is to add a several lines to new feature list, though it is useless?

Live Bindings feature has been met sceptically too (QC #97444).

Leider habe ich unter den angegebenen QC Nummern bei Embarcadero nichts gefunden(Either there is no report #xxxxx, or you are not authorized to see that report). Gibt es dazu evtl.noch weitere Infos?

Da hat wohl jemand ausm (Beta-)Nähkästchen geplaudert, oder?

Was ich bisher so an Info zu dem für mich interessantesten Feature (LiveBindings) gesehen habe, reißt mich jetzt nicht vom Hocker. Gerade das Feature hätte wie eine Bombe einschlagen können (im Gegensatz zu den Jahre zu spät kommenden 64bit und Cross platform). Und gerade in Verbindung mit Firemonkey. Was macht man denn nun wenn man eine Anwedung für beide Oberflächen entwickeln möchte? Man muss zwangsläufig Oberfläche und Business Logik trennen (ein Thema, was ja in jüngster Vergangenheit heiß diskutiert wurde) und LiveBindings dafür verwenden, diese wieder zusammen zu tackern. Aber eine string basierte Scriptsprache brauch ich nicht, die gibts schon, und die kann mit ziemlicher Sicherheit weitaus mehr.

[jaenicke]

Zitat von Stevie:

Da hat wohl jemand ausm (Beta-)Nähkästchen geplaudert, oder?

Ja, allerdings verwechselt derjenige da etwas. Extended war nur noch eine Emulation, nicht umgekehrt...

Zitat von Stevie:

Aber eine string basierte Scriptsprache brauch ich nicht, die gibts schon, und die kann mit ziemlicher Sicherheit weitaus mehr.

Also so hätte ich das auch nicht wirklich benutzt. Hier etwas von mir zu dem Thema:
http://www.delphi-forum.de/viewtopic.php?t=106839
Da sieht man auch ein bisschen mehr...

Ich hätte mir zwar auch eine etwas andere Umsetzung gewünscht, aber schlecht finde ich es trotzdem nicht.

[mquadrat]

Mhh also die Live-Bindings sind schon mal besser als nichts. Ich kann mich noch nicht so ganz entscheiden, ob ich die mag oder nicht. Werde es mal ausprobieren, sobald ich eine XE2 hab. Aber vom Konzept her, find ich DSharp schöner.

[Stevie]

Zitat von mquadrat:

Mhh also die Live-Bindings sind schon mal besser als nichts. Ich kann mich noch nicht so ganz entscheiden, ob ich die mag oder nicht. Werde es mal ausprobieren, sobald ich eine XE2 hab. Aber vom Konzept her, find ich DSharp schöner.

Das geht runter wie Öl Wenns raus ist, werd ich mal eine Gegenüberstellung machen

[mquadrat]

Wer Gutes leistet, wird auch gelobt

[mquadrat]

Mag mir jemand erklären, wo der Sinn bei Live-Bindings liegen, wenn ich denen mittels Notify erst mitteilen muss, dass sich was geändert hat? Dann hab ich doch fast genau so viel Glue-Code wie vorher auch, oder nicht?

[Lemmy]

Hi,

selbst beim Observer-Pattern musst Du ja mitteilen, dass sich was verändert hat. Was mir am LiveBinding überhaupt nicht gefällt ist die Beschränkung auf TComponent. Gibts dazu irgend welche Aussagen? Die Anbinung des eigenen BusinessModel kann man so vergessen.... Da es ja offensichtlich per RTTI geht, warum wurde das nicht schon viel weiter oben in die VCL eingehängt?

Grüße

[Stevie]

Zitat von mquadrat:

Mag mir jemand erklären, wo der Sinn bei Live-Bindings liegen, wenn ich denen mittels Notify erst mitteilen muss, dass sich was geändert hat? Dann hab ich doch fast genau so viel Glue-Code wie vorher auch, oder nicht?

Leider wurde das scheinbar nicht konsequent in die VCL Controls (zu FMX kann ich nicht viel sagen) eingebaut. Einer meiner vielen Kritikpunkte zu den LiveBindings bisher. Theoretisch gibt es über die neue Observer property von TComponent die Möglichkeit, dass, was ich in der extra "Zwischenunit" bei DSharp gemacht habe direkt in den entsprechenden Change methoden der Controls einzubauen. Das scheint auch der Fall zu sein für einige Controls (angeschaut bei TEdit und TCheckBox). Allerdings stimmt dort die Reihenfolge nicht, so dass der Observer feuert, bevor die Property aktualisiert wurde (KeyDown Methode im TCustomEdit z.B.). Außerdem registrieren die TBindingExpression Objekte keine Observer, dies tun nur die TBindLink Objekte (weiterer Kritikpunkt, keine gemeinsame Basisklasse). Diese haben aber noch das Problem, dass das SourceObjekt ein bestimmtes interface (irgendwas mit IEditBindLink oder so) implementieren müssen. Ansonsten bleibt das TEdit einfach ma ReadOnly.

Zitat von Lemmy:

Was mir am LiveBinding überhaupt nicht gefällt ist die Beschränkung auf TComponent. Gibts dazu irgend welche Aussagen? Die Anbinung des eigenen BusinessModel kann man so vergessen.... Da es ja offensichtlich per RTTI geht, warum wurde das nicht schon viel weiter oben in die VCL eingehängt?

Bindings arbeiten auch mit TObject. Die Property heißt aber anders (DataObject oder so...) Das fällt nur in der IDE nicht auf, weil man dort ja nur TComponent Derivate hat. Ich glaube in der Doku gibts ein Beispiel, wie man einfache Objekte über Bindings aneinander heftet.


Generell kann ich mich des Eindrucks nicht erwehren, dass das Hauptziel der LiveBindings das fitmachen von FMX für DB Geschichten ist. Dann schien jemandem aufgefallen zu sein, dass man da ja noch mehr draus machen kann aber es wurde nicht konsequent und qualitativ hochwertig umgesetzt.