Development

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

You must first sign up to be able to contribute.

Changes between Version 1 and Version 2 of Documentation/de_DE/book/1.0/19-Mastering-Symfony-s-Configuration-Files

Show
Ignore:
Author:
Jan.Kunzmann (IP: 84.190.3.111)
Timestamp:
02/27/08 10:05:29 (10 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/de_DE/book/1.0/19-Mastering-Symfony-s-Configuration-Files

    v1 v2  
    11'''ARBEITSENTWURF ROHÜBERSETZUNG / TRANSLATION WORKING DRAFT'''[[BR]] 
    22Originaldokument: http://svn.symfony-project.com/doc/trunk/book/19-Mastering-Symfony-s-Configuration-Files.txt, Version 4935 vom 2007-08-30[[BR]] 
    3 Übersetzungsfortschritt: 10%[[BR]] 
     3Übersetzungsfortschritt: 50%[[BR]] 
    44Übersetzung: JK[[BR]] 
    55Korrekturfortschritt: 0%[[BR]] 
    6363----------------------- | ----------- | ------------- 
    6464`use_database`          | Aktiviert den Datenbank-Manager. Wenn Sie keine Datenbank verwenden, setzen Sie die Einstellung auf `off`. | `on` 
     65`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` 
     66`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` 
     67`i18n`                  | Aktiviert die Internationalisierung der Benutzerschnittstelle (siehe Kapitel 13). Für mehrsprachige Anwendungen setzen Sie hier `on`. | `off` 
     68`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` 
     69`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` 
     70`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 
     71`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 
     72`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` 
     73`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` 
     74`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` 
     75`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` 
     76 
     77### Konfiguration der Features 
     78 
     79Symfony verwendet einige der Parameter aus `settings.yml`, um das Verhalten von eingebauten Features (z.B. Formularvalidierung, Caching, Module von Drittanbietern) zu verändern. 
     80 
     81#### Einstellungen für die Ausgabemaskierung (Output Escaping) 
     82 
     83Die 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: 
     84 
     85  * Die Einstellung `escaping_strategy` (Maskierungs-Strategie) kann die Werte `bc`, `both`, `on` oder `off` annehmen. 
     86  * Die Einstellung `escaping_method` (Maskierungs-Methode) kann auf `ESC_RAW`, `ESC_ENTITIES`, `ESC_JS` oder `ESC_JS_NO_ENTITIES` gesetzt werden. 
     87 
     88#### Einstellungen für das Routing 
     89 
     90Zwei Einstellungen zum Routing (siehe Kapitel 9) befinden sich in `settings.yml`: 
     91 
     92  * 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. 
     93  * 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`. 
     94 
     95#### Einstellungen für die Formular-Validierung 
     96 
     97Mit den Einstellungen zur Formular-Validierung kontrollieren Sie, wie Fehlermeldungen der `Validation`-Helfer aussehen (siehe Kapitel 10). Diese Fehler sind in `<div>'-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. 
     98 
     99Zwei 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. 
     100 
     101#### Einstellungen für den Cache 
     102 
     103Die 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). 
     104 
     105#### Einstellungen für das Logging (Protokollierung) 
     106 
     107Zwei Einstellungen zum Logging (siehe Kapitel 16) befinden sich in `settings.yml`: 
     108 
     109  * `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`. 
     110  * Die Einstellung `web_debug` aktiviert die Web-Debug-Toolbar. Setzen Sie sie nur in der Entwicklungs- und der Testumgebung auf `on`. 
     111 
     112#### Pfade zu eingebundenen Dateien (Assets) 
     113 
     114Die 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: 
     115 
     116  * Die JavaScript-Dateien des Editors für formatierten Text liegen in `rich_text_js_dir` (Standard: `js/tiny_mce`) 
     117  * Die Bibliotheken von Prototype werden in `prototype_web_dir` gespeichert (Standard: `/sf/prototype`) 
     118  * Die Dateien, die der Administrations-Generator verwendet, liegen in `admin_web_dir` 
     119  * Die Dateien, die die Web-Debug-Toolbar verwendet, liegen in `web_debug_web_dir` 
     120  * Die Dateien, die der Javascript-Kalender verwendet, liegen in `calendar_web_dir` 
     121 
     122#### Standardhelfer 
     123 
     124Die 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. 
     125 
     126#### Aktivierte Module 
     127 
     128Aktivierge 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. 
     129 
     130#### Zeichensatz 
     131 
     132Der 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`. 
     133 
     134#### Verschiedene Konfigurationseinstellungen 
     135 
     136Die 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. 
     137 
     138Listing 19-1 - Verschiedene Konfigurationseinstellungen, in `meineapp/config/settings.yml` 
     139 
     140    # Kommentare aus den Kernklassen des Frameworks entfernen, wie in core_compile.yml angegeben 
     141    strip_comments:         on 
     142    # Timeout der Sitzung, in Sekunden 
     143    timeout:                1800 
     144    # Maximale Anzahl von forward-Aufrufen in einer Action, bevor eine Exception geschmissen wird 
     145    max_forwards:           5 
     146    # Globale Konstanten 
     147    path_info_array:        SERVER 
     148    path_info_key:          PATH_INFO 
     149    url_format:             PATH 
     150 
     151>**SIDEBAR** 
     152>Eigene Einstellungen für Ihre Anwendung hinzufügen 
     153> 
     154>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 `meineapp/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. 
     155> 
     156> 
     157>     all: 
     158>       kreditkarten: 
     159>         simulation:       off    # app_kreditkarten_simulation 
     160>         visa:             on     # app_kreditkarten_visa 
     161>         americanexpress:  on     # app_kreditkarten_americanexpress 
     162> 
     163> 
     164>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. 
     165 
     166Erweiterung des Autoloadings 
     167---------------------------- 
     168 
     169Das 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. 
     170 
     171Die 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. 
     172 
     173Das Autoloading funktioniert bei allen `.php`-Dateien, die Klassen- oder Interface-Definitionen enthalten. 
     174 
     175Standardmäßig werden alle Klassen in folgenden Verzeichnissen Ihres Projekts berücksichtigt: 
     176 
     177  * `meinprojekt/lib/` 
     178  * `meinprojekt/lib/model` 
     179  * `meinprojekt/apps/meineapp/lib/` 
     180  * `meinprojekt/apps/meineapp/modules/meinmodul/lib` 
     181 
     182Im 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. 
     183 
     184Die 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. 
     185 
     186Listing 19-2 - Voreingestellte Konfiguration für das Autoloading, in `$sf_symfony_data_dir/config/autoload.yml` 
     187 
     188    autoload: 
     189 
     190      # symfony core 
     191      symfony: 
     192        name:           symfony 
     193        path:           %SF_SYMFONY_LIB_DIR% 
     194        recursive:      on 
     195        exclude:        [vendor] 
     196 
     197      propel: 
     198        name:           propel 
     199        path:           %SF_SYMFONY_LIB_DIR%/vendor/propel 
     200        recursive:      on 
     201 
     202      creole: 
     203        name:           creole 
     204        path:           %SF_SYMFONY_LIB_DIR%/vendor/creole 
     205        recursive:      on 
     206 
     207      propel_addon: 
     208        name:           propel addon 
     209        files: 
     210          Propel:       %SF_SYMFONY_LIB_DIR%/addon/propel/sfPropelAutoload.php 
     211 
     212      # plugins 
     213      plugins_lib: 
     214        name:           plugins lib 
     215        path:           %SF_PLUGINS_DIR%/*/lib 
     216        recursive:      on 
     217 
     218      plugins_module_lib: 
     219        name:           plugins module lib 
     220        path:           %SF_PLUGINS_DIR%/*/modules/*/lib 
     221        prefix:         2 
     222        recursive:      on 
     223 
     224      # project 
     225      project: 
     226        name:           project 
     227        path:           %SF_LIB_DIR% 
     228        recursive:      on 
     229        exclude:        [model, symfony] 
     230 
     231      project_model: 
     232        name:           project model 
     233        path:           %SF_MODEL_LIB_DIR% 
     234        recursive:      on 
     235 
     236      # application 
     237      application: 
     238        name:           application 
     239        path:           %SF_APP_LIB_DIR% 
     240        recursive:      on 
     241 
     242      modules: 
     243        name:           module 
     244        path:           %SF_APP_DIR%/modules/*/lib 
     245        prefix:         1 
     246        recursive:      on 
     247 
     248Eine 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. 
     249 
     250Durch 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: 
     251 
     252    [php] 
     253    // Projektkonfiguration einbinden 
     254    include(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php'); 
     255 
     256    // Symfony-Kern laden 
     257    require_once($sf_symfony_lib_dir.'/util/sfCore.class.php'); 
     258    sfCore::bootstrap($sf_symfony_lib_dir, $sf_symfony_data_dir); 
     259 
     260    // Hier können Sie ihre eigenen Autoload-Callbacks einfügen 
     261    spl_autoload_register(array('myToolkit', 'autoload')); 
     262 
     263    if (sfConfig::get('sf_debug')) 
     264    { 
     265      spl_autoload_register(array('sfAutoload', 'autoloadAgain')); 
     266    } 
     267 
     268Wenn 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). 
     269 
     270Angepasste Verzeichnisstruktur 
     271------------------------------ 
     272 
     273Jedes 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. 
     274 
     275>**ACHTUNG** 
     276>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. 
     277 
     278### Die grundlegende Verzeichnisstruktur 
     279 
     280Die 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. 
     281 
     282Listing 19-3 - Variablen der vorkonfigurierten Verzeichnisstruktur, from `$sf_symfony_data_dir/config/constants.php` 
     283 
     284    sf_root_dir           # meinprojekt/ 
     285                          #   apps/ 
     286    sf_app_dir            #     meineapp/ 
     287    sf_app_config_dir     #       config/ 
     288    sf_app_i18n_dir       #       i18n/ 
     289    sf_app_lib_dir        #       lib/ 
     290    sf_app_module_dir     #       modules/ 
     291    sf_app_template_dir   #       templates/ 
     292    sf_bin_dir            #   batch/ 
     293                          #   cache/ 
     294    sf_base_cache_dir     #     meineapp/ 
     295    sf_cache_dir          #       prod/ 
     296    sf_template_cache_dir #         templates/ 
     297    sf_i18n_cache_dir     #         i18n/ 
     298    sf_config_cache_dir   #         config/ 
     299    sf_test_cache_dir     #         test/ 
     300    sf_module_cache_dir   #         modules/ 
     301    sf_config_dir         #   config/ 
     302    sf_data_dir           #   data/ 
     303    sf_doc_dir            #   doc/ 
     304    sf_lib_dir            #   lib/ 
     305    sf_model_lib_dir      #     model/ 
     306    sf_log_dir            #   log/ 
     307    sf_test_dir           #   test/ 
     308    sf_plugins_dir        #   plugins/ 
     309    sf_web_dir            #   web/ 
     310    sf_upload_dir         #     uploads/ 
    65311}}}