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.
