Development

Documentation/de_DE/book/1.0/19-Mastering-Symfony-s-Configuration-Files

You must first sign up to be able to contribute.

Version 3 (modified by Jan.Kunzmann, 10 years ago)
60%

ARBEITSENTWURF ROHÜBERSETZUNG / TRANSLATION WORKING DRAFT
Originaldokument: http://svn.symfony-project.com/doc/trunk/book/19-Mastering-Symfony-s-Configuration-Files.txt, Version 7705 vom 2008-03-01
Übersetzungsfortschritt: 60%
Übersetzung: JK
Korrekturfortschritt: 0%

Chapter 19 - Symfonys Konfigurationsdateien meistern

Nun, da Sie Symfony sehr gut kennen, sind Sie bereits in der Lage, in die Tiefen seines Codes abzutauchen, um das Kerndesign zu verstehen und neue, versteckte Möglichkeiten zu entdecken. Bevor Sie jedoch die Symfony-Klassen für Ihre eigenen Bedürfnisse erweitern, sollten Sie noch einen Blick auf einige Konfigurationsdateien werfen. Viele Features sind bereits in Symfony eingebaut und können durch einfaches Ändern einer Konfigurationseinstellung aktiviert werden. Das heißt, dass Sie das Verhalten Symfony-Kerns verändern können, ohne die Klassen abzuleiten. Dieses Kapitel führt Sie tief in die Konfigurationsdateien und zeigt deren mächtige Fähigkeiten.

"Settings" - Die Symfony-Einstellungen

Die Datei frontend/config/settings.yml enthält Symfonys Hauptkonfiguration für die Anwendung meineapp. Obwohl Sie bereits in den vorangegangenen Kapiteln die Funktion vieler Einstellungen in dieser Datei gesehen haben, wollen wir Sie hier nochmal rekapitulieren.

Wie in Kapitel 5 erklärt, ist diese Datei abhängig von der Umgebung, das bedeutet, dass jede Einstellung für jede Umgebung einen anderen Wert annehmen kann. Sicher erinnern Sie sich daran, dass auf jeden der hier definierten Parameter auch aus dem PHP-Code über die Klasse sfConfig zugegriffen werden kann. Der Parametername ist der Name der Einstellung mit einem vorangestellten sf_. Wenn Sie z.B. den Wert des Parameters cache ermitteln wollen, rufen Sie einfach sfConfig::get('sf_cache') auf.

Standard-Module und -Actions

Wenn keine Routingregel die Parameter module oder action festlegt, werden statt dessen die Werte aus settings.yml verwendet:

  • default_module: Standardmäßiger Request-Parameter module. Voreinstellung ist das Modul default.
  • default_action: Standardmäßiger Request-Parameter action. Voreinstellung ist die Action index.

Symfony stellt Standardseiten für spezielle Situationen zur Verfügung. Im Falle eines Routing-Fehlers führt Symfony eine Action des default-Moduls aus, welches im Verzeichnis $sf_symfony_data_dir/modules/default/ zu finden ist. settings.yml definiert, welche Action in Abhängigkeit vom Fehler ausgeführt werden soll:

  • error_404_module und error_404_action: Diese Action wird aufgerufen, wenn die URL des Benutzers auf keine Routingregel passt oder wenn eine sfError404Exception auftritt. Standardwert ist default/error404.
  • login_module and login_action: Diese Action wird aufgerufen, wenn ein nicht authentifizierter Benutzer versucht, eine Seite zu öffnen, die in security.yml als sicher (secure) markiert ist (Details hierzu in Kapitel 6). Standardwert ist default/login.
  • secure_module and secure_action: Diese Action wird aufgerufen, wenn der Benutzer nicht die notwendigen Berechtigungen hat, um eine Action auszuführen. Standardwert ist default/secure.
  • module_disabled_module and module_disabled_action: Diese Action wird aufgerufen, wenn der User ein Modul anfragt, das in module.yml deaktiviert wurde. Standardwert ist default/disabled.

Bevor Sie eine Anwendung für den produktiven Betrieb ausliefern, sollten Sie diese Actions anpassen, da die Templates des default-Moduls das Symfony-Logo auf der Seite einbinden. Abbildung 19-1 zeigt einen Screenshot einer dieser Seiten, der Seite für den Fehler 404.

Figure 19-1 - Standardseite für den Fehler 404

Standardseite für den Fehler 404

Sie könenn die Standardseiten auf zwei Arten übersteuern:

  • Sie können ein eigenes Standardmodul im Verzeichnis modules/ Ihrer Anwendung anlegen, in dem Sie alle entsprechenden Actions (index, error404, login, secure, disabled) und alle verwandten Templates (indexSuccess.php, error404Success.php, loginSuccess.php, secureSuccess.php, disabledSuccess.php) selbst definieren.
  • Sie können die voreingestellten Modul- und Action-Einstellungen in settings.yml so ändern, dass Seiten Ihrer Anwendung verwendet werden.

Noch zwei andere Seiten tragen den Symfony-Look und müssen auch vor der Produktivsetzung angepasst werden. Diese Seiten sind nicht im default-Modul, da sie aufgerufen werden, wenn Symfony nicht richtig funktioniert. Sie finden diese Standardseiten im Verzeichnis $sf_symfony_data_dir/web/errors/:

  • error500.php: Diese Seite wird aufgerufen, wenn ein "Interner Serverfehler" in der Produktionsumgebung auftritt. In anderen Umgebungen (wo SF_DEBUG auf true gesetzt ist) zeigt Symfony den kompletten Ausführungsstapel und eine explizite Meldung an, wenn ein Fehler auftritt (in Kapitel 16 finden Sie weitere Details).
  • unavailable.php: Diese Seite wird aufgerufen, wenn ein User eine Anfrage startet, während die Anwendung abgeschaltet ist (über den Task disable). Sie wird auch aufgerufen, wenn der Cache gelöscht wird (also zwischen dem Aufruf von symfony clear-cache und dem Ausführungsende dieses Tasks). Bei Systemen mit sehr großem Cache kann der Löschprozess durchaus mehrere Sekunden dauern. Symfony kann keine Requests ausfüllen, solange der Cache nur teilweise geleert ist, deshalb werden Requests bis zum Ende des Löschvorgangs auf diese Seite umgeleitet.

Um diese Seiten anzupassen, erzeugen Sie einfach error500.php und unavailable.php in dem Verzeichnis web/errors/. Symfony wird dann diese anstelle der eigenen verwenden.

NOTE Um Requests, wenn nötig, auf die Seite unavailable.php umzuleiten, müssen Sie die Einstellung check_lock in der settings.yml der Anwendung auf on setzen. Diese Überprüfung ist standardmäßig nicht aktiv, da sie jedem Request einen kleinen Overhead hinzufügt.

Aktivierung optionaler Features

Einige Parameter in settings.yml kontrollieren optionale Fähigkeiten des Frameworks, die an- oder ausgeschaltet werden können. Da das Abschalten ungenutzter Features die Ausführungsgeschwindigkeit erhöht, sollten Sie vor den Ausliefern der Anwendung die Einstellungen aus Tabelle 19-1 sorgfältig kontrollieren.

Tabelle 19-1 - Optionale Features, definiert in settings.yml

Parameter | Beschreibung | Standardwert ----------------------- | ----------- | ------------- use_database | Aktiviert den Datenbank-Manager. Wenn Sie keine Datenbank verwenden, setzen Sie die Einstellung auf off. | on use_security | Aktiviert die Sicherheitsmerkmale (Sichere Actions und Zugangskontrolle; siehe Kapitel 6). Der voreingestellte Sicherheitsfilter (sfBasicSecurityFilter) ist nur dann aktiv, wenn diese Einstellung on ist. | on use_flash | Aktiviert den "Flash" (siehe Kapitel 6). Setzen Sie diesen Wert auf off, wenn Sie die Methode setFlash() der Klasse sfUser nicht benutzen. | on i18n | Aktiviert die Internationalisierung der Benutzerschnittstelle (siehe Kapitel 13). Für mehrsprachige Anwendungen setzen Sie hier on. | off logging_enabled | Aktiviert das Protokollieren (Logging) von Ereignissen in Symfony. Setzen Sie diesen Wert auf off, wenn die Angaben in logging.yml ignoriert werden sollen und Sie das Protokoll komplett deaktiveren sollen. | on escaping_strategy | Aktiviert die Ausgabemaskierung und legt deren Methodik fest (siehe Kapitel 7). Setzen Sie hier off, wenn Sie den $sf_data-Containern in Ihren Templates nicht verwenden. | bc cache | Aktiviert das Template-Caching (siehe Kapitel 12). Setzen Sie diesen Wert auf on, wenn eines Ihrer Module eine cache.yml enthält. Der Cache-Filter (sfCacheFilter) ist nur dann aktiv, wenn diese Einstellung on ist. | off in development, on in production web_debug | Aktiviert die Web-Debug-Toolbar für bequemes Debugging (siehe Kapitel 16). Setzen Sie hier on, um die Toolbar auf jeder Seite anzuzeigen. Der Web-Debug-Filter (sfWebDebugFilter) ist nur dann aktiv, wenn diese Einstellung on ist. | on in development, off in production check_symfony_version | Aktiviert die Überprüfung der Symfony-Version bei jedem Request. Setzen Sie diesen Wert auf on, wenn Sie den Cache automatisch leeren wollen, wenn Sie das Framework aktualisiert haben. Lassen Sie den Wert auf off, wenn Sie den Cache nach einem Upgrade stets manuell leeren. | off check_lock | Aktiviert das Lock-System der Anwendung, das durch die Tasks clear-cache und disable ausgelöst wird (siehe vorheriger Abschnitt). Wenn Sie hier on angeben, werden alle Requests auf deaktivierte Anwendungen auf $sf_symfony_data_dir/web/errors/unavailable.php umgeleitet. | off compressed | Aktiviert die Antwortkompression von PHP. Setzen Sie den Wert auf on, um den erzeugten HTML-Code durch den PHP-Kompressionshandler komprimieren zu lassen. | off use_process_cache | Aktiviert Optimierungen durch PHP-Beschleuniger. Wenn ein solcher Beschleuniger (z.B. APC, XCache oder eAccelerator) installiert ist, kann Symfony davon profitieren, indem es Objekte und Konfigurationen zwischen den Requests im Speicher hält. Setzen Sie den Parameter in der Entwicklungsumgebung auf off oder wenn Sie keine Optimierungen verwenden wollen. Wenn Sie jedoch keinen Beschleuniger installiert haben, wird on dennoch keinen negativen Einfluss auf die Performance haben. | on

Konfiguration der Features

Symfony verwendet einige der Parameter aus settings.yml, um das Verhalten von eingebauten Features (z.B. Formularvalidierung, Caching, Module von Drittanbietern) zu verändern.

Einstellungen für die Ausgabemaskierung (Output Escaping)

Die Einstellungen für die Ausgabemaskierung bestimmen die Art, wie im Template auf Variablen zugegriffen werden kann (siehe Kapitel 7). Die Datei settings.yml hat zwei Einstellungen zu diesem Feature:

  • Die Einstellung escaping_strategy (Maskierungs-Strategie) kann die Werte bc, both, on oder off annehmen.
  • Die Einstellung escaping_method (Maskierungs-Methode) kann auf ESC_RAW, ESC_ENTITIES, ESC_JS oder ESC_JS_NO_ENTITIES gesetzt werden.

Einstellungen für das Routing

Zwei Einstellungen zum Routing (siehe Kapitel 9) befinden sich in settings.yml:

  • Der Parameter suffix (Anhang) bestimmt die Dateiendungen für erzeugte URLs. Standardwert ist ein Punkt (.), so dass keine Erweiterung angehängt wird. Setzen Sie diesen Wert beispielsweise auf .html, dann sehen alle erzeugten URLs wie statische Dateien aus.
  • Der Parameter no_script_name (Kein Scriptname) gibt an, ob der Scriptname des Frontcontrollers in erzeugten URLs erscheint. Die Einstellung kann nur für eine einzige Anwendung in einem Projekt on sein, es sei denn, Sie speichern die Frontcontroller in unterschiedlichen Verzeichnissen und verändern die vorgegebenen Regel des URL-Rewriters. Gewöhnlich werden Sie diesen Wert für die Hauptanwendung in der Produktionsumgebung auf on setzen, ansonsten auf off.

Einstellungen für die Formular-Validierung

Mit den Einstellungen zur Formular-Validierung kontrollieren Sie, wie Fehlermeldungen der `Validation-Helfer aussehen (siehe Kapitel 10). Diese Fehler sind in

'-Tags eingebettet, wobei das Attribut class auf den Wert von validation_error_class gesetzt und das Attribut id aus validation_error_id_prefix zusammengesetzt wird. Standardwerte sind form_error und error_for_, so dass ein Aufruf des Helfers form_error() für eine Eingabebox namens foobar die Attribute class="form_error" id="error_for_foobar" ausgibt.

Zwei weitere Einstellungen legen fest, welche Zeichen vor und nach jeder Fehlermeldung ausgegeben werden: validation_error_prefix und validation_error_suffix. Sie können dieser Werte ändern, um alle Fehlermeldungen auf einmal anzupassen.

Einstellungen für den Cache

Die Cache-Einstellungen befinden größtenteils in cache.yml, bis auf zwei in settings.yml: cache aktiviert den Template-Cache, und etag aktiviert die serverseitige Verarbeitung von ETags (siehe Kapitel 15).

Einstellungen für das Logging (Protokollierung)

Zwei Einstellungen zum Logging (siehe Kapitel 16) befinden sich in settings.yml:

  • error_reporting gibt an, welche Ereignisse in die PHP-Logdateien geschrieben werden. Standardmäßig ist dieser Wert in der Produktionsumgebung auf E_PARSE | E_COMPILE_ERROR | E_ERROR | E_CORE_ERROR | E_USER_ERROR gesetzt (also sind die protokollierten Ereignisse E_PARSE, E_COMPILE_ERROR, E_ERROR, E_CORE_ERROR und E_USER_ERROR) und in der Entwicklungsumgebung auf E_ALL | E_STRICT.
  • Die Einstellung web_debug aktiviert die Web-Debug-Toolbar. Setzen Sie sie nur in der Entwicklungs- und der Testumgebung auf on.

Pfade zu eingebundenen Dateien (Assets)

Die Datei settings.yml bestimmt auch die Pfade zu eingebundenen Dateien, Komponenten oder Bibliotheken (Anm.d.Übers.: Die englische Originaldokumentation spricht hier von "Asset"). Wenn Sie von einem solchen Asset eine andere Version verwenden wollen als diejenige, die bereits in Symfony enthalten ist, können Sie diese Pfadangaben ändern:

  • Die JavaScript-Dateien des Editors für formatierten Text liegen in rich_text_js_dir (Standard: js/tiny_mce)
  • Die Bibliotheken von Prototype werden in prototype_web_dir gespeichert (Standard: /sf/prototype)
  • Die Dateien, die der Administrations-Generator verwendet, liegen in admin_web_dir
  • Die Dateien, die die Web-Debug-Toolbar verwendet, liegen in web_debug_web_dir
  • Die Dateien, die der Javascript-Kalender verwendet, liegen in calendar_web_dir

Standardhelfer

Die Helfer, die für jedes Template bereits geladen sein sollen, werden in der Einstellung standard_helpers angegeben (siehe Kapitel 7). Standardmäßig sind dies die Helfergruppen Partial, Cache und Form. Wenn Sie eine Helfergruppe in allen Templates einer Anwendung verwenden, sparen Sie sich die Verwendung von use_helper() in jedem Template, indem Sie deren Namen an standard_helpers anfügen.

Aktivierte Module

Aktivierge Module aus Plugins oder aus dem Symfony-Kern werden im Parameter enabled_modules aufgeführt. Wenn ein Plugin ein Modul mitbringt, kann ein Benutzer keine Request an dieses Modul schicken, solange es nicht in enabled_modules aufgeführt ist. Das Modul default, das die Standardseiten von Symfony anzeigt ("Willkommen", "Seite nicht gefunden" usw.) ist standardmäßig das einzige aktivierte Modul.

Zeichensatz

Der Zeichensatz der Antworten ist eine allgemeine Einstellung der Anwendung, weil er von vielen Komponenten im Framework verwendet wird (Templates, Ausgabe-Maskierung, Helfer usw.). Sie legen ihn über die Einstellung charset fest. Voreingestellt (und empfohlen) ist utf-8.

Verschiedene Konfigurationseinstellungen

Die Datei settings.yml enthält noch einige weitere Parameter, die intern vom Symfony-Kern für bestimmte Verhaltensweisen verwendet werden. Listing 19-1 zeigt sie so, wie sie in der Konfigurationsdatei auftauchen.

Listing 19-1 - Verschiedene Konfigurationseinstellungen, in frontend/config/settings.yml

# Kommentare aus den Kernklassen des Frameworks entfernen, wie in core_compile.yml angegeben
strip_comments:         on
# Maximale Anzahl von forward-Aufrufen in einer Action, bevor eine Exception geschmissen wird
max_forwards:           5
# Globale Konstanten
path_info_array:        SERVER
path_info_key:          PATH_INFO
url_format:             PATH

SIDEBAR Eigene Einstellungen für Ihre Anwendung hinzufügen

Die Datei settings.yml spezifiziert die Symfony-Einstellungen für eine Anwendung. Wie bereits in Kapitel 5 angesprochen, ist die beste Stelle, um eigene Einstellungen festzulegen, die Datei frontend/config/app.yml. Diese Datei berücksichtigt ebenfalls die gesetzte Umgebung, und auf die Einstellungen, die Sie hier vornehmen, können Sie über die Klasse sfConfig mit dem Prefix app_ zugreifen.

all:
  kreditkarten:
    simulation:       off    # app_kreditkarten_simulation
    visa:             on     # app_kreditkarten_visa
    americanexpress:  on     # app_kreditkarten_americanexpress

Sie können auch eine app.yml-Datei im Konfigurationsverzeichnis des Projekts erstellen und so eigene, projektweite Einstellungen festlegen. Die Konfigurationskaskade gilt auch für diese Datei, so dass Angaben in der app.yml der Anwendungen die aus dem Projektverzeichnis überschreiben.

Erweiterung des Autoloadings

Das Autoloading-Feature, das bereits in Kapitel 2 kurz beschrieben wurde, befreit Sie von der Notwendigkeit, in Ihren Klassendateiein mit require einzubinden, sofern diese in bestimmten Verzeichnissen liegen. Sie können also diese Aufgabe durch das Framework erledigen lassen, wodurch es die notwendigen Klassen erst zur gegebenen Zeit lädt, und nur, wenn sie benötigt werden.

Die Datei autoload.yml enthält die Pfade, in der die zu ladenden Klassen gespeichert sind. Wenn diese Konfigurationsdatei zum ersten Mal verarbeitet wird, durchsucht Symfony alle darin benannten Verzeichnisse. Jedes Mal, wenn in diesen Verzeichnissen eine Datei mit der Erweiterung .php gefunden wird, werden der Pfad und die Namen der darin deklarierten Klassen an eine interne Liste angehängt. Diese Liste wird dann im Cache in einer Datei namens config/config_autoload.yml.php gespeichert. Wenn zur Laufzeit eine Klasse verwendet wird, schaut Symfony nach dem Pfad der entsprehenden Klasse und bindet die .php-Datei automatisch ein.

Das Autoloading funktioniert bei allen .php-Dateien, die Klassen- oder Interface-Definitionen enthalten.

Standardmäßig werden alle Klassen in folgenden Verzeichnissen Ihres Projekts berücksichtigt:

  • meinprojekt/lib/
  • meinprojekt/lib/model
  • meinprojekt/apps/frontend/lib/
  • meinprojekt/apps/frontend/modules/meinmodul/lib

Im Konfigurationsverzeichnis der Standardanwendung befindet sich keine autoload.yml. Wenn Sie die Einstellungen des Frameworks verändern wollen - z.B. weil sich Ihre Klassen an einem anderen Ort der Verzeichnisstruktur befinden -, erzeugen Sie eine leere autoload.yml und überschreiben darin die Einstellungen aus $sf_symfony_data_dir/config/autoload.yml bzw. fügen Ihre eigenen hinzu.

Die Datei autoload.yml muss mit dem Schlüssel autoload: beginnen und die Orte aufführen, in denen Symfony nach Klassen suchen soll. Jeder Ort benötigt einen Bezeichner; dies gibt Ihnen die Möglichkeit, die Voreinstellungen von Symfony zu überschreiben. Für jeden Ort müssen Sie einen Namen (name, erscheint als Kommentar in config_autoload.yml.php) und einen Pfad (path) angeben. Dann definieren Sie noch, ob die Suche rekursiv (recursive) durchgeführt werden soll, so dass Symfony in alle Unterverzeichnisse nach .php-Dateien durchsucht, und ob Sie bestimmte Unterverzeichnisse ausschließen wollen (exclude). Listing 19-2 zeigt die voreingestellten Orte und den Aufbau der Datei.

Listing 19-2 - Voreingestellte Konfiguration für das Autoloading, in $sf_symfony_data_dir/config/autoload.yml

autoload:

  # symfony core
  symfony:
    name:           symfony
    path:           %SF_SYMFONY_LIB_DIR%
    recursive:      on
    exclude:        [vendor]

  propel:
    name:           propel
    path:           %SF_SYMFONY_LIB_DIR%/vendor/propel
    recursive:      on

  creole:
    name:           creole
    path:           %SF_SYMFONY_LIB_DIR%/vendor/creole
    recursive:      on

  propel_addon:
    name:           propel addon
    files:
      Propel:       %SF_SYMFONY_LIB_DIR%/addon/propel/sfPropelAutoload.php

  # plugins
  plugins_lib:
    name:           plugins lib
    path:           %SF_PLUGINS_DIR%/*/lib
    recursive:      on

  plugins_module_lib:
    name:           plugins module lib
    path:           %SF_PLUGINS_DIR%/*/modules/*/lib
    prefix:         2
    recursive:      on

  # project
  project:
    name:           project
    path:           %SF_LIB_DIR%
    recursive:      on
    exclude:        [model, symfony]

  project_model:
    name:           project model
    path:           %SF_MODEL_LIB_DIR%
    recursive:      on

  # application
  application:
    name:           application
    path:           %SF_APP_LIB_DIR%
    recursive:      on

  modules:
    name:           module
    path:           %SF_APP_DIR%/modules/*/lib
    prefix:         1
    recursive:      on

Eine Pfadangabe kann Wildcards enthalten und die Pfadangaben aus constants.php verwenden (siehe nächster Abschnitt). Wenn Sie diese Parameter in der Konfigurationsdatei verwenden, müssen Sie sie in Großbuchstaben schreiben und mit %-Zeichen umschließen.

Durch das Erstellen einer eigenen autoload.yml teilen Sie Symfony Autoloader neue Speicherorte mit, aber möglicherweise möchten Sie den Mechanismus von Symfony um ihren eigenen Autoloader ergänzen. Da Symfony die Standardfunktion spl_autoload_register() verwendet, um seinen Autoload-Handler zu installieren, können Sie weitere Callbacks auf Anwendungsebene in der Datei config.php registrieren:

[php]
// Projektkonfiguration einbinden
include(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

// Symfony-Kern laden
require_once($sf_symfony_lib_dir.'/util/sfCore.class.php');
sfCore::bootstrap($sf_symfony_lib_dir, $sf_symfony_data_dir);

// Hier können Sie ihre eigenen Autoload-Callbacks einfügen
spl_autoload_register(array('myToolkit', 'autoload'));

if (sfConfig::get('sf_debug'))
{
  spl_autoload_register(array('sfAutoload', 'autoloadAgain'));
}

Wenn das Autoloading-System von PHP auf eine neue Klasse stößt, wird es zuerst die Autoloader-Methode von Symfony aufrufen (und so die Orte aus autoload.yml verwenden). Wenn es keine Klassendefinition findet, werden alle anderen Methoden aufgerufen, die über spl_autoload_register() registriert wurden, bis eine Klasse gefunden wurde. Sie können auf diese Weise so viele Autoload-Mechanismen hinzufügen, wie Sie wollen - um beispielsweise eine Brücke (Bridge) zu Komponenten aus anderen Frameworks zu bauen (siehe Kapitel 17).

Angepasste Verzeichnisstruktur

Jedes Mal, wenn das Framework etwas in einem bestimmten Pfad suchen muss (Kernklassen, Templates, Plugins, Konfigurationen usw.), verwendet es Pfadvariablen statt einem fest codierten Pfad. Wenn Sie diese Variablen ändern, können Sie die Verzeichnisstruktur eines Symfonyprojekts komplett anpassen und so beispielsweise Kundenvorgaben bezüglich der Dateiablage umsetzen.

ACHTUNG Obwohl es möglich ist, die Verzeichnisstruktur eines Symfony-Projekts anzupassen, ist das nicht notwendigerweise eine gute Idee. Eine der Stärken eines Frameworks wie Symfony ist, dass sich jeder Webentwickler in deinem solchen Projekt sofort heimisch fühlt, wenn man sich an die Konventionen hält. Sie sollten diesen Aspekt auf jeden Fall gründlich bedenken, bevor Sie sich für eine eigene Verzeichnisstruktur entscheiden.

Die grundlegende Verzeichnisstruktur

Die Pfadvariablen sind in der Datei $sf_symfony_data_dir/config/constants.php definiert, welche bei der Initialisierung der Anwendung eingebunden wird. Gespeichert werden Sie im sfConfig-Objekt, so dass sie einfach überschrieben werden können. Listing 19-3 zeigt eine Liste der Pfadvariablen und der Verzeichnisse, auf die sie sich beziehen.

Listing 19-3 - Variablen der vorkonfigurierten Verzeichnisstruktur, from $sf_symfony_data_dir/config/constants.php

sf_root_dir           # meinprojekt/
                      #   apps/
sf_app_dir            #     frontend/
sf_app_config_dir     #       config/
sf_app_i18n_dir       #       i18n/
sf_app_lib_dir        #       lib/
sf_app_module_dir     #       modules/
sf_app_template_dir   #       templates/
sf_bin_dir            #   batch/
                      #   cache/
sf_base_cache_dir     #     frontend/
sf_cache_dir          #       prod/
sf_template_cache_dir #         templates/
sf_i18n_cache_dir     #         i18n/
sf_config_cache_dir   #         config/
sf_test_cache_dir     #         test/
sf_module_cache_dir   #         modules/
sf_config_dir         #   config/
sf_data_dir           #   data/
sf_doc_dir            #   doc/
sf_lib_dir            #   lib/
sf_model_lib_dir      #     model/
sf_log_dir            #   log/
sf_test_dir           #   test/
sf_plugins_dir        #   plugins/
sf_web_dir            #   web/
sf_upload_dir         #     uploads/

Jede Pfadangabe in ein Schlüsselverzeichnis wird von einem Parameter bestimmt, der mit _dir endet. Verwenden Sie stets die Pfadvariablen anstelle von konstanten Angaben (egal ob relativ oder absolut), so dass Sie sie später ändern können, wenn es notwendig sein sollte. Wenn Sie z.B. eine Datei in das Verzeichnos uploads/ verschieben wollen, sollten Sie sfConfig::get('sf_upload_dir') verwenden anstatt SF_ROOT_DIR.'/web/uploads/'.

Die Verzeichnisstruktur eines Moduls wird erst zur Laufzeit definiert, wenn das Routing-System den Modulnamen ($module_name) ermittelt hat. Sie wird gemäßg der Pfadnamen aufgebaut, die in der Datei constants.php angegeben sind, wie in Listing 19-4 gezeigt.

Listing 19-4 - Variablen für die standardmäßige Verzeichnisstruktur eines Moduls

sf_app_module_dir                 # modules/
module_name                       #  meinmodul/
sf_app_module_action_dir_name     #    actions/
sf_app_module_template_dir_name   #    templates/
sf_app_module_lib_dir_name        #    lib/
sf_app_module_view_dir_name       #    views/
sf_app_module_validate_dir_name   #    validate/
sf_app_module_config_dir_name     #    config/
sf_app_module_i18n_dir_name       #    i18n/

Folglich wird der Pfad zu dem Verzeichnis validate/ des aktuellen Moduls zur Laufzeit dynamisch zusammengesetzt:

[php]
sfConfig::get('sf_app_module_dir').'/'.$module_name.'/'.sfConfig::get('sf_app_module_validate_dir_name')

Anpassen der Verzeichnisstruktur

Die standardmäßige Verzeichnisstruktur müssen Sie möglicherweise anpassen, wenn Sie eine Anwendung für einen Kunden entwickeln, der bereits eine definierte Verzeichnisstruktur hat und nicht gewillt ist, sie so zu ändern, dass sie der Logik von Symfony entspricht. Indem Sie die Variablen sf_XXX_dir und sf_XXX_dir_name mit sfConfig überschreiben, können Sie Symfony mit einer völlig anderen Verzeichnisstruktur arbeiten lassen. Der beste Ort, um dies zu erreichen, ist die anwendungsweite config.php.

ACHTUNG Verwenden Sie die config.php der Anwendung, nicht die des Projekts, um die Variablen sf_XXX_dir und sf_XXX_dir_name mit sfConfig zu überschreiben. Die Datei config/config.php des Projekts wird in einem sehr frühen Stadium des Requests geladen. Die Klasse sfConfig gibt es zu diesem Zeitpunkt allerdings noch nicht, und constants.php ist noch nicht geladen.

Wenn Sie beispielsweise erreichen wollen, dass alle Anwendungen ein gemeinsames Verzeichnis für die Layout-Templates verwenden, fügen Sie folgende Zeile in frontend/config/config.php ein, um die Einstellung sf_app_template_dir zu überschreiben:

[php]
sfConfig::set('sf_app_template_dir', sfConfig::get('sf_root_dir').DIRECTORY_SEPARATOR.'templates');

Beachten Sie, dass die config.php der Anwendung nicht leer ist; wenn Sie also hier Verzeichnisstrukturen definieren, machen Sie das am Ende der Datei.

Das Web-Wurzelverzeichnis des Projekts anpassen

Alle Pfade in constants.php hängen vom Wurzelverzeichnis (engl. "root directory") des Projekts ab, welches als Konstante (SF_ROOT_DIR) im Frontcontroller definiert wird. Für gewöhnlich ist das Wurzelverzeichnis eine Ebene oberhalb des web/-Verzeichnisses, Sie können jedoch auch eine andere Struktur verwenden. Angenommen, die Struktur Ihres Hauptverzeichnisses besteht aus zwei Unterverzeichnissen, einem öffentlichen und einem privaten, wie in Listing 19-5 gezeigt. Typischerweise ist dies bei Projekten der Fall, die auf einem Shared-Host laufen, also einem Webserver, den man sich mit anderen Kunden teilt.

Listing 19-5 - Beispiel einer angepassten Verzeichnisstruktur für einen Shared-Host

symfony/    # Privater Bereich
  apps/
  batch/
  cache/
  ...
www/        # Öffentlicher Bereich
  images/
  css/
  js/
  index.php

In diesem Fall ist das Verzeichnis symfony/ das Wurzelverzeichnis. Deshalb muss der Frontcontroller index.php das SF_ROOT_DIR einfach nur wie folgt festlegen, damit die Anwendung funktioniert:

[php]
define('SF_ROOT_DIR', dirname(__FILE__).'/../symfony');

Da außerdem das öffentliche Verzeichnis www/ lautet anstatt dem üblichen web/, müssen Sie die beiden Dateipfade in config.php entsprechend überschreiben:

[php]
sfConfig::add(array(
  'sf_web_dir'      => SF_ROOT_DIR.DIRECTORY_SEPARATOR.'../www',
  'sf_upload_dir'   => SF_ROOT_DIR.DIRECTORY_SEPARATOR.'../www'.DIRECTORY_SEPARATOR.sfConfig::get('sf_upload_dir_name'),
));