Basti

Hallo.

Was habt ihr für Erfahrungen mit Observern in euren Anwendungen? Konkret geht es bei mir darum, das Session-Objekt an verschiedenen Stellen im Code "einzuhängen". Wenn der Benutzer-Status wechselt, wird $Session->regenerateId() aufgerufen, bevor Weiterleitungen (302er) ausgeführt werden, wird $Session->writeClose() aufgerufen.

Das funktioniert natürlich auch und im Moment reicht mir das vollkommen aus. Ich denke nur schonmal weiter, denn meinem Verständnis nach sollten weder die Controller, noch das Session-Objekt ($Session->triggerEvent('beforeExit'); oder so) entscheiden, was alles zu tun ist, bevor eine Weiterleitung gestartet wird.

Das Problem ist nun, dass ich schlecht das Session-Objekt zum Observer des User-Objektes machen kann, da dieses zum Zeitpunkt der initialisierung des Session-Objektes noch garnicht besteht. Beziehungsweise hier könnte man ja zunächst ein leeres User-Objekt bauen, aber das geht mit den Redirects ja nicht, da ich die Session brauche, um überhaupt entscheiden zu können, welcher Controller den Request ausführen soll.

Ich dachte an einen zentralen EventManager, bei dem sich Beobachter für bestimmte Events anmelden können und die dann einfach durch ein EventManager->getInstance()->triggerEvent('auth_state_changed'); oder so benachrichtigt werden.

Aber so ganz sauber finde ich das nicht, denn ich müsste die Events und damt die Abhängigkeiten und Zusammenhänge getrennt dokumentieren.

Hab ihr mir Anregungen dazu?

Basti

Mister Ad

brain_overload

vielleicht ist der Aufbau deiner Objekt Hierarchie zu überdenken!?

Das "Henne-Ei-Problem" stellt sich nicht, wenn man das User-Objekt und das Session-Objekt auf eine Hierarchie-Ebene stellt, was meiner Meinung für HTTP-Anwendungen korrekt wäre.

Oberhalb dieser beiden Objekten sollte ein Application-Objekt stehen, das die Events/Benachrichtigungen von seinen Child-Objekten verarbeitet.
Mit diesem Prinzip arbeite ich häufig.

Hoffe, Dein Problem richtig verstanden zu haben.
Grüße brain_overload

Basti

Hi "brain_overload".

Klar, darum geht es ja gerade, dass die einzelnen Controller nicht direkt auf das Session-Objekt zugreifen (natürlich schon, wo es um das Schreiben und Lesen von Daten geht, aber eben nicht, wo es darum geht, die Anwendung in puncto Session sicher zu machen bzw. Fehlerquellen der Session auszumerzen), sondern dass es eine übergeordnete Instanz gibt, die auf bestimmte Signale entsprechend geagiert.

Nur, wie sieht das praktisch aus?

Den Redirect werd ich eh in den Application Controller legen - damit ist das Problem erledigt. Aber was Änderungen am User-Status angeht, so wäre hier in meinen Augen ein Observer bzw. Event- oder Model-Listener angebracht. Andernfalls müsste der Controller, der die Statusänderung durchführt ja neben der View noch Signale an den ApplicationController zurück durchgeben, dass eben eine solche Änderung stattgefunden hat.

Und da fehlt mir ein gescheiter Ansatz, wie das gut umzusetzen ist.

Basti

dr.e.

Hallo Basti,

meiner Ansicht nach ist das ein klassisches FrontController-Thema. Dabei wird die Busines-Schicht vor der Präsentationsschicht aufgebaut und dort bereits die Entscheidung getroffen, was passieren soll. Du kannst zudem eine Art "Runtime" instanzieren (bei mir heißt das Applicationmanager), der bei jedem Request gestartet wird und Listener-Methoden (registerListener(), unregisterListener(), ...) zur Verfügung stellt.


Grüße,
Christian

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~