Da die neue Komponente Zend_Application hier und da für mehr Verwirrung, als Hilfe sorgt, hab ich mal bisschen gezeichnet. Ja, wirklich: Mit Stift, Papier und zwei gesunden Händen.
Zend_Application selbst macht wirklich nicht viel, wie Skizze 2 vereinfacht darstellt. Application selbst lädt die Config, die man bei Instanzierung als Dateiname für gewöhnlich mit angibt. Was sie darin findet, wird immer weiter getragen. Die eigene Bootstrap ruft nun zunächst die geschützten (“protected”) _init*()-Methoden auf, die in ihr definiert sind. Danach werden der Reihe nach die Plugin-Resources abgearbeitet, allerdings nur die, die benötigt werden. Danach ist der Zauber auch schon vorbei. Die Bootstrap registriert sich noch im Front-Kontroller und ist dann in den Action-Kontrollern per getInvokeArg(‘bootstrap’) verfügbar. Das hat den Vorteil, dass man darüber die Bootstrap, darüber eine Plugin-Resource und wiederum darüber (meist) ein Objekt holen kann, für das sich die Resource zuständig gefühlt hat.
$translate = $this->getInvokeArg ('bootstrap')
->getPluginResource ('translate')
->getTranslate();
Das etwas größere Zusammenspiel mit dem Front-Kontroller zeigt Skizze 1. Zunächst ruft man die Bootstrap auf. Ist die fertig, übergibt sie die Kontrolle an den Front-Kontroller und ist damit mit ihrer Aufgabe am Ende. Danach füllt der Router das Request-Objekt mit Infos, der Dispatcher dispatched, ActionController actioned und so weiter. Das ist allerdings an anderer Stelle bereits besser dargestellt und hat sich sowieso mit 1.8 nicht geändert.
Damit sollte klar sein, wo die Zuständigkeiten sind: Bootstrap und Konsorten kümmern sich um die Initialisierung, FrontController um den Ablauf. Darin ist auch begründet, warum zum Bootstrap-Ablauf kein FrontController-Plugin registriert werden kann, das von aktuellen Modul abhängt; Er kennt es schlicht noch garnicht.
Grüße, KingCrunch
RSS
Facebook
twitter