Ü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

Wer uns nicht kennt könnte meinen, dass wir 2011 nicht viel geleistet haben. Die History 2011 könnte diesen Eindruck enstehen lassen. Dem ist aber nicht so. Im Gegenteil. Es folgt eine kurze Zusammenfassung:

Projekte:

• OPSI Setup für 250 Arbeitsplätze. Wir können die Lösung der Softwareverteilung nur empfehlen.
• Migration Cyrus auf Dovecot mit 1500 Postfächern.
• Integration Webapplikationen mit Facebook.
• Unterstützung Migration auf NFS4 und Kerberos für eine Forschungseinrichtungen in Deutschland.
• Freeswitch Support für eine Fluggesellschaft. Hier warten wir gespannt auf Gemeinschaft 4.0
• Yate ist auch sehr gut. Installation für 250 Teilnehmern.

Details folgen …

Nahezu out-of-the-box konnten wir die von Inverse bereitgestellte virtual appliance mit integriertem SOGo 1.3.3 in eine bestehende Infrastruktur eingliedern und eine ältere SOGo Version durch die aktuelle ablösen.

Weiterlesen >>

Die Integration von Asterisk und Snom Telefonen in Tine ist schon recht weit fortgeschritten. Näher angesehen haben wir uns das Zusammenspiel von Asterisk 1.6, Tine20 Mialena und Snom 3XX Telefonen. Es benötigt schon den einen oder anderen Blick in den Source Code. Deshalb hier eine kurze Zusammenfassungen. Weiterlesen >>