mepeisen

Hallo.

Ich habe für ein Projekt eine Objekt orientierte Registry entwickelt. In zwei Details bin ich aber mit meiner Lösung nicht ganz glücklich.

Im Grunde ist es so aufgebaut, dass ich einen Baum aus Knoten habe. Jeder Knoten kann Attribute aufnehmen (einfache Key-Value-Paare) und beliebige Unterknoten. Diese Registry (ich habs so genannt, weil das zunächst mal ein ähnliches Prinzip ist wie die Windows-Registry) soll nun von der Webanwendung, also JavaScript, verwendet werden. Verwendung findet immer über Hilfsklassen statt. Die Knoten haben also für sich genommen keinen Typ, sondern sind reine Informationsverwalter. Wenn ich einen Knoten als etwas (zum Beispiel als Datei) interpretieren will, lege ich eine Hilfsklasse an, die weiß, welche Attribute und Unterknoten sie wie zu interpretieren hat.

Eine Verwendung soll sein, dass ich in einem Bereich eine Art virtuelles Dateisystem abbilde, also klassische Ordner und Dateien. Ich habe mir folgendes überlegt:
Dateien erhalten Mime-Typen und pro Mime-Type auch entsprechende Inhalte. Es gibt immer einen primären Mime-Typen und einen Haufen sekundärer Mime-Typen. Beispiel einer Text-Datei:
Bei diesem Beispiel habe ich eine einfache Textdatei. Es gibt ein Bewertungssystem und der Datei wurde die Schulnote 4 gegeben. Zu Deutsch: Ich kann bei jeder Datei weitere Features einbinden, in diesem Beispiel ein Bewertungssystem, mit dem die Datei bewertet wird. Durch die Mime-Typen ist immer klar, dass das eigentlich eine Text-Datei ist, deswegen primär.
Vorteil: Unabhängig vom Inhalt der Datei kann man zusätzliche Features an sie binden. Das Bewertungssystem kann auch auf Bildern, RTFs oder was weiß ich arbeiten.

Verzeichnisse arbeiten ähnlich (haben also auch mögliche Mime-Typen), haben dann weitere Inhalte.

Ein weiterer Vorteil des Systems: Wenn ich ein Dokument habe mit eingebetteten Dateien, ist das problemlos möglich. Nach außen hin sehe ich erst einmal eine Datei, beispielsweise mit "text/html" als Mime-Typ. Dadurch dass auch eine Datei Unterknoten haben kann, können jederzeit Bilder eingebettet werden. Ein Bildbearbeitungsprogramm kann diese Bilder ohne Probleme wie eine normale Datei behandeln, beispielsweise über den Pfad "/meinOrdner/test-html/meinBild". Das macht insbesondere bei der Dokumentbearbeitung Sinn.

Wie die Registry zustande kommt, liegt am Server. Ob er beispielsweise bei bestimmten Knoten die Veränderungen in spezielle Datenbanktabellen wegschreibt. Der Clou: Selbst die Mime-Typen einer Datei sind einzelne Knoten in dieser Registry, können also individuell angepasst werden und vom Server alternativ verwaltet werden. Das Rating-Beispiel von oben könnte also in einer schlichten Datenbanktabelle abgelegt werden.

Ich sprach von zwei Sachen, die mir derzeit nicht gefallen.
1. Die Art und Weise, wie ich Dateien und Verzeichnisse derzeit erkenne. Ich habe ein Flag eingeführt, was entweder auf 'file' steht oder auf 'folder' oder auf gar nichts (dann ist es ein interner Knoten, den ein Dateibrowser zum Beispiel ignorieren soll). Das gefällt mir derzeit nicht wirklich. Wieso nicht ein Verzeichnis dadurch kennzeichnen, dass es einen primären Mime-Typ verpasst bekommt, beispielsweise 'application/x-folder'. Dateien wären dann alles andere. Problem: Wenn ich von dem Flag wegkomme, brauch ich trotzdem noch eine Unterscheidung, ob es nun ein interner und für Browser unsichtbarer Knoten ist.
2. Da jeder Knoten beliebige Unterknoten aufnehmen können soll, habe ich irgendwann Namenskonflikte. Derzeit speichere ich beispielsweise die Mime-Typen im Unterknoten 'x-mime-types' eines Knotens. Das bedeutet automatisch, dass ich diesen Namen als Dateinamen nicht mehr verwenden kann, denn er ist fest für interne Zwecke vergeben. Wenn nun eine Anwendung ihrerseits etwas erweitert und den System-Knoten plötzlich 'foo' nennt, kann ich auch dies nicht mehr guten Herzens als Dateiname vergeben. Eine Lösung aus diesem Dilemma will mir nicht recht einfallen...

Ja, so schön die Lösung ist und soviel Spass wie mir das derzeit macht mit meinem Texteditor und Bewertungsbeispiel, so dämlich finde ich diese beiden Details. Wie würdet ihr das lösen?

Achja: Das "fertige" Beispiel zeige ich euch dann die Tage, sieht bisher hübsch aus

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Mister Ad

dr.e.

Hi,

ich habe deinen Beitrag nun 2x gelesen, ich verstehe jedoch beim besten Willen den Ansatz nicht. Entweder du wählst ein Problem passend zur Lösung oder ich habe das Problem nicht verstanden.

Kannst du mal für deine Anwendungs-Domäne die echten Entitäten aufzeigen? Du sprichst von Text-Dateien, Key-Value-Paaren, ... aber das passt für mich nicht wirklich zusammen. Sofern du ersteres hast, heißen deine Domänen-Objekte "Folder" und "File", im Fall einer Bewertung gelten da andere Regeln ("Subject", "Rating", ...).

Das ist jetzt erst mal keine Lösung für dich, ich möchte jedoch sicherstellen, dass mein Ratschlag auch wirklich passt.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mepeisen

Das Problem ist die Frage, wie ich verschiedene Domänen miteinander verknüpfen kann. Vom Grundprinzip her benötige ich also eine Lösung, wie ich ein zentrales Daten-Repository gestalte. Die eigentliche Registry-Lösung oder die Kombination aus hierarchisch angeordneten Knoten, die über variable Attribute verfügen, ist eine Grundlage aus Flow3, was wiederum auf dem Java Content Repository basiert. Ich habe daher auch nicht mehr weiter drüber philosphiert. Warum ich das nicht gezielt Content Repository nennen will ist ist darin begründet, dass ich verschiedene Features daraus bewusst nicht umsetzen werde (Transaktionen, Sessions, mehrere Roots usw.).
Als Domänen habe ich also zunächst einmal einen Objektknoten mit beliebigen Objektknoten als Kinder und mit Attributen. Die weiteren Domänen basieren nun auf dieser Struktur und interpretieren sie gezielt für ihre Bedürfnisse. Jede Domäne muss jedoch ihre Daten und Zugriffe über diese Struktur (Objekthierarchie mit Attributen) abbilden.

Die Aufgabenstellung ist nun, einen Teilbereich dieses Objektbaums als Dateisystem darzustellen und interpretieren zu lassen. Sprich: Wie soll es aufgebaut werden, dass meinetwegen die Domänen Datei und Rating sich nicht untereinander stören. Ebend diese zwei Details machen mir Kopfschmerzen:
1. Wie erhalte ich einen "Typ-Hinweis" an einem Knoten?
2. Wie vermeide ich Namenskonflikte bei Attributen und Knoten im Objektbaum, die durch unterschiedliche Domänen, die sich untereinander ja nicht zwangsläufig kennen, provoziert werden könnten?

In Flow3 ist es so gelöst, dass ich mehr oder minder die PHP-Objekte serialisiere. Dadurch hat man immer einen Klassennamen pro Knoten als Hinweis und die Klassenattribute. Ein Vermischen der Domänen kann nicht stattfinden, weil man die Trennung über die Klassennamen hat. Das wird in JavaScript so nicht möglich sein ohne Zusatzcode, den ich bewusst vermeiden will. Daher sind die Knoten im JavaScript Repository immer Typungebunden.


P.S.: Es war schon spät gestern und ich war freudentrunken über den Bayern-Sieg, daher ist der Einleitungsartikel in der Tat etwas konfus

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Dark Guardian

Du könntest doch die Knoten noch einmal kategorisieren. Z.B. nach "System" und "Files" o.ä. So könnte es "x-mime-types" oder anderes, was in "System" definiert wird auch noch einmal als Datei unter "Files" geben.

Bzw. jede Domäne könnte halt einen solchen Bereich im Knoten registrieren, falls nötig.

Falls ich dich richtig verstanden habe würde das jedoch Flexibilität kosten da der Kontext eines Knotens oder Attributes durch den übergeordneten Bereich bestimmt werden würde.

mepeisen

Die Flexibilität geht dann verloren, wenn jede Domäne wissen muss, wie der Pfad angesprochen wird, nur weil eine Vaterdomäne etwas anderes ist. Wenn ich jede Domäne separat verwalte, muss jede Domäne die Verwaltungsschnittstelle des Vaters kennen, sonst kann sie nicht auf Objekte, die in anderen Domänen stecken, problemlos zugreifen.

Naja nicht zwangsläufig. Man kann sich ja dadurch beheben, dass jede Domäne einen Prefix kriegt. Das, was Domäne a) verwendet, kriegt Präfix "a-" und das aus Domäne B kriegt Präfix "B-".
Es schaut etwas blöd aus, wenn ich den Pfad zu einem Objekt anschaue. Aus dem vorher "hübschen" Dateinamen "/fs/mypath/Hello World" wird dann plötzlich ein "/filesystem-fs/filesystem-mypath/filesystem-Hello World". Technisch wäre das eine mögliche Lösung. In der Praxis sieht das bescheuert aus

Noch ein Beispiel zur Verwendung. Eine Domäne, die sich um Berechtigungsverwaltung kümmert, könnte ihre Daten in "acl" abspeichern. Sofern sie weiß, wie der Pfad eines Objektes ist, ist es ihr egal, ob sie Berechtigungen einer Datei speichert, eines Verzeichnisses oder von ganz was anderem. Auch deswegen ist es geschickter, dass die Knoten immer über einen Pfad erreichbar sein sollten und beim Zugriff auf einen Knoten nicht bekannt sein muss, über welche Vater-Domänen wie auf ein Kind-Knoten zugegriffen werden muss.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Dark Guardian

Eine ähnliche Lösungsmöglichkeit wäre ein seperater Domänen-Baum welcher die gleiche Knotenstruktur hat, aber die Domäne festlegt zu welcher der Knoten gehört.

So kann man die Knoten weiuterhin über ihren Pfad ansprechen, und müsste ledeglich im Konfliktfall eine Domäne angeben.

Z.B. wäre

"/fs/mypath/Hello World"

ein gültiger Pfad. Der Domänenpfad sähe so aus:

"/filesystem/filesystem/filesystem".

Da die Domänen in einem seperatem Baum liegen ist die Angabe der Domäne im Pfad nicht mehr notwendig und auch nur für den Konfliktfall relevant.

Die gnanze Sache wäre aber auch sehr aufwendig. Damit die Domänenpfade auch nicht so beknackt aussehen wäre z.B. auch folgendes sinnvoll:

"/filesystem/*" -> alle Knoten werden als Filesystem interpretiert.

"/filesystem/*/windows/dll/"
"/filesystem/*/linux/so/"

-> Alle Knoten bis zu dn letzten zwei werden als Filesystem interpretiert und die letzten beiden der Angabe entsprechend.

Wie gesagt, das wäre ein erheblicher Mehraufwand. Und das Problem wird nur halb gelöst denn im Falle einer fehlenden Domänenangabe und dem Auftreten eines Konfliktes besteht das Problem weiterhin.