[stahli]

Grundsätzliches:

Ich möchte Euch meine Komponenten vorstellen, mit denen man sowohl Datenklassen erstellen und ändern als auch Daten speichern und laden und letztlich diese auch mit minimalem Aufwand an die GUI anbinden kann.

Mein Anliegen war es insbesondere, eine flexible Programmierung zu ermöglichen und bei der eigentlichen Projekterstellung mit möglichst wenig Aufwand arbeiten zu können.
Dabei will ich komplett objektorientiert arbeiten (da dies m.E. die beste Flexibilität ermöglicht) und auch dem User (Endanwender) ein komplettes objektorientiertes Handling anbieten. Der User soll, wo immer es geht, Objekte sehen und diese bewegen können.

-> Video od1


Datenklassen - der odExperte:

Die odControls sollen dabei alle notwendigen Datenfunktionen selbständig initiieren und durchführen, so dass der Programmierer sich auf die Geschäftslogik (Methoden, Berechnungen etc.) und die GUI (Platzierung der Komponenten auf den Formularen beschränken kann.

Weiterhin sollen auch spätere Erweiterungen und Änderungen der Datenstruktur möglichst problemlos zu realisieren sein - und zwar direkt innerhalb der IDE.

-> Video od2


DataBinding:

Die Komponenten beinhalten ein DataBinding (allerdings nur untereinander, es können als nur die odData- an die odVisible-Controls gebunden werden). Andere Objekte lassen sich nicht an die odControls binden.

-> Video od3


Aussichten:

Es sind natürlich noch einige Erweiterungen und Verbesserungen geplant.
Insbesondere will ich versuchen, den odExperten noch besser in die DIE zu integrieren. Vor allem wäre es wünschenswert, die erzeugten Units automatisch in ein bestimmtes Package „einzuladen“. Ich werde versuchen, dieses Feature später zu realisieren.

Ein wesentlicher Nachteil der odControls ist, dass derzeit alle Daten komplett im Speicher verwaltet werden. Dies kann natürlich Probleme bei sehr großen Datenmengen verursachen (allerdings gibt es auch bei sehr großen Turnierveranstaltungen bisher keine Probleme) und es ist derzeit auch nicht möglich, die Daten von mehreren Clients aus gleichzeitig zu verwenden.

Zur Lösung der beiden Probleme habe ich bereits die Anbindung einer Datenbank vorgesehen. Diese soll jedoch lediglich als reines „Datenlager“ dienen. Einen OR-Mapper plane ich definitiv nicht. Die komplette Datenstruktur und Geschäftslogik soll auf jeden Fall weiter in den Datenobjekten verbleiben.

Die Datenbank würde dann lediglich die Objektstruktur, etwa:
-> ObjOwner, ObjClass, ObjId, Pos
und die Objektdaten, etwa:
-> ObjectId, PropName, PropValue
verwalten.

Ein alternativer/zusätzlicher Lösungsansatz könnte sein, die Daten auf einem „Server“ zu verwalten (der müsste in meinem Fall eine TodTournamentEvent bekommen), der alle Daten und die komplette Geschäftslogik beinhaltet und „GUI-Clients“ (ohne eigene Datenkomponeten) anzubinden, die die Objektdaten vom „Server“ bei Bedarf abrufen und Änderungen verschicken.
Es müssten immer nur diejenigen sichtbaren Controls Daten abrufen, die gerade gezeichnet werden. Nicht sichtbare Controls (z.B. in ausgeblendeten Registern oder Formularen) würden keinen Datentransfer verursachen.

Meine weiteren Verfahrensweisen und die genauen Implementierungen sind noch offen und auch davon abhängig, ob und wie weit Interesse von Euch oder Dritten besteht. Daher...


...meine Bitte:

Ich würde mich freuen, wenn Ihr Euch einmal die Zeit nehmt, euch die odControls (jedenfalls die Vorschauvideos) einmal anzuschauen.

Ich bin für jede Rückäußerung sehr dankbar, auch wenn Ihr das Konzept misslungen oder (für Euch) uninteressant findet.

Ich selbst werde mit Sicherheit weiter damit arbeiten (weil ich so einfach und flexibel bisher nicht entwickeln konnte), aber es interessiert mich natürlich dennoch sehr, was Ihr von den odControls haltet...

Also einfach drauf los



Und noch mal großen Dank an die gesamte DP!!!



EDIT: Weitere Beispielvideos im Beitrag #6

Hallo stahli,

werd mich mit dem Videomaterial mal ins Freie gesellen bei dem Wetter Rückmeldung gibts dann später. Ordentlich Arbeit hast du dir ja schon mal gemacht - alleine die Videos zu erstellen^^

Schöne Grüße,
Florian

Zitat von Stahli:

Vor allem wäre es wünschenswert, die erzeugten Units automatisch in ein bestimmtes Package „einzuladen“.

Könnte mir vorstellen, dass Du ein Package dauerhaft installiert hast und die Register-Aufrufe der Komponenten in eine extra Unit auslagerst. Dann bräuchtes Du nur diese Registerunit bei uses und procedure Register zu ergänzen und das neu installieren auslösen ( Muss mir die Komponenten mal in Ruhe ansachauen . . .).

So, ich hab mir die Videos jetzt mal angeschaut und würde meine Bemerkungen dann auch wieder aufteilen wollen:

Experte / Code Generation

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. Desweiteren macht man eine Programmierung in der Programmierung auf. Das ist ein klassischer Fall von "Ist-Halt-So" und konzeptbedingt.

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.

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

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"?



Datenbindung und Controls

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

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.


App-Framework insgesamt

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

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.

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. 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.




So, das mal als ersten Eindruck.

@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.

Hallo Männer (und die Mädels auch),


ich bin überrascht, dass mein Beitrag hier dermaßen untergegangen ist.

Ich will nicht glauben, dass das wirklich so passieren konnte - NEIN, das will ich nicht - NEIN!
Viel mehr will ich glauben, dass ich das Konzept vielleicht zu theoretisch erklärt habe und Ihr nicht nachvollziehen konntet, was das Ganze soll...


Daher habe ich noch einmal ein kleines, an der Praxis orientiertes Testprojekt erstellt, das von Anfang an zeigt, wie man eine Anwendung mit den odControls aufbauen kann.
Ursprünglich wollte ich eine kleine "Schulverwaltung" erstellen, in der man Lehrer, Schüler und ein paar Fahrzeuge (o.ä.) verwalten kann.
Um das Ganze nicht noch mehr in die Länge zu ziehen, habe ich mich dann doch auf ein paar Testobjekte beschränkt (es geht ja nur um die Arbeitsweise).

Im wesentlichen erkennt man, dass
- man für die Datenklassen keinen Code schreiben muss
- die Daten (automatisch) von der GUI getrennt sind
- die Bindung der Daten und GUI in der IDE einfach durch Selektion der gewünschten Eigenschaft erfolgt
- in der GUI nahezu nichts programmiert werden muss.

Sicher sind die odControls noch ausbaufähig und an einigen Stellen noch zu optimieren, mir geht es im Moment jedoch auch erst einmal um die grundlegende Arbeitsweise.

Ich würde mich daher freuen, wenn Ihr Euch doch einmal die Zeit nehmt, Euch das anzuschauen. Es ist eine (aus meiner Sicht) ziemlich neue Arbeitsweise mit Delphi.
Jedenfalls hätte ich so etwas früher gern genutzt, habe aber nie eine ähnliche Lösung gesehen.

ECO unter .net war von der Grundidee her vielleicht ähnlich, wenngleich ein anderer Ansatz dahinter steckte. Leider hat dies (nach meinen Erfahrungen nicht stabil funktioniert.

Die XE2-Datenbindung steht natürlich in den Startlöchern und Stevies Lösung ohnehin. Vielleicht lässt sich meine Datenbindung durch diese Lösungen ersetzen, wobei die Datenbindung nur einen Teil der odControls darstellt und meine Lösung auf das Zusammenspiel meiner Controls optimiert ist.


Bei der Verwendung der odControls arbeitet man mit ganz klassischen Delphi-Objekten, die die Daten und die Geschäftslogik implementieren. Bei der Erstellung der Objekte bzw. Klassen hilft ein Experte, so dass man diese nicht selbst schreiben muss (außer die Geschäftslogik).
Die odControls kümmern sich dann automatisch um das Speichern und Laden der Daten und um die Kommunikation der Daten mit den GUI-Controls (Formularen) ... zur Run- und Designtime.

Die Möglichkeit, an den Klassen zu arbeiten und dennoch jederzeit Änderungen an den Datenstrukturen vorzunehmen, habe ich bisher noch nirgens gefunden. Man war dann doch immer irgendwo limitiert und konnte nicht beliebig flexibel an den Klassen arbeiten.

Ich hätte erwartet, dass die Lösung auf eine Resonanz trifft ("breitere Resonanz" wäre hier falsch formuliert), da es sich ja um einen ganz allgemeinen Ansatz handelt, den irgendwann jeder mal nutzen könnte.
Daher nun noch mein zweiter Versuch - vielleicht wird das Konzept ja etwas verständlicher durch ein praktisches Beispiel.


Es wäre nett, wenn Ihr mal die eine oder andere Folge "verbotene Liebe" ausfallen lasst und Euch statt dessen mein Gestammel antut...

Vielleicht bin ich ja aus Eurer Sicht auf einem Holzweg - dann könnt Ihr es gefahrlos sagen...
Vielleicht gibt es bessere Lösungen für eine solche Arbeitsweise - dann immer her damit...
Habt Ihr vielleicht ähnliche (oder bessere) Lösungen selbst entwickelt? Warum hört man dann nix davon?

Ok, wenn es Euch nicht interessiert, dann lässt es sich nicht ändern...



Also hier mein letzter Versuch:

Bis zum Video 03 (ich hatte mit der Projektvorbereitung mit 00 angefangen, da ich das noch nichts weiter mit den odControls zu tun hat) erkläre ich - das ist zugegebener Maßen etwas trocken - die Vorbereitungen und die Datendefinition.
Mehr zu sehen gibt es dann ab 04. Wer nur mal einen schnellen Blick werfen will, dann vielleicht besser ab dort...
Zum besseren Verständnis der Arbeitsweise und des grundsätzlichen Konzeptes sind aber die vorherigen Videos wichtig (ein Projekt fängt man ja am Anfang an )


http://www.stahlisoft.de/videos/scho...school-00.html (3 Min)
- Projekterstellung (allgemeine Vorbereitung)
- Formularanwendung, Package + Projektgruppe


http://www.stahlisoft.de/videos/scho...school-01.html (11 Min)
- erste Experten-Verwendung
- Benutzug der erstellten Units (Klassen)


http://www.stahlisoft.de/videos/scho...school-02.html (9 Min)
- Trennung GUI + Daten im Projekt (DataModule)
- Formularvorbereitung
- erste Datenbindung (4. Min)
- erster Projektstart


http://www.stahlisoft.de/videos/scho...school-03.html (21 Min)
- Komplexere Datenstruktur + neue Klasse
- Änderung der "Geschäftslogik"


http://www.stahlisoft.de/videos/scho...school-04.html (10 Min)
- Daten in Listen


http://www.stahlisoft.de/videos/scho...school-05.html (6 Min)
- andere Listendarstellung
- die gleichen Daten im TabControl


http://www.stahlisoft.de/videos/scho...school-06.html (15 Min)
- spezialisierte Darstellungsobjekte


http://www.stahlisoft.de/videos/scho...school-07.html (7 Min)
- spezialisierte Bearbeitungsformulare
- (Die Zuweisung der odFormCtrl wird noch vereinfacht.)


Die odControls enthalten noch einige Komponenten, die hier noch nicht zu sehen waren. So z.B. einen Designer, auf den der Endanwender Objekte aus einer Palette ziehen und dann beliebig anordnen und bearbeiten kann. Einiges davon kann man in meiner Turniersoftware auf meiner Homepage sehen.


So. Bin nochmal gespannt...

Evtl. Meinungen bitte hier.
Bei Interesse am Testen bitte per pn (Die Controls sind eigentlich noch in der Entwicklung und Hilfen gibt es noch keine.)

Falls jemand einen Vorschlag für ein anderes Demoprojekt hat, da könnte man auch drüber reden...


PS: Über meine Englisch-Versuche bitte nicht so laut lachen, dass ich es hören kann...

Zitat von stahli:

(...)
ich bin überrascht, dass mein Beitrag hier dermaßen untergegangen ist.

(...)
Ich will nicht glauben, dass das wirklich so passieren konnte - NEIN, das will ich nicht - NEIN!

(...)
Ich würde mich daher freuen, wenn Ihr Euch doch einmal die Zeit nehmt, Euch das anzuschauen. Es ist eine (aus meiner Sicht) ziemlich neue Arbeitsweise mit Delphi.

(...)
Ich hätte erwartet, dass die Lösung auf eine Resonanz trifft ("breitere Resonanz" wäre hier falsch formuliert), (...)

(...)
Es wäre nett, wenn Ihr mal die eine oder andere Folge "verbotene Liebe" ausfallen lasst und Euch statt dessen mein Gestammel antut...

Abwarten und Kaffee trinken!

Edit: Ich kann dir leider kein Feedback geben, da ich nicht viel mit Datenbanken zu tun habe, aber ich bin mir sicher, du hast tolle Arbeit geleistet. Sei halt nicht so offensichtlich ungeduldig! xD

Na ja, etwas ironisch waren die Sätze schon gemeint.
Ich wollte aber mal einen 2. Versuch unternehmen, da der Kaffee nach gut 3 Wochen kalt ist...

Zu Deinem Edit: Mit Datenbanken hat das nichts zu tun, nur mit dem Umgang mit Daten in einem Projekt.

Das ist ja gerade mein Problem:
- Ich weiß nicht, wer es sich überhaupt mal angesehen hat.
- Ich weiß nicht, wer verstanden hat worum es geht (kein Vorwurf! Ich verstehe auch viele Konzepte nicht, vor allem wenn sie schlecht oder englisch erklärt werden).
- Es wäre ja denkbar, dass das Prinzip schon interessant wäre, wenn ich es ausreichend erkläre.
- Kann auch sein, dass ich in einer anderen Welt lebe und das alles Quatsch ist (aber ein paar Jahre programmiere ich ja nun auch schon).

Ich drängle nicht gern (ist auch das erste Mal) - aber diesmal musste es sein...

Sorry


[EDIT]Der neue Kaffee dampft. Du hast Recht - es geht wieder besser! [/EDIT]

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

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.