Pyramiden-ACL ohne Traversierung

Ich habe wirklich keine Ahnung, wie ACL funktioniert. Ich weiß, es ist ziemlich cool und könnte mir viel Zeit und Schmerzen ersparen. Aber momentan bin ich ein bisschen verloren. Alle Beispiele für Pyramiden verwenden Traversal. Ich verwende ausschließlich URL-Versand. Ich bin mir nicht sicher, wie ich eine Ressourcenbaumstruktur aufbauen kann.

Hier ist ein Beispielcode:

Die Sache ist, dass es funktioniert. Aber ich muss für jede Art von Ressource eine neue Fabrik definieren. Ich bin mir nicht sicher, wie ich wissen soll, auf welche Ressource ich durch URL Dispatch und Factory zugreifen möchte. Ich würde so etwas sehen

Das sagte hier würde ich solche Struktur haben

Jede dieser Fabriken hat ihre eigenen speziellen acl. Die andere Sache ist, dass / accounts die Hauptseite ist. Es hat keine ID oder so etwas. Auch / accounts / new ist ebenfalls ein Sonderfall. Es ist keine ID, sondern die Ansicht, um einen neuen Gegenstand zu erstellen.

Ich verwende einen erholsamen Stil mit GET / PUT / DELETE / POST-Anforderung. Ich bin nicht so sicher, wie ich url zu einer Ressource und zur rechten acl automatisch zusammenbringen sollte. Wenn ich in meiner Wurzel eine spezielle Fabrik wie oben definiere, gibt es keine Probleme.

Bearbeiten

Ich habe es mit Ausnahme einiger Dinge zum Laufen gebracht. Ich denke schließlich, ich verstehe, was der Zweck der Überquerung ist. Zum Beispiel mit dieser URL: / comments / 9494f0eda / new, / Kommentare / {Kommentar} / neu

Wir könnten Knoten in unserem Ressourcenbaum oder sogar 3 Knoten haben.

Die RootFactory wird zuerst überprüft, dann gemäß unserer Durchquerung. Es wird das comments-Attribut von RootFactory, dann "comment" von Comment factory und "new" von CommentFactory oder des Objekts selbst

Ich benutze Factory nicht als Diktat wie im Beispiel von Michael

Es sieht ungefähr so ​​aus:

Dies ist mein Basis-Ressourcenobjekt. Bei jedem Schritt kopiert es Informationen vom Elternteil zum neuen Kind .. Ich könnte sicherlich mein Attribut .. Kontext. Elternteil ._ Elternteil _. Uid aber das ist einfach nicht so toll.

Der Grund, warum ich das Attribut dict nicht verwende. Ich füge hinzu, damit es mit

/ Kommentare

Aus einigen Gründen hat es meine CommentFactory erstellt, aber nicht zurückgegeben, da kein Schlüssel benötigt wurde.

Also sieht meine root Factory so aus:

Wenn kein Element gefunden wird, gibt RootFactory sich selbst zurück, wenn nicht, gibt es eine neue Factory zurück. Da ich meinen Code auf Michaels Code stütze, gibt es einen zweiten Parameter für den Factory-Konstruktor. Ich bin mir nicht sicher, ob ich das behalten soll, da eine QuestionFactory durchaus weiß, mit "Fragen" umzugehen, so dass man die Fabrik hier nicht nennen muss. Es sollte schon seinen Namen wissen.

Das ist also der Punkt, an dem fast alle Logik gehen wird. In der init setze ich acl, das für / questions im getitem funktionieren wird, wird es für / questions / {id} / *

Da ich mich selbst zurückgebe, wird jedes getitem nach dieser RessourceFactory auf sich selbst zeigen, wenn ich nicht eine neue Factory für einen speziellen Fall zurückgebe. Der Grund dafür ist, dass mein Kontext nicht nur ein Objekt in der Datenbank oder ein Objekt ist.

Mein Kontext behandelt mehrere Dinge wie Benutzer-ID, Gebietsschema und so weiter ... Wenn das acl fertig ist, habe ich ein neues Kontextobjekt zur Verwendung bereit. Es entfernt den Großteil der Logik in den Ansichten.

Ich könnte wahrscheinlich Ereignisse setzen, um locale und uid abzufragen, aber es passt wirklich hierher. Wenn ich etwas neues brauche, muss ich nur meine RootFactory und ResourceFactory bearbeiten, um sie in die Child Factory zu kopieren.

Auf diese Weise gibt es keine Redundanz, wenn sich etwas über alle Ansichten hinweg ändern muss.