Diese Methode schien mir für deutsche Fehlermeldungen in den Formularen noch am schnellsten zu sein.

Dabei gehe ich davon aus, daß die Website durchgehend in einer Sprache ist, und die Anzahl der Übersetzungen sich nur auf Meldungen der Standart-Dekoratoren und Fehlermeldungen beschränkt.

Die Idee nutzt die Tatsache, daß die Formulare auf einen Default-Translator zurückgreifen, falls dieser vorhanden. (mehr …)

Die View-Verwaltung verfügt über eine eigene Auflösung von Namespaces für die Viewhelper. Diese Auflösung wird mit Plugin-Loader-Klassen erledigt, im Gegensatz zu Resource-Loader-Klassen, die für die Auflösung von Klassennamen zuständig sind.

Wird ein Viewhelper angefordert, so versucht die View den Helper zuerst mit den Plugin-Loadern zu ermitteln, erst danach werden die Resource-Loader verwendet. Der Vorteil der Plugin-Loader ist neben dem (geringfügigen) Geschwindigkeitsgewinn auch die Möglichkeit, die vorgegebenen Viewhelper-Pfade besser zu manipulieren.

Aber gerade hier entsteht ein Problem, denn meist werden die Viewhelper nur über die Plugin-Loader gefunden, um aber eine Basis-Klasse zu finden braucht man zusätzlich einen entsprechenden Resource-Loader. (mehr …)

Über die application.ini lässt sich der Namespace der Applikation
festlegen.

Nochmals zur Erinnerung:

Der Namespace ist immer der erste Teil eines Klassennamens. Namespaces
ermöglichen dem Autoloader schnell zu entscheiden, wie er einen Namen
auflösen soll.

Grundsätzlich kann man für den Autoloader beliebige viele Namespaces
festlegen. Auch lassen sich für die weitere Auflösung des Klassennamens
Regeln festlegen.

Um die allgemeine Verwendung von Namespaces von den festgelegten
Namespace in der application.ini unterscheiden zu können verwende ich für
den in der ini festgelegten Namespace den Begriff Applikation-Namespace.

Für eine Applikation gibt es immer nur einen
Applikation-Namespace.

Den Applikation-Namespace sollte man nicht vermischen
mit den Namespaces für allgemeinere Klassen zB Libraries. Sinnvollerweise
sollten die Klassen für den Applikation-Namespace in der Applikation
stehen und auch nur dort verwendet werden.

Diesen Namespace kann man als simple Verwaltung der üblichen
applikationspezifischen Objekte betrachten.

In der application.ini wird

appnamespace = "My"
autoloaderNamespaces.My = "MyApp"

der Namespace für die Applikation gesetzt.

Im Rahmen des Bootstrapping wird dann die Autoloader-Resource erzeugt.

Es werden automatisch einige Resourcen und Pfade mit erzeugt. Der
Basispfad zu den Pfaden wird erstellt mit mit
„Zend_Application_Module_Autoloader::getBasePath()“.

Eine Einschränkung der Initialisierung über die Ini ist, daß man die
Namespaces und ihre Pfade nicht beeinflussen kann (es gibt einfach keine
Möglichkeiten dafür).
Auch kann man den Basispfad nicht über die ini setzen, dieser ist
automatisch auf das Applikationsverzeichnis gesetzt.

Wer also mehr mit Resourcen und Namespaces zB für Bibliotheken machen
will, der kommt um eine Ausprogrammierung (in der Bootstrap) nicht drum
herum.

Wenn man über die navigation.ini seine Seitenverlinkung festlegt und
zudem eigene Router verwendet, dann kann es passieren, daß man bei der
Navigation falsche Links bekommt.

Wenn nicht anders festgelegt worden ist, dann lösst das Framework die
Links der Navigation mit dem aktuell verwendeten Router auf. Um das zu
verhindern muß man in der navigation.ini explizit den Router angeben, den
man verwenden will.

Dies ist auch notwendig, wenn man den Default-Router verwenden will. In
diesem Fall wählt man als Routernamen „default“.

Ein Eintrag in der ini sähe dann so aus:

register.label = "Registrieren"
register.controller = "registration"
register.action = "index"
register.resource = registration
register.privilege = index
register.route = default