meine odControls - Preview

[mquadrat]

Nochmal zur Idee an sich:

Die ist soweit gut. Ich denke mal, dass hier zumindest die Leute, die größere Projekte betreuen, ebenfalls eigene App-Frameworks in Gebrauch haben. Vielleicht erklärt das die schwache Rückmeldung. Meine zwei größten Kritikpunkte sind zum einen die Abgeschlossenheit des Systems und die große Abhängigkeit von Strings. Das erstere kann zum Problem werden, wenn sich in einigen Jahren mal was ändern soll, oder ein Mash-Up aus verschiedenen Cloud-Diensten gebraucht wird oder oder oder. Mir fehlen da ein wenig die Erweiterungspunkte. Das mir der Experte nicht so sonderlich gefällt, hatte ich ja oben bereits geschrieben. Ich habe dort keinen Syntax-Check, kein Auto-Completion. Habe ich sehr viele Klassen, dann suche ich mir da einen Wolf bis ich die Deklaration gefunden habe. Also entweder muss der Experte von der UX her leistungsfähiger werden, oder man sollte über eine andere Art der Definition der Meta-Daten nachdenken.

Die Geschichte mit den Listen gefällt mir ganz gut.


Was mir zusätzlich zum bereits geschriebenen aufgefallen ist (nur Hinweise / Denkanstöße, keine Kritik):

- Bei der Region PRIVAT fehlt das E am Ende
- Sehe ich das richtig, das bei jedem Start die komplette Datenbasis geladen wird? Große Datenbestände? Multi-User?
- Die ID der Datensätze würde ich (persönliche Meinunng) eher fortlaufend vergeben. Menschenlesbarkeit macht das Debugging einfacher
- Property-Namen: Dataset ist nicht gut, da man dort ein TDataset und kein TodDataset erwartet
- Das Zuweisen von ODClass und ODName nach dem Generieren eines OD-Objekts ist doch arg unschön. Der Aufrufer muss wissen, welchen Namen die Klasse hat?!
- Das Befüllen der Objekte erfolgt über die Setter? Wie realisiert man dann Nur-Lesen-Properties? Oder gibt's die nicht?
- Video 03: Wieso kann ich nicht LinkTest binden? Der Treeview wird nur für Test erweitert.
- Warum kein XML für die Datendatei?


Mit dem Release von XE2 haste dir einen ungünstigen Zeitpunkt rausgesucht

[stahli]

Zitat von mquadrat:

Nochmal zur Idee an sich:
Die ist soweit gut.

Du bist ein reiner Guter.

Zitat:

Ich denke mal, dass hier zumindest die Leute, die größere Projekte betreuen, ebenfalls eigene App-Frameworks in Gebrauch haben. Vielleicht erklärt das die schwache Rückmeldung.

Das denke ich inzwischen auch - deshalb ja auch meine Bitte, bessere Lösungen mal zu zeigen. Aber es ist doch Unsinn, dass sich jeder auf´s Neue die Mühe macht.
Eine generelle Lösung zum einfacheren Umgang mit Daten würde Delphi gut tun. Ich hätte gern schon früher darauf zurück gegriffen.
Eigentlich will ja jeder komplexe Projekte möglichst einfach und flexibel erstellen können.

Zitat:

Meine zwei größten Kritikpunkte sind zum einen die Abgeschlossenheit des Systems und die große Abhängigkeit von Strings. Das erstere kann zum Problem werden, wenn sich in einigen Jahren mal was ändern soll, oder ein Mash-Up aus verschiedenen Cloud-Diensten gebraucht wird oder oder oder. Mir fehlen da ein wenig die Erweiterungspunkte.

Das Konzept ist halt aus meinen Bedürfnissen heraus entstanden. Änderungen sind sicher möglich. Die Datenspeicherung in Strings betrifft auch NUR das Speichern. Das funktionert analog einer Ini bzw. XML. Das lässt sich ohne weiteres anpassen, aber ich sehe darin gerade einen Vorteil in Bezug auf die Flexibilität. Ansonsten muss man bei Änderungen der Datenstruktur komplexe Anpassungen z.B. einer SQL-DB vornehmen. Aus diesem Grund habe ich meine früheren Versuche mit Firebird verworfen.

Zitat:

Das mir der Experte nicht so sonderlich gefällt, hatte ich ja oben bereits geschrieben. Ich habe dort keinen Syntax-Check, kein Auto-Completion. Habe ich sehr viele Klassen, dann suche ich mir da einen Wolf bis ich die Deklaration gefunden habe. Also entweder muss der Experte von der UX her leistungsfähiger werden, oder man sollte über eine andere Art der Definition der Meta-Daten nachdenken.

Der lässt sich ausbauen.
[EDIT]Ich fand das zwar bisher eher unnötig, aber ein Baukastensystem in der Art "Namen eingeben" und "Typ aus Palette dazu ziehen" klingt auch ganz nett. Im Hintergrund würde dann dadurch die triviale cla-Datei erzeugt.[/EDIT]

Zitat:

Die Geschichte mit den Listen gefällt mir ganz gut.

Fein.

Zitat:

Was mir zusätzlich zum bereits geschriebenen aufgefallen ist (nur Hinweise / Denkanstöße, keine Kritik):

- Bei der Region PRIVAT fehlt das E am Ende

Ok danke.

Zitat:

- Sehe ich das richtig, das bei jedem Start die komplette Datenbasis geladen wird? Große Datenbestände? Multi-User?

In der aktuellen Version ja.
Eine DB-Lösung schwebt wir vor. Die Daten könnten dann in einer DB gespeichert werden. Allerdings soll das ein reines "Datenlager" werden. Sämtliche Geschäftslogik soll aber über die Objekte realisiert werden, die sich dann aber ihre Daten (im Unterschied zu jetzt) aus einer einfachen DB holen.
Es wäre darüber hinaus denkbar, dass es "vollständig dumme" Clients gibt, die nur die GUI enthalten. Wenn diese Clients dann gestartet werden, rufen sie für alle GUI-Controls, die sie gerade darstellen sollen, die aktuellen Daten ab.
Da sind meine Vorstellungen noch etwas unscharf, aber Lösungen lassen sich sicher finden. Zumindest finde ich die Idee reizvoll. Zwischen GUI und Datenebene müsste noch eine Verbindungsebene eingesetzt werden (etwas wie DataSnap oder DataAbstract). Damit habe ich noch keine Erfahrungen.

Zitat:

- Die ID der Datensätze würde ich (persönliche Meinunng) eher fortlaufend vergeben. Menschenlesbarkeit macht das Debugging einfacher

Die ID´s enthalten 2 Zeitstempel und man kann davon ausgehen, dass diese weltweit einmalig sind (wenn nicht manipuliert wird). So kann man Objekte auch zwischen Anwendungen austauschen und sie bleiben identifizierbar.
Im Gegensatz zu GUID sind diese analog zu Ihrer Erstellungsreihenfolge aufsteigend sortierbar.

Zitat:

- Property-Namen: Dataset ist nicht gut, da man dort ein TDataset und kein TodDataset erwartet

Ist ein Argument. Könnte ich noch ändern.

Zitat:

- Das Zuweisen von ODClass und ODName nach dem Generieren eines OD-Objekts ist doch arg unschön. Der Aufrufer muss wissen, welchen Namen die Klasse hat?!

Stimmt natürlich. Hier wären Attribute hübscher. Werde ich mal prüfen...
Die Daten werden verwendet, um beim Speichern und Laden die richtigen Objekte anzusprechen. So können zwei Objekte Ox.odName='Person1' und Oy.odName='Person2' beide die Klasse odClass='Person' beinhalten. Hier kann ich also ermitteln, wohin das Objekt in meiner vordefinierten Struktur gehört. Object.Name und Object.ClassName sind für diese Zwecke ungeeignet.

Zitat:

- Das Befüllen der Objekte erfolgt über die Setter? Wie realisiert man dann Nur-Lesen-Properties? Oder gibt's die nicht?

Im Moment nur für SubObjekte, für die das OwnerObjekt selbst eine Instanz erzeugt (Objekt "Test" im Beispiel). Andere Erfordernisse hatte ich bisher nicht. Aber man kann da bei Bedarf natürlich noch einiges regeln.

Zitat:

- Video 03: Wieso kann ich nicht LinkTest binden? Der Treeview wird nur für Test erweitert.

Das macht (wenn ich jetzt so überlege) zur Designtime auch noch keinen Sinn. Wenn LinkTest mal z.B. das schönste Testobjekt aus der Test-Liste referenzieren soll, macht es nur Sinn, das man das zur Laufzeit aus der Liste auswählt. Und dafür gibt es dann unterschiedliche Möglichkeiten.
Ansonsten kann man noch über Erweiterungen nachdenken.
[Edit]Stimmt, Du hast Recht. Das fehlt noch.[/EDIT]

Zitat:

- Warum kein XML für die Datendatei?

Habe ich wieder verworfen. Gegen XML-Dateien habe ich nichts. Aber die Zugriffsmöglichkeiten waren mir nicht felexibel genug. Ich habe mich einge Zeit daran versucht und XML dann als zu starr verworfen.
Es ist ja auch für andere Zwecke gedacht.

Zitat:

Mit dem Release von XE2 haste dir einen ungünstigen Zeitpunkt rausgesucht

Ich hatte David gefragt, ob er´s mal verschieben kann, aber er wollte nicht.

[mquadrat]

Unsere aktuell eingesetzten Bausteine sind doch noch sehr zurückhaltend.

Wir haben zwar ein Tool zur Code-Generierung der Klassen, das allerdings kaum bis gar nicht genutzt wird Die Geschäftslogik steckt in Klassen mit einer gemeinsamen Basisklasse, die das Active Record - Pattern umsetzt. Jedes Objekt kann sich also selbstständig laden und speichern ohne Mapper. Eine entsprechende Listenklasse gibt es auch, allerdings noch ohne Generics, da für D2007 entwickelt. Die Anbindung an die GUI wird derzeit über manuell geschriebenen Glue-Code realisiert, wobei es für die Listenklassen Adapter gibt um sie mit Grid oder Combobox zu verbinden. Die Validierung wird ebenfalls als Adapter zwischen Control und Objekt realisiert. Constructor Injection für Abhängigkeiten wird verwendet, allerdings nicht automatisiert.

Zukünftig wird es eher in Richtung ORM gehen (wahrscheinlich Attribut oder XML basiertes Mapping). Dazu wird die Datenbindung entweder aus DSharp oder XE2 kommen. Als GUI-Pattern wird aller Vorausicht nach MVVM zum Einsatz kommen, sowie ein Convention-Over-Configuration Layer, der die Data-Bindings automatisch generiert. Dependency Injection entweder aus DSharp oder Spring oder was eigenes.

Aktuell bin ich noch am Ausprobieren, was ich wie haben will und welche Blöcke man von wo benutzen kann, so dass es am Ende ein halbwegs durchgängiges Konzept gibt.

[stahli]

Ich will mal wieder...

Zitat:

Wir haben zwar ein Tool zur Code-Generierung der Klassen, das allerdings kaum bis gar nicht genutzt wird

Warum nutzt Ihr den Codegenerator nicht? Man kann sich doch damit Stunden Arbeit sparen (vorausgesetzt, er arbeitet komfortabel und der Code ist flexibel bearbeitbar).

Zitat:

Die Geschäftslogik steckt in Klassen mit einer gemeinsamen Basisklasse, die das Active Record - Pattern umsetzt. Jedes Objekt kann sich also selbstständig laden und speichern ohne Mapper.

Wohin speichert Ihr? In eine SQL-Datenbank? Wie realisiert Ihr nachträgliche Änderungen der Datenstrukturen?

Zitat:

Eine entsprechende Listenklasse gibt es auch, allerdings noch ohne Generics, da für D2007 entwickelt.

Die Generics sparen ja nur Tipparbeit. Das fällt nicht in´s Gewicht, wenn man die Klassen automatisch generieren lässt. Im Gegenteil sind generische Klassen eher störend, wenn man die RTTI für die Serialisierung einsetzt, da die Vererbung dann immer von TObject erfolgt.

Zitat:

Die Anbindung an die GUI wird derzeit über manuell geschriebenen Glue-Code realisiert

Glue-Code für die Datenbindung ist bäh Jedenfalls würde ich das immer lieber direkt zur Designzeit im Objektinspektor erledigen.

Zitat:

Zukünftig wird es eher in Richtung ORM gehen (wahrscheinlich Attribut oder XML basiertes Mapping)

Und welcher ORM schwebt Dir vor? (Win32 setze ich mal voraus)

Zitat:

Dazu wird die Datenbindung entweder aus DSharp oder XE2 kommen. Als GUI-Pattern wird aller Vorausicht nach MVVM zum Einsatz kommen, sowie ein Convention-Over-Configuration Layer, der die Data-Bindings automatisch generiert. Dependency Injection entweder aus DSharp oder Spring oder was eigenes.

Wie ist denn das grundsätzlich mit DSharp + XE2? Angenommen ich schiebe in der Datenschicht eine Berechnung an, in die 10 Sekunden braucht und rekursiv dutzenden Objekteigenschaften ständig neue Werte zuweist. Wird dann jede Wertänderung in der GUI direkt abgebildet?
Bei meinen odControls wird die GUI erst veranlasst, sich neu zu zeichnen, wenn die Datenschicht mit der Neuberechnung fertig ist.
Daher kann ich mir auch eine Client-Server-Lösung vorstellen. Die Clients werden beauftragt, sich neu darzustellen, wenn der Server neue Daten vorliegen hat. Alle sichtbaren Controls zeichnen sich dann neu und rufen dafür ihre aktuellen Daten ab (genaue Lösungsansätze habe ich aber noch nicht).


Zu Deinen früheren Anmerkungen:

Du hattest Recht mit Deinem Hinweis auf den zu einfachen Klasseneditor. Ich merke das jetzt, da mein Projekt komplexer wird selbst. Ich werde also mal noch einen komfortableren Editor erstellen, der dann eine bessere Übersicht über die verfügbaren Klassen, Typen und Beziehungen bringt.



Es ist halt schade, wenn in dem Bereich jeder sein eigenes Süppchen kocht. Ich hätte ja gern auf eine vorhandene Lösung zurückgegriffen, aber habe leider nix passendes gefunden...

[mquadrat]

Ja, wir speichern in eine SQL-Datenbank (Firebird). Bei einer Änderung von Strukturen (sprich: neue Felder) werden die in den Tabellen und in den Objekten von Hand hinzugefügt. Ist kein wirklich großer Aufwand. Aktualisierung der Kunden-Datenbanken über Delta-Listen.

Generics fallen imho extrem ins Gewicht. Je komplexer die Geschäftslogik umso mehr. Wir haben tausende Casts in der Anwenung, die - theoretisch - auf einen Schlag weg wären. Erhöht die Lesbarkeit enorm.

Bislang habe ich in Delphi noch keinen ORM gefunden, der mir wirklich gefallen hat. Gute Ansätze, aber die Projekte schlafen nach nem halben Jahr meist ein. Mal schauen was Spring bringt. Ansonsten halt selber schreiben.

Im Endeffekt kommt es ja drauf an wann man die Notification schickt. Wäre also nicht sonderlich kompliziert ein BeginUpdate...EndUpdate einzubauen.

[Stevie]

So, ich hab mir das jetzt auch mal angeschaut - bin ich blind oder wo ist der Source Code?

Ich mein, nix gegen deine Videos, aber wo kann man das selber ausprobieren? Ich hab immer nen Problem, wenn mir jemand, der was programmiert hat, vorführt, wie doll das alles funktioniert, ohne dass ich es selber auf Herz und Nieren prüfen kann. Ist mir schon oft passiert - bei der Präsentation alle staunend da gesessen und hinterher geflucht, wenn mans selber benutzen musste. (nein, ich meine nicht FireMonkey )

Zum Experten teile ich die Meinung von mquadrat. Da hätt ich auch den Interface Teil einer Unit schreiben können und der Experte erzeugt mir den Implementation Teil. Auch das Format scheint mir etwas eigenwillig. Schau dir mal ModelMaker an, damit kann man sowas auch machen, eventuell gibt das noch die eine oder andere Idee.

Die Controls an sich find ich prima. Allerdings erschließt sich mir noch nicht ganz, wie weit sie in das ganze System verflochten sind. Den Tree zum Auswählen der Eigenschaften find ich auch gut (muss ich mal in meine Bindings einbauen *g*). Woran macht er fest, welche Eigenschaften angezeigt werden? Nur die mit den Attributen?

Ein bisschen flau wurde mir ehrlich gesagt bei der Turnier Klasse, das sah mir sehr nach god object aus, in dem alles drin steckt.

Bei der Generierung der Klassen musste ich an code first denken.

@mquadrat: Gib mir ruhig Feedback, wenn die beim Einsatz von DSharp für dein Projekt noch was auffällt oder fehlt. Hab noch einiges auf meiner Todo Liste stehen, was DSharp angeht - nur zu wenig Zeit (und manchmal auch keine Lust *g*)

[stahli]

Zitat von Stevie:

So, ich hab mir das jetzt auch mal angeschaut - bin ich blind oder wo ist der Source Code?
Ich mein, nix gegen deine Videos, aber wo kann man das selber ausprobieren? Ich hab immer nen Problem, wenn mir jemand, der was programmiert hat, vorführt, wie doll das alles funktioniert, ohne dass ich es selber auf Herz und Nieren prüfen kann. Ist mir schon oft passiert - bei der Präsentation alle staunend da gesessen und hinterher geflucht, wenn mans selber benutzen musste. (nein, ich meine nicht FireMonkey )

Ich wollte erst einmal grundsätzlich sehen, was Ihr von der Lösung haltet. In der Form kannte ich bisher noch kein Framework.
Ich selbst komme mit dem aktuellen Stand schon sehr gut zurecht - geht aber vermutlich jedem Entwickler so Wenn ein breiteres Interesse bestanden hätte, hätte man natürlich noch einiges an der Benutzbarkeit optimieren können. So erweitere ich die Klassen nach und nach entsprechend Notwendigkeit und verfügbarer Zeit.
Ich schicke Dir mal einen Link zu einer Testversion per pn. Es gibt aber noch keinen Installer und keine Hilfe und es kann an einigen Stellen schon noch etwas hakeln.
In den Videobeispielen zu School-Projekt (Beitrag #6) sind die notwendigen Schritte erklärt. Es ist nicht sehr kompliziert, aber ein paar Dinge sind natürlich zu beachten.

Zitat von Stevie:

Zum Experten teile ich die Meinung von mquadrat. Da hätt ich auch den Interface Teil einer Unit schreiben können und der Experte erzeugt mir den Implementation Teil. Auch das Format scheint mir etwas eigenwillig.

Die Meinung teile ich inzwischen auch. Ich plane deshalb durchaus einen Editor, in dem man Klassen und Typen z.B. per ComboBox auswählen kann. Das wäre schon noch deutlich komfortabler, aber es geht erstmal auch mit dem Texteditor ganz gut. Einen UML-Designer plane ich definitiv nicht. Erstens wäre das zu aufwendig und ich will den die Klassendeklaration außerdem möglichst nah am Aufbau der zu erzeugenden Units halten.
Die cla-Datei stellt somit eine Übersicht über die erzeugten Units dar, allerdings nur auf die Daten bezogen.
Da die erzeugten Units auch die kompletten Referenzen der Datenobjekte aufeinander realisieren, würdest Du mit dem schreiben des interface-Teils nicht weit kommen. Der odExperte übernimmt da noch einiges mehr.

Zitat von Stevie:

Schau dir mal ModelMaker an, damit kann man sowas auch machen, eventuell gibt das noch die eine oder andere Idee.

Das stimmt. Wenn ich den gekannt hätte, hätte ich es vielleicht auch einmal damit versucht. Allerdings kann ich nicht wirklich beurteilen, wie flexibel das Ganze ist. Lassen sich die Klassen denn problemlos mit beliebigen Funktionen und Prozeduren erweitern und vor allem auch debuggen? Vielleicht teste ich das später einmal.
Meine Lösung ist natürlich optisch nicht so aufwendig, dafür lassen sich die erzeugten Klassen sehr flexibel erweitern und verändern.
Dazu ist das Speichern und Laden automatisch implementiert und es gibt eine Datenbindung an die Formulare (wobei es dafür natürlich nun auch andere Lösungen gibt).

Zitat von Stevie:

Die Controls an sich find ich prima. Allerdings erschließt sich mir noch nicht ganz, wie weit sie in das ganze System verflochten sind.

Was meinst Du? Ich nutze statt einem TEdit ein TodEdit usw. Die odControls enthalten ein TodDataSet, das eine Datenkomponente und den gewünschten PropertyName zugewiesen bekommt.
Die odDataSets werden über Änderungen in der Datenschicht informiert und veranlassen ihren Owner, sich neu zu zeichnen. Sicher könntest Du das noch geschickter lösen.

Zitat von Stevie:

Den Tree zum Auswählen der Eigenschaften find ich auch gut (muss ich mal in meine Bindings einbauen *g*). Woran macht er fest, welche Eigenschaften angezeigt werden? Nur die mit den Attributen?

Genau.

Zitat von Stevie:

Ein bisschen flau wurde mir ehrlich gesagt bei der Turnier Klasse, das sah mir sehr nach god object aus, in dem alles drin steckt.

Würde ich nicht so sagen. Das TournamentEvent-Objekt kennt die Sportart, den Ort und die Turniere und kann mit diesen umgehen.
Die genannten Objekte selbst haben wieder ihre eigenen Unterobjekte und eine eigene Geschäftslogik. Das ist doch ok, oder?

Zitat von Stevie:

Bei der Generierung der Klassen musste ich an code first denken.

Weiß nicht recht, kann sein...