Vorhandene Ressource Plugins

Hier kann man API-artige Dokumentation über alle Ressource Plugins finden die standardmäßig in Zend_Application vorhanden sind.

Zend_Application_Resource_Cachemanager

Zend_Application_Resource_Cachemanager kann verwendet werden um ein Bündel von Zend_Cache Optionen zu setzen die verwendet werden sollen wenn Caches lazy geladen werden bei der Verwendung von Zend_Cache_Manager

Da der Cache Manager ein Lazy Loading Mechanismus ist, werden die Optionen auf Options Templates übersetzt welche verwendet werden um ein Cache Objekt auf Anfrage zu initialisieren.

Example #1 Beispiel einer Cachemanager Ressource Konfiguration

Anbei ist eine Beispiel INI Datei die zeigt wie Zend_Cache_Manager konfiguriert werden kann. Das Format ist der Präfix der Cachemanager Ressource (resources.cachemanager) gefolgt von dem Namen der einer Cache Template/Bündel Option zugeordnet werden soll (z.B. resources.cachemanager.database) und letztendlich gefolgt von einer typischen Zend_Cache Option.

  1. resources.cachemanager.database.frontend.name = Core
  2. resources.cachemanager.database.frontend.customFrontendNaming = false
  3. resources.cachemanager.database.frontend.options.lifetime = 7200
  4. resources.cachemanager.database.frontend.options.automatic_serialization = true
  5. resources.cachemanager.database.backend.name = File
  6. resources.cachemanager.database.backend.customBackendNaming = false
  7. resources.cachemanager.database.backend.options.cache_dir = "/path/to/cache"
  8. resources.cachemanager.database.frontendBackendAutoload = false

Das Empfangen dieses Caches vom Cache Manager ist in Wirklichkeit so einfach wie der Zugriff auf eine Instanz des Managers (Zend_Cache_Manager) was von Zend_Application_Resource_Cachemanager empfangen wird beim Aufruf von $cacheManager->getCache('database');. Das folgende Beispiel ist von einem Controller genommen bei dem auf die Bootstrap Klasse als Front Controller Parameter zugegriffen werden kann (welcher automatisch wärend des bootstrappens zugeordnet wird). Wie man sehen kann implementiert die Cache Manager Ressource eine getCacheManager() Methode um die ge-bootstrappte Instanz von Zend_Cache_Manager zu erhalten.

  1. $manager = $this->getFrontController()
  2.             ->getParam('bootstrap')
  3.             ->getResource('cachemanager')
  4.             ->getCacheManager();
  5. $dbCache = $manager->getCache('database');

Siehe auch die Methode Zend_Cache::factory() um eine Beschreibung der Standardwerte zu bekommen welche man zuordnen kann wenn ein Cache über eine Konfigurationsdatei konfiguriert wurde wie im obigen Beispiel einer INI Datei.

Zend_Application_Resource_Db

Zend_Application_Resource_Db initialisiert einen Zend_Db Adapter basieren auf den Ihm übergebenen Optionen. Standardmäßig, setzt es den Adapter als Default Adapter zur Verwendung mit Zend_Db_Table. Wenn man mehrere Datenbanken simultan verwenden will, kann man das Multidb Ressource Plugin verwenden.

Die folgenden Konfigurationsschlüssel werden erkannt:

  • adapter: Zend_Db Adaptertyp.

  • params: Assoziatives Array von Konfigurationsparametern das verwendet wird wenn man die Instanz des Adapter empfängt.

  • isDefaultTableAdapter: Ob dieser Adapter als Standard-Tabellen Adapter verwendet werden soll oder nicht.

  • defaultMetadataCache: Der Name des Cache Templates oder einer Instanz von Zend_Cache_Core welche als Metadaten-Cache für Zend_Db_Table zu verwenden ist.

Example #2 Beispiel der Konfiguration einer DB Adapter Ressource

Anbei ist das Beispiel einer INI Konfiguration die verwendet werden kann um die DB Ressource zu initialisieren.

  1. [production]
  2. resources.db.adapter = "pdo_mysql"
  3. resources.db.params.host = "localhost"
  4. resources.db.params.username = "webuser"
  5. resources.db.params.password = "XXXXXXX"
  6. resources.db.params.dbname = "test"
  7. resources.db.isDefaultTableAdapter = true
  8.  
  9. ; Optional kann auch ein Cache Template zur Verwendung für Metadaten Caching
  10. ; angegeben werden:
  11. resources.db.defaultMetadataCache = "database"

Note: Empfangen der Adapter Instanz
Wenn man den, mit dieser Ressource initialisierten Adapter, nicht zum Standard-Tabellen Adapter macht, wie erhält man dann die Adapter Instanz ?
Wie bei jedem Ressource Plugin, kann an das DB Ressource Plugin von der Bootstrap Datei erhalten:

  1. $resource = $bootstrap->getPluginResource('db');
Sobald man das Ressource Objekt hat, kann man den DB Adapter erhalten indem die getDbAdapter() Methode verwendet wird:
  1. $db = $resource->getDbAdapter();

Zend_Application_Resource_Dojo

Zend_Application_Resource_Dojo kann verwendet werden um die Viewhelfer von Zend_Dojo zu konfigurieren.

Example #3 Beispiel einer Dojo Ressource Konfiguration

Anbei ist ein Beispiel einer INI Datei welches zeigt wie Zend_Dojo aktiviert werden kann.

  1. resources.dojo.enable = true ; Always load the Dojo javascript files

Das Zend_Dojo Ressource Plugin verwendet die Optionen für Zend_Dojo_View_Helper_Dojo_Container::setOptions() um die Viewhelfer zu konfigurieren. Sehen Sie bitte im Kapitel über Zend_Dojo für eine vollständige Beschreibung und die vorhandenen Optionen nach.

Zend_Application_Resource_Frontcontroller

Die warscheinlich am meisten verwendete Ressource die man mit Zend_Application verwenden wird, ist die Front Controller Ressource, die eine Möglichkeit bietet den Zend_Controller_Front zu konfigurieren. Diese Ressource bietet die Möglichkeit verschiedenste Front Controller Parameter zu setzen, Plugins zu spezifizieren die initialisiert werden sollen, und vieles mehr.

Sobald Sie initialisiert wurde, fügt die Ressource die $frontController Eigenschaft vom Bootstrap in die Zend_Controller_Front Instanz hinzu.

Die folgenden Konfigurationsschlüssel sind vorhanden, und sind abhängig von der Groß- oder Kleinschreibung:

  • controllerDirectory: Entweder ein Stringwert der ein einzelnes Controller Verzeichnis spezifiziert, oder ein Array von Modul und Controller Verzeichnis Paaren.

  • moduleControllerDirectoryName: Ein Stringwert der auf ein Unterverzeichnis unter einem Modul zeigt, das Controller enthält.

  • moduleDirectory: Verzeichnis in dem Module gefunden werden können.

  • defaultControllerName: Basisname des Standard Controllers (normalerweise "index").

  • defaultAction: Basisname der Standard Aktion (normalerweise "index").

  • defaultModule: Basisname des Standard Moduls (normalerweise "default").

  • baseUrl: Explizite Basis URL zur Anwendung (normalerweise automatisch erkannt).

  • plugins: Array von Front Controller Plugin Klassennamen. Die Ressource wird jede Klasse instanziieren (ohne Contructor Argumente) und die Instanz dann mit dem Front Controller registrieren. Wenn man ein Plugin mit einem speziellen Stackindex registriert muss man ein Array mit den zwei Schlüsseln class und stackIndex angeben.

  • params: Array von Schlüssel und Wert Paaren die mit dem Front Controller registriert werden sollen.

  • returnresponse: Ob das Response Objekt nach dem Dispatchen des Front Controllers zurückgegeben wird oder nicht. Der Wert sollte ein Boolean sein; standardmäßig ist er deaktiviert.

Wenn ein Schlüssel übergeben wird der nicht erkannt wird, wird dieser als Parameter beim Front Controller registriert, indem er an setParam() übergeben wird.

Example #4 Beispiel der Konfiguration einer Front Controller Ressource

Anbei ist ein Beispiel eines INI Abschnitts der zeigt wie die Front Controller Ressource konfiguriert werden kann.

  1. [production]
  2. resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
  3. resources.frontController.moduleControllerDirectoryName = "actions"
  4. resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"
  5. resources.frontController.defaultControllerName = "site"
  6. resources.frontController.defaultAction = "home"
  7. resources.frontController.defaultModule = "static"
  8. resources.frontController.baseUrl = "/subdir"
  9. resources.frontController.plugins.foo = "My_Plugin_Foo"
  10. resources.frontController.plugins.bar = "My_Plugin_Bar"
  11. resources.frontController.plugins.baz.class = "My_Plugin_Baz"
  12. resources.frontController.plugins.baz.stackIndex = 123
  13. resources.frontController.returnresponse = 1
  14. resources.frontController.env = APPLICATION_ENV
  15.  
  16. ; Das folgende verweist auf:
  17. ; Zend_Controller_Action_HelperBroker::addPath('Helper_Path', $helperPrefix);
  18. resources.frontController.actionHelperPaths.HELPER_Prefix = "My/Helper/Path"

Example #5 Empfangen des Front Controllers im eigenen Bootstrap

Sobald die Front Controller Ressource initialisiert wurde, kann die Front Controller Instanz über die $frontController Eigenschaft der Bootstraps geholt werden.

  1. $bootstrap->bootstrap('frontController');
  2. $front = $bootstrap->frontController;

Zend_Application_Resource_Layout

Zend_Application_Resource_Layout kann verwendet werden um Zend_Layout zu konfigurieren. Die Optionen für die Konfiguration sind die Optionen von Zend_Layout.

Example #6 Einfache Konfiguration eines Layouts

Anbei ist ein beispielhaftes INI Schnipsel das zeigt wie Layout Ressourcen konfiguriert werden können.

  1. resources.layout.layout = "NameOfDefaultLayout"
  2. resources.layout.layoutPath = "/path/to/layouts"

Zend_Application_Resource_Locale

Zend_Application_Resource_Locale kann verwendet werden um ein Anwendungsweites Gebietsschema zu setzen welches dann in allen Klassen und Komponenten verwendet wird welche mit Lokalisierung oder Internationalisierung arbeiten. Standardmäßig wird das Gebietsschema in einem Zend_Registry Eintrag mit dem Schlüssel 'Zend_Locale' gespeichert.

Es gibt grundsätzlich drei Anwendungsfälle für das Locale Ressource Plugin. Jeder von Ihnen sollte abhängig auf den Notwendigkeiten der Anwendung verwendet werden.

Automatische Erkennung des zu verwendenden Gebietsschemas

Ohne Spezifikation einer Option für Zend_Application_Resource_Locale, erkennt Zend_Locale das Gebietsschema, welches in der Anwendung verwendet werden soll automatisch.

Diese Erkennung funktioniert weil der Client die gewünschte Sprache in seiner HTTP Anfrage sendet. Normalerweise sendet der Client die Sprache welche er sehen will, und Zend_Locale verwendet diese Information für die Erkennung.

Aber es gibt 2 Probleme mit diesem Verfahren:

  • Der Browser könnte so eingestellt sein das er keine Sprache sendet

  • Der Benutzer könnte ein Gebietsschema manuell gesetzt haben das gar nicht existiert

In beiden Fällen wird Zend_Locale auf einen anderen Mechanismus zurückfallen um das Gebietsschema zu erkennen:

  • Wenn ein Gebietsschema gesetzt wird das nicht existiert versucht Zend_Locale diesen String degradieren.

    Wenn zum Beispiel en_ZZ gesetzt wird, dann wird es automatisch zu en degradiert. In diesem Fall wird en als Gebietsschema für die Anwendung verwendet.

  • Wenn das Gebietsschema durch das degradieren nicht erkannt wird, dann wird das Gebietsschema der Umgebung (Web Server) verwendet. Die meisten vorhandenen Umgebungen von Web Hostern verwenden en als Gebietsschema.

  • Wenn das Gebietsschema des Systems nicht erkannt wird, verwendet Zend_Locale sein eigenes Standardgebietsschema, welches standardmäßig auf en gesetzt wird.

Für weitere Informationen über die Erkennung von Gebietsschema sollte in dieses Kapitel für Zend_Locale's automatischer Erkennung gesehen werden.

Das Gebietsschema automatisch erkennen und ein eigenes Fallback hinzufügen

Die automatische Erkennung von vorher könnte zu Problemen führen wenn das Gebietsschema nicht erkannt werden kann und man ein anderes Standardgebietsschema als en haben will. Um das zu verhindern erlaubt es Zend_Application_Resource_Locale ein eigenes Gebietsschema zu setzen welches in dem Fall verwendet wird wenn kein Gebietsschema erkannt wird.

Example #7 Automatische Erkennung des Gebietsschemas und setzen eines Fallbacks

Der folgende Abschnitt zeigt wie ein eigenes Standardgebietsschema gesetzt werden kann welches verwendet wird wenn der Client selbst kein Gebietsschema sendet.

  1. ; Versucht zuerst die automatische Erkennung,
  2. ; ist diese nicht erfolgreich wird nl_NL als Fallback verwendet
  3. resources.locale.default = "nl_NL"

Erzwingen eines Gebietsschemas für die Verwendung

Manchmal ist es nützlich ein einzelnes Gebietsschema zu definieren welches verwendet werden soll. Das kann durch Verwendung der Option force getan werden.

In diesem Fall wird dieses einzelne Gebietsschema verwendet und die automatische Erkennung wird ausgeschaltet.

Example #8 Definition eines einzelnen Gebietsschemas für die Verwendung

Der folgende Abschnitt zeigt wie ein einzelnes Gebietsschema für die komplette Anwendung gesetzt werden kann.

  1. ; Unabhängig von allem wird das Gebietsschema nl_NL verwendet
  2. resources.locale.default = "nl_NL"
  3. resources.locale.force = true

Zend_Application_Resource_Log

Zend_Application_Resource_Log instanziert eine Instanz von Zend_Log mit einer beliebigen Anzahl an Log Writern. Die Konfiguration wird der Zend_Log::factory() Methode übergeben, was es erlaubt Kombinationen von Log Writern und Filtern zu spezifizieren. Die Log Instanz kann später durch den Bootstrap empfangen werden um Events zu loggen.

Example #9 Beispiel Konfiguration einer Log Ressource

Anbei ist ein Beispiel eines INI Abschnitts der zeigt wir die Log Ressource konfiguriert wird.

  1. resources.log.stream.writerName = "Stream"
  2. resources.log.stream.writerParams.stream = APPLICATION_PATH "/../data/logs/application.log"
  3. resources.log.stream.writerParams.mode = "a"
  4. resources.log.stream.filterName = "Priority"
  5. resources.log.stream.filterParams.priority = 4

Für weitere Informationen über vorhandene Optionen, siehe in die Dokumentation von Zend_Log::factory().

Zend_Application_Resource_Mail

Zend_Application_Resource_Mail kann verwendet werden um einen Transport für Zend_Mail zu instanzieren, oder den Standardnamen und Adresse zu setzen, sowie die standardmäßigen replyto- Namen und Adressen.

Wenn ein Transport instanziert wird, wird er automatisch bei Zend_Mail registriert. Aber durch das Setzen der transport.register Direktive auf FALSE, findet dieses Verhalten nicht mehr statt.

Example #10 Beispiel der Konfiguration der Mail Ressource

Anbei ist ein beispielhafter INI Abschnitt der zeigt wie das Mail Ressource Plugin konfiguriert wird.

  1. resources.mail.transport.type = smtp
  2. resources.mail.transport.host = "smtp.example.com"
  3. resources.mail.transport.auth = login
  4. resources.mail.transport.username = myUsername
  5. resources.mail.transport.password = myPassword
  6. resources.mail.transport.register = true ; True by default
  7.  
  8. resources.mail.defaultFrom.email = john@example.com
  9. resources.mail.defaultFrom.name = "John Doe"
  10. resources.mail.defaultReplyTo.email = Jane@example.com
  11. resources.mail.defaultReplyTo.name = "Jane Doe"

Zend_Application_Resource_Modules

Zend_Application_Resource_Modules wird verwendet im eigene Anwendungsmodule zu initialisieren. Wenn das Modul eine Bootstrap.php Datei in seinem Root hat, und es eine Klasse die Module_Bootstrap heißt enthält (wobei "Module" der Modulname ist), dann wird diese Klasse verwendet um das Modul zu bootstrappen.

Standardmäßig wird eine Instanz vom Zend_Application_Module_Autoloader für das Modul erstellt, indem der Modulname und das Verzeichnis dazu verwendet werden sie zu initialisieren.

Da die Modul Ressourcen standardmäßig keine Argumente entgegen nehmen muss man, um das über die Konfiguration zu gestatten, diese als leeres Array erstellen. In der INI Stil Konfiguration sieht das etwa so aus:

  1. resources.modules[] =

In XML Stil Konfiguration sieht das etwa so aus:

  1. <resources>
  2.     <modules>
  3.         <!-- Platzhlter um sicherzustellen das ein Array erstellt wird -->
  4.         <placeholder />
  5.     </modules>
  6. </resources>

Bei Verwendung eines PHP Arrays, einfach Erstellen indem ein leeres Array verwendet wird:

  1. $options = array(
  2.     'resources' => array(
  3.         'modules' => array(),
  4.     ),
  5. );

Note: Abhängigkeiten der Front Controller Ressource
Die Module Ressource hat eine Abhängigkeit zur Front Controller Ressource. Man kann natürlich seine eigenen Ersatz für diese Ressource, über eine eigene Front Controller Ressource Klasse, anbieten oder eine Initialisierungsmethode für eine Klasse -- solange die Ressource Plugin Klasse mit "Frontcontroller" endet, oder die Initialisierungsmethode "_initFrontController" heißt (abhängig von der Groß- und Kleinschreibung).

Example #11 Module konfigurieren

Man kann eine modul-spezifische Konfiguration spezifizieren indem der Modulname als Präfix oder Unter-Sektion in der Konfigurationsdatei verwendet wird.

Nehmen wir als Beispiel an, das die eigene Anwendung ein "news" Modul hat. Nachfolgend sind die INI und XML Beispiele die eine Konfiguration von Ressourcen in diesem Modul zeigen.

  1. [production]
  2. news.resources.db.adapter = "pdo_mysql"
  3. news.resources.db.params.host = "localhost"
  4. news.resources.db.params.username = "webuser"
  5. news.resources.db.params.password = "XXXXXXX"
  6. news.resources.db.params.dbname = "news"
  1. <?xml version="1.0"?>
  2. <config>
  3.     <production>
  4.         <news>
  5.             <resources>
  6.                 <db>
  7.                     <adapter>pdo_mysql</adapter>
  8.                     <params>
  9.                         <host>localhost</host>
  10.                         <username>webuser</username>
  11.                         <password>XXXXXXX</password>
  12.                         <dbname>news</dbname>
  13.                     </params>
  14.                     <isDefaultAdapter>true</isDefaultAdapter>
  15.                 </db>
  16.             </resources>
  17.         </news>
  18.     </production>
  19. </config>

Example #12 Eine spezielle Modul Bootstrap erhalten

Manchmal will man ein Bootstrap Objekt für ein spezifisches Modul erhalten -- möglicherweise um andere Bootstrap Methoden auszuführen, oder um den Autoloader zu holen damit er konfiguriert werden kann. Das kann man erreichen indem die getExecutedBootstraps() Methode der Modul Ressource verwendet wird.

  1. $resource = $bootstrap->getPluginResource('modules');
  2. $moduleBootstraps = $resource->getExecutedBootstraps();
  3. $newsBootstrap = $moduleBootstraps['news'];

Zend_Application_Resource_Multidb

Zend_Application_Resource_Multidb wird verwendet um mehrere Datenbankverbindungen zu initialisieren. Man kann die gleichen Optionen wie beim Db Ressource Plugin verwenden. Trotzdem kann für das Spezifizieren einer Standardverbindung auch die 'default' Direktive verwendet werden.

Example #13 Mehrere Db Verbindungen konfigurieren

Anbei ist eine beispielhafte INI Konfiguration die verwendet werden kann um zwei Db Verbindungen zu initialisieren.

  1. [production]
  2. resources.multidb.db1.adapter = "pdo_mysql"
  3. resources.multidb.db1.host = "localhost"
  4. resources.multidb.db1.username = "webuser"
  5. resources.multidb.db1.password = "XXXX"
  6. resources.multidb.db1.dbname = "db1"
  7.  
  8. resources.multidb.db2.adapter = "pdo_pgsql"
  9. resources.multidb.db2.host = "example.com"
  10. resources.multidb.db2.username = "dba"
  11. resources.multidb.db2.password = "notthatpublic"
  12. resources.multidb.db2.dbname = "db2"
  13. resources.multidb.db2.default = true

Example #14 Einen speziellen Datenbankadapter empfangen

Wenn dieses Ressource Plugin verwendet wird, will man normalerweise eine spezifische Datenbank erhalten. Das kann durch Verwendung von getDb() von der Ressource getan werden. Die Methode getDb() gibt eine Instanz einer Klasse zurück welche Zend_Db_Adapter_Abstract erweitert. Wenn man keine Standarddatendank gesetzt hat, wird eine Exception geworfen wenn diese Methode ohne die Spezifikation eines Parameters aufgerufen wird.

  1. $resource = $bootstrap->getPluginResource('multidb');
  2. $db1 = $resource->getDb('db1');
  3. $db2 = $resource->getDb('db2');
  4. $defaultDb = $resource->getDb();

Example #15 Den standardmäßigen Datenbankadapter empfangen

Zusätzlich kann der standardmäßige Datenbankadapter empfangen werden indem die Methode getDefaultDb() verwendet wird. Wenn man keinen standardmäßigen Adapter gesetzt hat, wird der erste konfigurierte Db Adapter zurückgegeben. Wenn man FALSE als ersten Parameter spezifiziert dann wird NULL zurückgegeben wenn kein standardmäßiger Datenbankadapter gesetzt wurde.

Anbei ist ein Beispiel welches annimmt dass das Multidb Ressource Plugin mit dem obigen INI Beispiel konfiguriert wurde:

  1. $resource = $bootstrap->getPluginResource('multidb');
  2. $db2 = $resource->getDefaultDb();
  3.  
  4. // Selbe Konfiguration, aber ohne eine standardmäßige Db:
  5. $db1 = $resource->getDefaultDb();
  6. $null = $resource->getDefaultDb(false); // Null

Zend_Application_Resource_Navigation

Zend_Application_Resource_Navigation kann verwendet werden um eine Zend_Navigation Instanz zu konfigurieren. Die Optionen der Konfiguration entsprechen den Optionen von Zend_Navigation.

Sobald die Instanz der Navigation konfiguriert wurde, wird diese standardmäßig Zend_View_Helper_Navigation zugeordnet -- von der es später geholt werden kann.

Example #16 Beispiel der Konfiguration einer Navigations Ressource

Anbei ist ein Beispiel eines INI Abschnitts der zeigt wir die Navigations Ressource konfiguriert wird.

  1. resources.navigation.pages.page1.label = "Überschrift der ersten Zeile"
  2. resources.navigation.pages.page1.route = "Route die der ersten Seite gehört"
  3.  
  4. ; Page 2 is a subpage of page 1
  5. resources.navigation.pages.page1.pages.page2.type = "Zend_Navigation_Page_Uri"
  6. resources.navigation.pages.page1.pages.page2.label = "Überschrift Seite zwei"
  7. resources.navigation.pages.page1.pages.page2.uri = "/url/to/page/2"

Zend_Application_Resource_Router

Zend_Application_Resource_Router kann verwendet werden um den Router so zu konfigurieren wie er im Front Controller registriert wird. Die Konfigurationsoptionen sind die gleichen wie die Optionen von Zend_Controller_Router_Route.

Example #17 Beispiel Konfiguration für eine Router Ressource

Anbei ist ein Beispiel INI Stück welches zeigt wie die Router Ressource konfiguriert wird.

  1. resources.router.routes.route_id.route               = "/login"
  2. resources.router.routes.route_id.defaults.module     = "admin"
  3. resources.router.routes.route_id.defaults.controller = "user"
  4. resources.router.routes.route_id.defaults.action     = "login"
  5.  
  6. ; Optional kann ein Chain Name Separator gesetzt werden:
  7. resources.router.chainNameSeparator = "_"
  8.  
  9. ; Beispiel mit Parameter
  10. resources.router.routes.route_id.route               = "/user/:user_id"
  11. resources.router.routes.route_id.defaults.module     = "admin"
  12. resources.router.routes.route_id.defaults.controller = "user"
  13. resources.router.routes.route_id.defaults.action     = "edit"
  14. resources.router.routes.route_id.reqs.user_id        = "^\d+$"

Für weitere Informationen über den Chain Name Separator, sehen Sie bitte in dessen Sektion.

Zend_Application_Resource_Session

Zend_Application_Resource_Session erlaubt es Zend_Session zu konfigurieren, sowie optional einen Session SaveHandler zu initialisieren.

Um einen Session Save Handler zu setzen, muß einfach der Optionsschlüssel saveHandler (Groß- und Kleinschreibung beachten) an die Ressource übergeben werden. Der Wert dieser Option kann einer der folgenden sein:

  • String : Ein String der eine Klasse benennt die Zend_Session_SaveHandler_Interface implementiert und initiiert werden soll.

  • Array : Ein Array mit den Schlüsseln "class", und optional "options", das eine Klasse benennt die Zend_Session_SaveHandler_Interface implementiert und iniiert werden, und ein Array von Optionen die an dessen Contructor übergeben werden soll.

  • Zend_Session_SaveHandler_Interface: Ein Objekt welches dieses Interface implementiert.

Jeder andere übergebene Optionsschlüssel wird an Zend_Session::setOptions() übergeben um Zend_Session zu konfigurieren.

Example #18 Beispiel der Konfiguration einer Session Ressource

Anbei ist das Beispiel eines INI Abschnitts der zeigt wie die Session Ressource konfiguriert werden kann. Er setzt verschiedene Zend_Session Optionen, und konfiguriert eine Zend_Session_SaveHandler_DbTable Instanz.

  1. resources.session.save_path = APPLICATION_PATH "/../data/session"
  2. resources.session.use_only_cookies = true
  3. resources.session.remember_me_seconds = 864000
  4. resources.session.saveHandler.class = "Zend_Session_SaveHandler_DbTable"
  5. resources.session.saveHandler.options.name = "session"
  6. resources.session.saveHandler.options.primary.session_id = "session_id"
  7. resources.session.saveHandler.options.primary.save_path = "save_path"
  8. resources.session.saveHandler.options.primary.name = "name"
  9. resources.session.saveHandler.options.primaryAssignment.sessionId = "sessionId"
  10. resources.session.saveHandler.options.primaryAssignment.sessionSavePath = "sessionSavePath"
  11. resources.session.saveHandler.options.primaryAssignment.sessionName = "sessionName"
  12. resources.session.saveHandler.options.modifiedColumn = "modified"
  13. resources.session.saveHandler.options.dataColumn = "session_data"
  14. resources.session.saveHandler.options.lifetimeColumn = "lifetime"

Note: Die Datenbank zuerst bootstrappen!
Wenn man den Zend_Session_SaveHandler_DbTable Session Save Handler konfiguriert, muß man für diesen zuerst die Datenbank Verbindung konfigurieren damit er arbeitet. Das kann entweder durch Verwendung der Db Ressource getan werden -- und indem man sicherstellt das der "resources.db" Schlüssel vor dem "resources.session" Schlüssel kommt -- oder durch Schreiben einer eigenen Ressource welche die Datenbank initialisiert, und im speziellen den standardmäßigen Zend_Db_Table Adapter setzt.

Zend_Application_Resource_View

Zend_Application_Resource_View kann verwendet werden um eine Instanz von Zend_View zu konfigurieren. Konfigurations Optionen sind die Zend_View Optionen.

Sobald die View Instanz konfiguriert wurde, erstellt Sie eine Instanz von Zend_Controller_Action_Helper_ViewRenderer und registriert den ViewRenderer im Zend_Controller_Action_HelperBroker -- von dem man Sie später empfangen kann.

Example #19 Beispiel der Konfiguration einer View Ressource

Anbei ist das Beispiel eines INI Abschnitts der zeigt wie die View Ressource konfiguriert werden kann.

  1. resources.view.encoding = "UTF-8"
  2. resources.view.basePath = APPLICATION_PATH "/views/"
blog comments powered by Disqus