@mquadrat
Vielen Dank für die Rückinfo!!
Experte / Code Generation
Zitat:
Der Experte hat
IMHO zwei Nachteile. Erstens hat man innerhalb des Experten, also beim Definieren der Metadaten, keinerlei Hilfen. Man kann sich also beliebig vertippen. Hier wären ggf. Tabellen zum Ausfüllen, in denen man über ComboBoxen die Typen auswählen kann, besser geeignet.
Das hatte ich ursprünglich vor, dann aber in der Praxis als unnötig verworfen. So muss man in den Metadaten nicht vorab bestimmte Typen registrieren. Man kann einfach TMyType verwenden und den ggf. später einfach im Projekt nach Bedarf deklarieren. Und Tippfehler können auf Knopfdruck korrigiert werden.
Zitat:
Desweiteren macht man eine Programmierung in der Programmierung auf. Das ist ein klassischer Fall von "Ist-Halt-So" und konzeptbedingt.
Was meinst Du genau?
Zitat:
Wenn man schon ein Modell der Daten aufbaut, dann könnte man weitere Metadaten integrieren. Ich denke da an Maximallängen für Strings, Reguläre Ausdrücke, denen die Einträge entsprechen müssen oder auch die Kennzeichnung von Pflichtangaben (not null). Bis auf die regulären Ausdrücke brauchst du das sowieso, wenn du später mal per Forware Engineering die passenden Datentabellen in einem RDBMS erzeugen willst.
Es soll definitiv kein OR-Mapper werden.
Zitat:
Die Code-Generierung sieht ganz gut auch das Reagieren auf verwänderten Source-Code. Wobei man eine Option anbieten sollte, dass veränderte Getter/Setter so beibehalten werden wie sie sind. Wenn ich mir große Klassen vorstelle, die mir jeden Getter / Setter um die Ohren hauen, den ich verändert habe, nur weil ein neues Feld dazu gekommen ist, dann verliert man schnell die Lust.
Ach ja und für meinen Geschmack sind es etwas arg viele Regionen
Die Getter/Setter und anderen erzeugten Quelltext-Abschnitte werden bei Änderungen der Datenstrukturen
immer automatisch angepasst.
Die gezeigten ("Fehler")-Hinweise treten nur auf, wenn eine Eigenschaft geändert werden soll, an der der Programmierer zwischendurch händische Änderungen vorgenommen hat (also z.B. in einem Setter). Andere Eigenschaften kann man beliebig hinzufügen, ändern oder löschen. Sofern man keine nochträglichen Änderungen an einer Eigenschaft vorgenommen hat, kann man diese jederzeit problemlos ändern. Der Experte merkt sich dazu jede Region und prüft diese auf händische Änderungen, bevor der Experte etwas verändern will. Will der Experte an einer Region nichts ändern, bleiben natürlich alle händische Veränderungen im Quelltext enthalten.
Zitat:
Was ich jetzt noch als offene Frage hätte, wäre wie man mit Fremdunits umgeht. Also beispielweise mit Klassen, die vom
WSDL Importer von Delphi erstellt wurden und zur Kommunikation mit Webservices dienen. Müsste man die Strukturen duplizieren und einen Adapter schreiben? Oder kann man die dem Datenmodell irgendwie "unterschieben"?
Da muss ich passen.
(WDSL habe ich nie verwendet.)
Aber grundsätzlich kann man sowohl die
Unit-Vorlage selbst jederzeit ändern als auch als BasisObjekt ein eigenes vorgeben (z.B. TodForWDSL), das von Tod abgeleitet wird und bestimmte Eigenschaften und Methoden implementiert. Falls es interessiert, könnte ich das mal an einem Beispiel zeigen.
Datenbindung und Controls
Zitat:
Den TreeView für die Datenbindung finde ich sehr schick. Da kann man schön durchnavigieren. Nun bin ich ja aber ein Fan des ViewModels, also eines Modells je View (wie der Name sagt
). Das fehlt mir so ein bisschen. Sicher kann man einen Teil der Validierungslogik über zusätzliche Metadaten (siehe Punkt 1) abfangen, möchte ich aber beispielsweise eine Funktion nur dann erlauben wenn in zwei Feldern eine Kombination aus bestimmten Werten steht, dann müsste ich das wieder in das Form bzw. einen neuen zusätzlichen Controller packen. Da dein Konzept aber ja ein anderes ist, kann man das den Komponenten nicht vorwerfen
Das ist richtig. Die odControls sind wie
DB-Komponenten zu verwenden und zeigen definierte Daten von Objekten an. Es gibt auch diverse Listenkomponenten, die Listen von Objekten darstellen und bearbeiten. Alles weitere ist im
GUI-Quelltext zu regeln (z.b. ein/ausblenden von Controls usw).
Zitat:
Was die Controls angeht hat man ja prinzipiell zwei Möglichkeiten: Entweder ich vererbe neue Controls (so wie du) oder ich erstelle Adapter, die die Bindung an die Controls übernehmen. Mit den Adaptern ist man, wie ich finde, flexibler. Man kann natürlicha auch beides mischen.
Auch richtig. Die odControls sind da quasi ein Zwischenweg.
App-Framework insgesamt
Zitat:
Nun hat man zwar keine Implementierung gesehen, aber rein vom Gefühl würde ich sagen, dass teilweise zu viel in den Framework-Klassen passiert. Der Experte scheint mir für zu viel zuständig zu sein. Solltest du das intern über viele kleine und leichtgewichtige Klassen gelöst haben, die du nach außen versteckst, dann gilt mein Argument natürlich nicht
Hmm. Der Experte erstellt nur die Datenklassen (also Klassen mit deren benötigten Eigenschaften).
In den odControls kümmern sich dann bestimmte Objekte im Hintergrund um die Kommunikation zwischen Datenebene +
GUI (sowohl zur Design- als auch zur Laufzeit).
Zitat:
Die Funktionsweise der File-Klasse ist mir noch nicht so ganz klar. Serialisiert die die Daten selber oder fordert die die Daten auf sich selbst zu serialisieren? Auch hier wären ggf. Adapter interessant um verschiedene Persistierungsarten zu ermöglichen.
Die File-Klasse veranlasst das Basisobjekt, sich zu serialisieren und dieses veranlasst dann wiederum seine entsprechenden SubObjekte. Beim lesen werden SubObjekte automatisch erzeugt und untereinander verlinkt.
Hier kann man natürlich unterschiedliche Arten der Serialisierung implementieren (habe ich z.B. genutzt für die TreeView im Propertyeditor).
Zitat:
Ich habe übrigens absichtlich App-Framework geschrieben. Du hast einen Experten, der über ein Modell der Daten Code generiert. Du hast eigene Controls. Wenn du jetzt noch etwas mehr Handling für das Application Lifecycle integrierst, dann hast du im Grunde ein eigenes App-Framework gebaut.
Das ist sicher etwas übertrieben. Es werden letztlich normale Controls verwendet. Lediglich die Datenklassen werden automatisch (bzw. komfortabel) erzeugt und serialisiert sowie leicht an die
GUI gebunden.
Zitat:
Was noch schön zum Konzept passen würde, wäre das Anbieten einer Reihe von Services (Mailversand, oder, oder, oder), die du zur Verfügung stellts. Ergo, alles was außerhalb der eigentlichen Geschäftslogik vor sich geht.
Man arbeitet ja letztlich ganz einfach nur mit Objekten und kann somit alles regeln und vererben, was man mit Objekten regeln kann.
Man erspart sich im Grunde nur jede Menge Tipparbeit, arbeitet aber ansonsten mit ganz normalen Objekten und Controls.
Zitat:
So, das mal als ersten Eindruck.
Großen Dank nochmal!
@mschaefer
Ich meinte nicht das Registrieren von Komponenten in ein Register sondern das Hinzufügen einer erzeugten
Unit zu einem bestimmten
Package (also wie über die Projektverwaltung). Das ist sicher nicht so einfach, hat aber auch noch Zeit.