Die eleganteste/sichere/einfache Lösung zum Speichern und Bearbeiten (GUI) einer verzeichnisartigen Baumstruktur?

Question

Ich habe ein etwas schwieriges Problem zu lösen. Stell dir das vor:

Eine meiner Anwendungen muss das Skripten stark nutzen. Meine Idee war es, dem Benutzer eine Möglichkeit zu bieten, Skriptschnitte zu schreiben und in einer verzeichnisartigen Baumstruktur zu organisieren. Dies ähnelt einem Quellcode -Verzeichnis mit Unterverzeichnissen und Quelldateien.

Datenklassen/Speichern

Das erste Problem, auf das ich stoße, ist, dass ich einen guten Weg finden muss, um die gesamte Baumstruktur (auf der Festplatte und innerhalb der Anwendung zur Laufzeit) zu speichern. Dafür hatte ich diese Ideen:

1. Verwenden Sie eine von QObject abgeleitete Klasse, die den Baum mithilfe der übergeordneten/untergeordneten Merkmale von QObject darstellen kann. Auf diese Weise muss ich mir keine Sorgen machen, diese Objekte zu löschen, wenn sie Eltern gelöscht werden.
2. Verwenden Sie eine einfache Klasse, die eine Qlist (ohne Zeiger) von Kindern und einige Eigenschaften enthalten kann, die die Eigenschaften jeder Gruppe/jedes Skripts speichern.
3. Verwenden Sie Ansatz Nr. 2, verwenden Sie jedoch Zeiger anstelle von statischen Objekten - dies würde das kopieren, wenn ich eine Gruppe oder einen Teil eines Baumes an eine Funktion übergeben muss, ein nutzloses Kopieren usw.
4. Verwenden Sie ein Live -Backend für eine SQLite -Datenbank (oder eine ähnliche) Datenbank und fragen Sie sie zur Laufzeit. Dies würde vermeiden, den gesamten Baum auf einmal zu beladen und im RAM zu halten.
5. Verwenden Sie eine flache Datei- und Verzeichnisstruktur im Dateisystem. Obwohl ich denke, dass dies mehr Probleme als nötig macht, da es keine Möglichkeit gibt, Meta -Informationen über Objekte zu speichern.

Editor

Das nächste Problem, auf das ich stoße, ist die Tatsache, dass der Benutzer wahrscheinlich die gesamte Baumstruktur bearbeiten möchte. Er möchte auf eine Gruppe oder ein Skript klicken, den Skriptcode bearbeiten und möglicherweise Verzeichnisse und Skripte im Baum umziehen. So ändern Sie die Struktur des gesamten Baumes auf dem Weg.

Dies wirft die folgenden Probleme auf:

1. Wenn der Benutzer den Editor schließt, könnte es eine gute Idee sein, ihm eine "Möchten Sie die Änderungen speichern?" Dialog. Ähnlich wie ein Texteditor, in dem Sie versehentlich etwas in ein vorhandenes Dokument eingegeben haben, aber Sie kündigen, ohne die Änderungen zu speichern. - Dies würde erfordern, dass wir eine Kopie des gesamten Baumes bearbeiten und den vorhandenen Baum innerhalb der Anwendung bei Bedarf überschreiben.
2. Das Zulassen von Drag & Drop könnte problematisch sein ...
   • ... mit dem Speichern Ansatz Nr. 1: Derzeit gibt es keinen guten Weg, um die Reihenfolge der Kinder von QObjects zu ändern. Außerdem ist es keine gute Idee, Objekte zur Laufzeit zu bewegen, während andere Teile des Programms auf sie zugreifen könnten.
   • ... das ist einfacher mit Speichern Ansatz #2, Da der gesamte Baum wie ein einzelner Wert behandelt wird und es keine Kinder gibt, müsste ich mich bewegen und wieder parent machen. Das Kopieren eines Teils des Baumes kopiert automatisch alle Kinder und so weiter. Leider würde dies viel Overhead und Flexibilitätsverlust bedeuten (ich müsste den ganzen Baum erneut auf die Scheibe schreiben, da ich nicht sicher sein kann, was genau geändert wurde).

Ich werde diese Frage wahrscheinlich ein wenig aktualisieren, wenn mir mehr Dinge in den Sinn kommen, aber ich bin wirklich gespannt, wie andere Leute dieses Problem lösen. Vorschläge und Ideen werden geschätzt. :)

Answer 1

Inzwischen habe ich das Problem gelöst, indem ich die Tiefe des Baumes mit dedizierten Klassen begrenzte. Das bedeutet, dass es nur eine begrenzte Menge an Baumtiefe gibt, die gehandhabt werden muss. Im Moment verwende ich einfach QreetreeWidget und einige Helfermethoden, die Sortieren, Drag & Drop und andere nette Funktionen ermöglichen.

Answer 2

Ich würde Ihnen vorschlagen, sich QFILESSystemmodel für gute Praktiken anzusehen. Das Modell sollte sich mit einem separaten Thread für die Reaktionsfähigkeit der Benutzeroberfläche aktualisieren, einen Cache usw. behalten. Ein gut benommenes Modell sollte auch Ihre Arbeit am Editor erleichtern.

Ich würde mich auch für das Erstellen Ihrer TreeItem -Klassen entscheiden. Eine gemeinsame Daten mit QsharedData für eine Basisklasse wäre schön. Ich hätte auch eine Immobilie für seine Bestellung. Auf diese Weise, wenn der Benutzer die Reihenfolge auf andere Weise schleppt und fallen lässt, haben Sie eine Möglichkeit, die Kontrolle zu behalten. Da die Daten gemeinsam genutzt werden, hätte die Aufbewahrung Ihrer eigenen Objektliste in Ihrer Bestellung für Leistung geringe Kosten.

Schauen Sie sich auch einen Blick auf Modeltest.