wie abspeichern?

[glkgereon]

aber ich hätte dann eine datei in der form:

Code:

[Name]
Unfall mit 30-Tonner
[Lauftext]
35-Jähriger erleidet schwere verletzungen an armen und beinen
[Text]
blablabla
.....
blablabla
.....
blablabla
.....
[Tipp]
mach dies
mach das
oder dies
oder das

und das ist nicht soo einfach....

wo gibts denn zlib?

is dasn externes prog oder is das ne compo, bzw ne unit, wo entsprechende procedures drin sind?

[Jens Schumann]

Hallo,
ich gehe mal davon aus, das die Patienten in einer Collection (Array, verkettet Liste o TList usw)
gespeichert sind. Dann haben wir hier einen ganz klaren Anwendungsfall der Klasse

Code:

TmxJsCollection

aus der CodeLib
Die einzelnen Patienteneigenschaften sind published properties eines Nachfahren von
TCollectionItem. Dann ist das Speichern eines Memos auch gar kein Problem mehr. Wenn
man sich entschließt noch ein paar Patienteneigenschaften hinzuzufügen bekommt der
TCollection-Nachfahre noch ein paar published properties (können auch Bitmaps sein !!!)
und das wars. Um das Speichern der zusätzlichen properties muss man sich nicht kümmern.
Läuft automatisch!!!

[glkgereon]

also ich benutz diese unit, und dann?

als was muss ich meine "datenbank" dann deklarieren bzw wie kann ich diese benutzen?

[Jens Schumann]

Zitat von glkbkk:

also ich benutz diese unit, und dann?

als was muss ich meine "datenbank" dann deklarieren bzw wie kann ich diese benutzen?

Ich vermute mal, du meinst mich.
Es reicht natürlich nicht die unit zu verwenden. Du musst Dir auch das Beispiel anschauen und
nachvollziehen. Der Aufwand lohnt sich. Wenn Du den Source und die OOP dahinter verstanden
hast, wirst Du erkennen, dass das Gespann TCollection/TCollectionItem einfach genial ist.

Jeder Patient wird durch ein Objekt repräsentiert. (Das sollte in den Zeiten der OOP natürlich
selbstverständlich sein). D.h. alle Patienteneigenschaften werden in den published properties
eines TCollectionItem-Nachfahren repräsentiert. TmxJsCollection verwaltet dann die einzelnen
PatientenObjekte.

Jetzt kommt der MegaVorteil der Sache!!!!!!!!
Wenn Du Dich entschließt zu den Patienten ein Bild zu speichern erweiterst Du das PatientenObjekt
um eine TBitmap Eigenschaft (natürlich im published Abschnitt). Das wars!!! Das Bild wird automatisch gespeichert. Wenn Du noch Dateien mit alten Patientendaten (ohne Bild) hast können die Dateien trotzdem gelesen werden. Das wäre bei einer typisierten Datei nicht der Fall.

[maximov]

Genau,

TmxJsCollection kann ich dir auch nur empfehlen! Da kannst du quasi vollautomatisch das dfm-persistenzierung-system benutzen, das einzige was du machen ist: SaveToFile/loadFromFile

@Jens: Hab für unsere collection ein template erstellt, womit die collection ein user-typ interface hat. Sehr geil, weil man nirgends mehr casten braucht. Werd ich demnächst mal posten.

[Eisenherz]

Zitat von Jens Schumann:

Dann haben wir hier einen ganz klaren Anwendungsfall der Klasse

Code:

TmxJsCollection

aus der CodeLib

Wenn blkbkk damit Leben kann, dass er von TCollectionItem ableiten muss und nicht zu erwarten ist, dass die Datenstrukturen komplizierter werden, dann dürfte das der einfachste Weg sein. Ich finde es gut, dass mal jemand daran gedacht hat, dass man auch noch alte Dateiformate einlesen kann.

Wenn die Datenstrukturen aber komplexer werden, dann vermute ich, dass TmxJsCollection an seine Grenzen stoßen wird.

Da wäre z.B. Polymorphie.
Nehmen wir an blkbkk würde von der Klasse TPatient die Klassen TKassenPatient und TPrivatPatient ableiten. Er könnte die Instanzen dieser Klassen nicht in einer Collection halten, da Collections nur die Instanzen einer Klasse halten können.

Datenkapselung:
Es können nur published-Properties automatisch gespeichert werden. Das Speichern von Daten mit einer anderen Sichtbarkeit ist dann nicht mehr ganz so einfach.

Und was macht man, wenn man aus irgendeinem Grund nicht von TCollectionItem ableiten kann?

[Jens Schumann]

Zitat von Eisenherz:

Wenn die Datenstrukturen aber komplexer werden, dann vermute ich, dass TmxJsCollection an seine Grenzen stoßen wird.

Eben nicht. TmxJsCollection kann n-dimensionale Strukturen speichern. Außerdem können die published
Properties auch wiederum Objekte sein. Diese Objekte müssen aber min von TPersistent abgeleitet sein.

Zitat von Eisenherz:

Da wäre z.B. Polymorphie.
Nehmen wir an blkbkk würde von der Klasse TPatient die Klassen TKassenPatient und TPrivatPatient ableiten. Er könnte die Instanzen dieser Klassen nicht in einer Collection halten, da Collections nur die Instanzen einer Klasse halten können.

Aber genau das ist der klassische Anwendungsfall von Polymorphie (also der innerste Sinn der OOP)
Die Collection verwaltet dann Klassen vom Type TPatient. Da TKassenPatient und TPrivatPatient Nachfahren
von TPatient sind gibt es hier keine Probleme. Die Klassen müssen naturlich OOP mäßig gestylt sein.
Siehe TStrings und ff.

Zitat von Eisenherz:

Datenkapselung:
Es können nur published-Properties automatisch gespeichert werden. Das Speichern von Daten mit einer anderen Sichtbarkeit ist dann nicht mehr ganz so einfach.

Wozu auch. Dann deklariert man die Properties eben als published. Wenn man unbedingt möchte das public properties gestreamt werden kann man noch mit DefineProperties arbeiten (überschreiben).

Zitat von Eisenherz:

Und was macht man, wenn man aus irgendeinem Grund nicht von TCollectionItem ableiten kann?

Dann hat man wohl Pech gehabt.

[maximov]

Zitat von Jens Schumann:

...Aber genau das ist der klassische Anwendungsfall von Polymorphie (also der innerste Sinn der OOP)
Die Collection verwaltet dann Klassen vom Type TPatient. Da TKassenPatient und TPrivatPatient Nachfahren
von TPatient sind gibt es hier keine Probleme. Die Klassen müssen naturlich OOP mäßig gestylt sein.
Siehe TStrings und ff.

Ich weiss nicht ob ich dich richtig verstehe, oder ob du eisenherz richtig verstehst , aber du kannst tatsächlich nur item von einer klasse in einer kollektion halten! Was dir sicher auch bewust ist? ..das hatte eisenherz nämlich angeprangert.


Wenn man hierarchische strukuren will und verschiedene klassen, dann muss man halt TComponent nehmen oder selbst was schreiben

[Jens Schumann]

Zitat von maximov:

Zitat von Jens Schumann:

...Aber genau das ist der klassische Anwendungsfall von Polymorphie (also der innerste Sinn der OOP)
Die Collection verwaltet dann Klassen vom Type TPatient. Da TKassenPatient und TPrivatPatient Nachfahren
von TPatient sind gibt es hier keine Probleme. Die Klassen müssen naturlich OOP mäßig gestylt sein.
Siehe TStrings und ff.

Ich weiss nicht ob ich dich richtig verstehe, oder ob du eisenherz richtig verstehst , aber du kannst tatsächlich nur item von einer klasse in einer kollektion halten! Was dir sicher auch bewust ist? ..das hatte eisenherz nämlich angeprangert.

Ist ist mir bewußt. Dummerweise aber nicht in dem Moment als ich die Antwort geschrieben habe.

[Eisenherz]

Zitat von Jens Schumann:

Eben nicht. TmxJsCollection kann n-dimensionale Strukturen speichern. Außerdem können die published
Properties auch wiederum Objekte sein. Diese Objekte müssen aber min von TPersistent abgeleitet sein.

Du gehst hier davon aus, dass die Datenstrukturen hierarchisch sind. Solange das der Fall ist und man wirklich von TPersistent ableiten kann, ist deine Lösung super.
Aber oft hat man es mit relationalen Datenstrukturen zu tun. Objekte haben nur Reverenzen auf andere Objekte und sind nicht der Besitzer des anderen Objektes. Man kann sicherlich auch das mit TmxJsCollection lösen, dann ist es aber vorbei mit einfach nur published machen.

Zitat:

Zitat von Eisenherz:

Datenkapselung:
Es können nur published-Properties automatisch gespeichert werden. Das Speichern von Daten mit einer anderen Sichtbarkeit ist dann nicht mehr ganz so einfach.

Wozu auch. Dann deklariert man die Properties eben als published.

Lass das bloß keinen OO-Fanatiker lesen.

Zitat:

Wenn man unbedingt möchte das public properties gestreamt werden kann man noch mit DefineProperties arbeiten (überschreiben)

Das meinte ich mit "nicht mehr ganz so einfach". Mit DefineProperties konnte ich mich nie richtig anfreunden.

Zitat:

Zitat von Eisenherz:

Und was macht man, wenn man aus irgendeinem Grund nicht von TCollectionItem ableiten kann?

Dann hat man wohl Pech gehabt.

Nicht ganz, denn dafür habe ich eine Alternative anzubieten.