So, um das ganze nicht einschlafen zu lassen
dipesh und ich hatten eine feine Diskussion im IRC.
Meine momentane Idee ist, das ganze dreiteilig zu machen.
1) Frontend: regelt den Zugriff auf die Daten, get/set Methoden
2) Container: speichert die Daten, zb in QMaps
3) IO: konvertiert zwischen Container und Außenwelt, zb INI File, XML File, etc.
dipesh möchte die Möglichkeit haben, hierachische Keys zu verwenden und es spricht ansich nichts dagegen.
Eventuell schränken wir das so ein, dass nicht jedes IO Modul das unterstützen muss, denn sonst wird das INI Modul mit viel Zustatzarbeit belastet.
Ich schlage vor, den Container immer hierachisch zu machen (also als Baum) und zwei Frontends zu haben, eines für hierachische Keys und eines für "flache".
Dadurch wird der Benutzer von flachen Strukturen nicht zu irgendwelchen Keykonventionen gewzungen.
Wenn das IO Modul durch das Frontend gesetzt wird, hat man auch da die Möglichkeit, nur solche zu erlauben, die den jeweiligen Modus auch können.
Abgesehen von der Struktur, sollten wir uns vielleicht auf eine Menge von Datentypen einigen, außer jemand hat eine gute Idee, das mit Templates zu lösen
Mir fallen da auf die Schnelle folgende ein
Code:
QString
QStringList
QColor
QFont
QPoint
QRect
bool
int
uint
double
Wie wollen wir das Verhalten haben?
Wenn zb ein QString Eintrag mit dem Namen "abc" existiert, soll dann ein QFont Eintrag mit selben Namen
- eingetragen werden
- zurückgewiesen werden
- den String löschen und den Font eintragen
?
Von Konzept her, was sagt ihr zu solchen Methoden
Code:
writeEntry(const QString& key, const QString& value);
writeEntry(const QString& key, const QFont& value);
readEntry(const QString& key, const QString& defvalue, bool* ok=0);
readEntry(const QString& key, const QFont& defvalue, bool* ok=0);
(Bei writeEntry bräuchte man bei möglichen Zurückweisungen natürlich einen bool Rückgabewert, oder auch einen bool* Parameter)
Ciao,
_
Lesezeichen