Development

Documentation/de_DE/book/1.0/05-Configuring-Symfony

You must first sign up to be able to contribute.

Version 31 (modified by Dejan.Spasic, 10 years ago)
--

ARBEITSENTWURF ROHÜBERSETZUNG / TRANSLATION WORKING DRAFT
Übersetzungsfortschritt: ca. 80%
Übersetzung: DS
Korrekturfortschritt: 0%

Kapitel 5 - Symfony konfigurieren

Um die Verwendung einfach und leicht zu gestalten, definiert Symfony Konventionen, die den allgemeinen Anforderungen einer Standardanwendung ohne die Notwendigkeit einer Modifikation gerecht wird. Durch den Gebrauch einer Ansammlung einfacher und mächtiger Konfigurationsdateien, ist es über diese Weise möglich, fast jede Interaktion zwischen Ihrer Anwendung und dem Framework anzupassen. Über diese Dateien haben Sie auch selbst die Möglichkeit Ihre eigene Parameter für Ihre Anwendung hinzu zu fügen.

Dieses Kapitel beschreibt, wie das Konfigurationssystem arbeitet:

  • Die Konfigurationen werden in Dateien abgelegt die in YAML geschrieben sind. Es kann auch ein anderes Format gewählt werden.
  • Die Konfigurationsdateien befinden sich in den jeweiligen Projekt-, Anwendung- und Modulebenen einer Projektstruktur
  • Sie können eine Gruppe mit verschiedenen Konfigurationseinstellungen definieren, eine solche Gruppe von Einstellungen nennt sich Umgebung.
  • Die Werte, die in den Konfigurationsdateien definert sind, sind im PHP Code Ihrer Anwendung verfügbar.
  • Zusätzlich ermöglicht Symfony PHP Code in YAML Dateien und andere Tricks, um das Konfigurationssystem noch flexibler zu gestalten.

Das Konfigurationssystem

Unabhängig vom Einsatz besitzen die meisten Web-Anwendungen einige gemeinsame Eingenschaften. Zum Beispiel können bestimmte Bereiche für bestimmte Benutzer beschränkt werden, oder die Seiten können durch einen Layout verziert werden, oder das ein Formular mit der Benutzereingabe nach einer fehlgeschlagene Validierung gefüllt wird. Ein Framework definiert die Struktur für diese Eigenschaften und ein Entwickler kann diese ändern, indem er die Einstellung der Konfiguration ändert. Diese Strategie erspart dem Entwickler eine Menge Zeit, da viele Änderungen nicht eine einzige Zeile Code erfordern, selbst wenn eine Menge Code vorhanden ist. Es ist auch viel leistungsfähiger, weil die Sicherstellung solcher Informationen in einer einzelnen und leicht identifizierbaren Position beibehalten werden kann.

Jedoch hat dieser Ansazt ein Paar Vor- und Nachteile:

  • Die Entwickler müssen nicht mehr unendlich lange und komplexe XML-Dateien schreiben.
  • Das abarbeiten einer Anfrage wird in der PHP-Architektur verlängert.

In betracht dieser Punkte, setzt Symfony Konfigurationsdateien nur dann ein, wenn sie für den Einsatz am besten geeignet sind. Tatsächlich ist das Bestreben des Konfigurationsystems von Symfony:

  • Leistungsfähig: Fast jeder Aspekt, der mit Konfigurationsdateien gehandhabt werden kann, wird mit Konfigurationsdateien gehandhabt.
  • Einfach: Viele Aspekte der Konfiguration werden nicht in einer normalen Anwendung gezeigt, da sie selten geändert werden müssen.
  • Leicht: Konfigurationsdateien sind für den Entwickler leicht zu lesen, zu ändern und zu erstellen.
  • Anpassbar: Die Standardeinstellung ist YAML als Konfigurationssprache vorgegeben, aber es kann auch ein INI, XML oder ein von dem Entwickler bevorzuges Format sein.
  • Schnell: Die Konfigurationsdateien werden nie durch die Anwendung sondern durch das Konfigurationssystem verarbeitet, welches in ein schnell bearbeitbaren Code für den PHP Server kompiliert.

Die YAML Syntax und die Symfony Konventionen

Für die Konfigurationen verwendet Symfony standardmäßig, anstelle von den traditionelleren INI oder XML Formaten, das YAML-Format. Der Aufbau YAML wird durch Einrückung realisiert und ist schnell zu erstellen. Seine Vorteile und grundlegenden Richtlinien wurden bereits in Kapitel 1 beschrieben. Denoch müssen Sie einige Regeln beachten, wenn Sie eine YAML-Datei schreiben. Dieser Abschnitt stellt mehrere der vorstehenden Regeln vor. Für eine komplette Abhandlung dieses Themas, besuchen Sie die YAML Homepage (http://www.yaml.org/).

Zuallererst benutzen Sie niemals TAB in YAML-Dateien. Verwenden Sie stattdessen Leerzeichen. YAML-Parser können Dateien mit TAB`s nicht vestehen, also rücken Sie Ihre Zeilen mit Leerzeichen (doppelte Leerzeichen geben in Symfony eine Einrückung an) wie in Codeabschnitt 5-1 dargestellt.

Codeabschnitt 5-1 - YAML-Dateien verbieten TAB`s

# Verwenden Sie niemals TAB`s
all:
-> mail:
-> -> webmaster:  webmaster@example.com

# Verwenden Sie stattdessen Leerzeichen
all:
  mail:
    webmaster: webmaster@example.com

Wenn Ihre Parameter Zeichenketten sind, die mit Leerzeichen enden oder beginnen, können Sie den Wert mit einfachen Anführungszeichen umgeben. Das selbe gilt auch wenn Ihr Parameter Sonderzeichen enthält, auch hier können Sie, wie in Codeabschnitt 5-2 dargestellt, den Wert mit einfachen Anführungszeichen umgeben.

Codeabschnitt 5-2 - Nichtstandardisierte Zeichenketten sollten mit einfache Anführungszeichen umgeben werden.

error1: Diese Feld ist obligatorisch
error2: '  Diese Feld ist obligatorisch  '
error3: 'Don''t leave this field blank'   # Einfache Anführungszeichen müssen umgeben werden

Sie können lange Zeichenketten in mehrfachen Zeilen und auch mehrzeilige Zeichenketten, mit speziellen Zeichen (> und |) sowie eine zusätzliche Einrückung definieren. Die Codeabschnitt 5-3 zeigt diese Versammlung.

Codeabschnitt 5-3 Lange und mehrzeilige Zeichenketten definieren

# Die gefaltete Methode, wird durch > eingeführt
# Jeder Zeilenumbruch wird zu ein Leerzeichen
# Dies Gestaltet YAML lesbarer
accomplishment: >
  Mark set a major league
  home run record in 1998.

# Literale Methode, wird durch > eingeführt
# Alle Zeilenumbrüche zählen
# Die Einrückung erscheint nicht in der resultierenden Zeichenkette
stats: |
  65 Home Runs
  0.278 Batting Average

Um einen Wert als ein Array zu definieren, umgeben Sie die Elemente in eckige Klammern, oder verwenden Sie die erweiterte Syntax den Bindestrich, wie im Codeabschnitt 5-4 abgebildet.

Codeabschnitt 5-4 - YAML Array Syntax

# Kurzform Syntax für Arrays
players: [ Mark McGwire, Sammy Sosa, Ken Griffey ]

# Erweiterter Syntax für Arrays
players:
  - Mark McGwire
  - Sammy Sosa
  - Ken Griffey

Um einen Wert als assoziatives Array oder ein Mix zu definieren, umgeben Sie die Elemente in geschweiften Klammern und setzen Sie immer einen Leerzeichen zwischen dem Schlüssel und dem Wert im Schlüssel: Wert Paare. Sie können auch die erweiterte Syntax verwenden, indem Sie Einrückung und einen Zeilenumbruch für jeden neuen Schlüssel hinzufügen, wie der Codeabschnitt 5-5 zeigt.

Codeabschnitt 5-5 - YAML assoziatives Array Syntax

# Falsche Syntax, es fehlen nach dem Doppelpunkt das Leerzeichen
mail: {webmaster:webmaster@example.com,contact:contact@example.com}

# Richtige kurzform Syntax für assoziatives Arrays
mail: { webmaster: webmaster@example.com, contact: contact@example.com }

# Erweiterte Syntax für assoziatives Arrays
mail:
  webmaster: webmaster@example.com
  contact:   contact@example.com

Für einen Booleschen Wert, verwenden Sie entweder on, 1 oder true für ein positiven und off, 0 oder false für ein negativen Wert. Der Codeabschnitt 5-6 zeigt die möglichen Booleschen Werte.

Codeabschnitt 5-6 - YAML Boolean Values Syntax

true_values:   [ on, 1, true ]
false_values:  [ off, 0, false ]

Zögern Sie nicht, Kommentare (beginnend mit der Raute #) und zusätzliche Freiräume bei Werten einzusetzen, um Ihre YAML lesbareres zu ordnen, wie der Codeabschnitt 5-7 zeigt.

Codeabschnitt 5-7 - YAML Kommentar Syntax und die Ausrichtung der Werte

# Das ist eine Kommetarzeile
mail:
  webmaster: webmaster@example.com
  contact:   contact@example.com
  admin:     admin@example.com   # zusätzliche Freiräume erlauben eine nette Ausrichtung von Werten

In einigen symfony Konfigurationsdateien sehen Sie manchmal Zeilen, die mit einer Raute beginnen (und, als solcher, durch die grammatischen YAML Definitionen, ignoriert werden), obwohl sie wie übliche Konfigurationszeilen aussehen. Dies ist eine symfony Konvention: die Standardeinstellungen, werden von anderen YAML-Dateien, die im symfony Kern abgelegt sind, geerbt und als auskommentierte Zeilen in Ihrer Anwendung zu Ihrer Inofrmation wiederholt. Wenn Sie den Wert eines solchen Parameters ändern möchten, müssen Sie zuerst die Zeile auskommentieren. Wie der Codeabschnitt 5-8 zeigt.

Codeabschnitt 5-8 - Standardeinstellungen sind Kommentiert

# Der Cache ist standardmäßig ausgeschaltet
settings:
# cache: off

# Um die Einstellung zu ändern, müssen Sie zuerst die Zeile auskommentieren
settings:
  cache: on

Manchmal gruppiert Symfony die Parameterdefinitionen in Kategorien. Alle Einstellungen einer gegebenen Kategorie sehen unter der Überschrift der Kategorie eingedrückt aus. Strukturierende lange Listen der Schlüssel: Wert Paare, wird Lesbarkeit der Konfigurationen indem Sie die langen Listen in Kategorien gruppieren, verbessert. Die Überschriften der Kategorien beginnen mit einem Punkt (.). Der Codeabschnitt 5-9 zeigt ein Beispiel mit Kategoerien.

Codeabschnitt 5-9 - Die Kategorien ähneln einem Schnüssel, aber Sie beginnen mit einem Punkt

all:
  .general:
    tax:        19.6

  mail:
    webmaster:  webmaster@example.com

In diesem Beispiel ist mail ein Schlüssel und general nur eine Kategorie. Alles funktioniert, als ob die Kategorie nicht besteht. Wie der Codeabschnitt 5-10 zeigt ist der tax Parameter eigentlich ein direktes Element des all Schlüssels.

Codeabschnitt 5-10 - Die Kategorien stehen nur für die Lesbarkeit dort und werden in Wahrheit ignoriert

all:
  tax:          19.6

  mail:
    webmaster:  webmaster@example.com

SIDEBAR Und wenn Ihnen YAML nicht zusagt

YAML ist lediglich eine Schnittstelle um die Einstellungen zu definieren, dass von PHP-Code verwendet wird. Somit endet die Definition einer YAML-Datei mit der Umwandlung in PHP. Nachdem Sie die Anwendung durchgegangen sind, überprüfen Sie die gecachten Konfigurationen (zum Beispiel in cache/myapp/dev/config/). Dort finden Sie die PHP-Dateien die Ihrer YAML Konfigurationen entsprechen. Sie werden später in diesen Kapitel mehr über die gecachten Konfigurationen erfahren.

Die guten Nachrichten sind, daß, wenn Sie YAML-Datein nicht einsetzen möchten, Sie in PHP oder über ein anderes Format (XML, INI und so weiter) das tun können was die Konfigurationsdatein eigenhändig tun. Während dieses Buches erfarhen Sie alternative Möglichkeiten, Konfigurationen ohne YAML zu definieren, und Sie erlernen sogar, die Hanlder für symfony Konfigurationen zu ersetzen (siehe Kapitel 19). Wenn Sie sie geschickt benutzen, ermöglichen Ihnen diese Tricks, Konfigurationsdateien zu überbrücken oder Ihr eigenes Konfigurationsformat zu definieren.

Hilfe, eine YAML-Datei zerstörte meine APP!

Die YAML-Dateien werden in PHP Hashes und Array übersetzt, und dann werden die Werte, um das Verhalten der Ansicht, des Steuerpults oder des Modells zu ändern, in den verschiedenen Teilen der Anwendung verwendet. Viele Male, wenn ein Problem in einer YAML-Datei gitb, wird es nicht, bis es die Notwendigkeiten den Wert zu verwenden auftritt, entdeckt. Außerdem hängt der Fehler oder die Ausnahme, die dann geworfen wird, normalerweise nicht offenbar mit der YAML Konfigurationsdatei zusammen.

Wenn Ihre Anwendung, bei der Abarbeitung einer Konfigurationsänderung, plötzlich stoppt, sollten Sie prüfen, ob sich nicht irgendwelche von den allgemeinen Fehlern des unaufmerksamen YAML Kodierers eingeschlichen haben:

  • Es fehlt ein Leerzeichen zwischen den Schlüssel und dem Wer

    key1:value1      # Nach dem : fehlt ein Leerzeichen
    
  • Die Schlüsseln in einer Reihenfolge werden nicht die gleiche Weise eingedrückt:

    all:
      key1:  value1
       key2: value2  # Einrückung ist nicht dieselbe wie die anderen Elementen in der Reihenfolge
      key3:  value3
    
  • Es gibt eine reserviertes YAML-Zeichen in einem Schlüssel oder in einem Wert, ohne Zeichenkettebegrenzungen:

    message: tell him: go way    # :, [, ], { and } sind reserviert in YAML
    message: 'tell him: go way'  # Korrekte Syntax
    
  • Sie ändern eine Kommentarzeile

    # key: value     # Wird wegen dem # nie in Betracht gezogen
    
  • Sie weisen Werte mit dem gleichen Schlüsselnamen zweimal auf die gleiche Ebende zu:

    key1: value1
    key2: value2
    key1: value3     # key1 wird zweimal definiert, der Wert wird dem letztem Schlüssel zugewiesen
    
  • Sie denken, daß der Wert einer Einstellung ein spezieller Typ ist, während es immer eine Zeichenkette ist, bis Sie den Wert umwandeln:

    income: 12,345   # Bis Sie es umwandeln, ist der Wert noch eine Zeichenkette
    

Übersicht der Konfigurationsdateien

Die Konfigurationen werden in Dateien, die in Themen unterteilt sind, abgelegt. Die Dateien enthalten Parameterdefinitionen oder Einstellungen. Einige dieser Parameter können auf einigen Ebenen (Projekt, Anwendung und Modul) überschrieben werden; einige sind zu einer bestimmten Ebene spezifisch. Die folgenden Kapitel beschäftigen sich mit Konfigurationsdateien die sich auf das Hauptthema beziehen. Währenddessen sich das Kapitel 19 mit der fortgeschrittenen Konfiguration auseinandersetzt.

Die Projektkonfiguration

Standardmäßig erstellt symfony eine Reihe von Projektkonfigurationsdateien. Diese Dateien befinden sich im Verzeichnis meinprojekt/config/.

  • config.php: Dieses Datei, ist die allererste Datei, die bei jeder Anfrage bzw. jeden Befehl ausgefürht wird. Es beinhaltet den Pfad zum Framework, der auch, um eine andere Installation zu verwenden, geändert werden kann. Wenn Sie einige define definitionen am Ende dieser Datei hinzufügen, sind die Konstanten für jede Anwendung des Projektes zugänglich. Im Kapitel 19 erfahren Sie mehr über den Gebrauch diese Datei.
  • databases.yml: In dieser Datei werden die Zugangsdaten und die Verbindungseinstellungen der Datenbank definiert (Host, Login, Passwort, Datenbankname, u.s.w.). In Kapitel 8 erfahren Sie mehr über das Thema. Es kann auch über die Anwendungsebene überschrieben werden.
  • properties.ini: Diese Datei enthält einige Paramter die von der Befehlszeilenwerkzeug verwendet wird, das einen Projektnamen sowie die Verbindungsdaten eines entfernten Server beinhaltet. Lesen Sie Kapitel 16 um eine Überblick der Eigenschaften dieser Datei zu erhalten.
  • rsync_exclude.txt: Diese Datei legt fest, welche Verzeichnisse von der Synchrounisierung zwischen den Servern ausgeschlossen werden. Dazu mehr in Kapitel 16.
  • schema.yml and propel.ini: Diese Konfigurationsdateien, mit Verbindungseinstellungen, werden von Propel verwendet (Die ORM Schicht von symfony). Sie werden benutzt, um die Propel Bibliotheken mit den Klassen von symfony und den Daten Ihres Projekts zu arbeiten. schema.yml wird das Beziehungs Datenmodel des Projektes dargestellt. propel.ini wird automatisch erzeugt, so dass Sie vermutlich nichts ändern müssen. Wenn Sie Propel nicht verwenden, sind diese Dateien nicht erfoderlich. In Kapitel 8 handelt den Gebrauch der Datei genauer ab.

Diese Dateien werden meistens durch externe Komponenten oder durch die Befehlzeile benutzt. Oder sie müssen sogar, bevor der YAML Parser vom Framework geladen werden kann, verarbeitet werden. Das ist der Grund, warum einige von ihnen nicht das YAML Format verwenden.

Die Konfiguration der Anwendung

Der Hauptteil der Konfiguration ist die der Anwendung. Es werden, für den Front-Controller (im web Verzeichnis) die Hauptkonstanten, in den YAML Dateien, die in der Anwendung im config/ Verzeichnis abgelegt sind, in den i18n/ Verzeichnissen für die Internationalisierung Dateien und in den Framework für unsichtbare --obgleich nützlich-- zusätzliche Konfigurationen der Anwendung definiert.

Die Konfiguration vom Front Controller

Die allererste Konfiguration der Anwendung finden Sie im Front Controller. Dort befindet sich das allererste Skript, der durch eine Anfrage ausgeführt wird. Werfen Sie einen Blick auf web/index.php im Codeabschnitt 5-11.

Codeabschnitt 5-11 - Die Voreinstellung eines Front Controller

[php]
<?php

define('SF_ROOT_DIR',    dirname(__FILE__).'/..');
define('SF_APP',         'myapp');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG',       true);

require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

sfContext::getInstance()->getController()->dispatch();

Nachdem man den Namen der Anwendung (myapp) und der Umgebung (prod) definiert hat, wird vor dem Abfertigen die allgemeine Konfigurationsdatei aufgerufen. Einige nützliche Konstanten werden hier definiert:

  • SF_ROOT_DIR: Das Wurzelverzeichnis des Projekts (normalerweise, sollte man die Voreinsetllung beibehalten, es sei denn Sie ändern die Struktur der Dateien).
  • SF_APP: Der Name der Anwendung im Projekt. Notwendig um die Pfade der Dateien zu erstellen.
  • SF_ENVIRONMENT: Der Name der Umgebung (prod, dev, oder andere projektspezifische Umgebungen das Sie definiert haben). Stellt fest, welche Konfigurationseinstellungen verwendet werden sollen. Umgebungen werden später in diesem Kapitel behandelt.
  • SF_DEBUG: Aktivierung des Debug-Modes (Siehe Kapitel 16 für Details).

SIDEBAR Das Wurzelverzeichnis kann überall sein

Nur die Dateien und die Skripte, die unter dem Wurzelverzeichnis Web abgelegt sind (das web/ Verzeichnis in einem symfony Projekt), sind von Außen erreichbar. Die Front Controller Skripte, die Bilder, die Style Sheets und die Javascripdateien sind öffentlich. Alle anderen Dateien müssen außerhalb des Webverzeichnisses abgelegt werden -- das bedeutet, dass sie irgendwoanders abgelegt werden können.

Die nicht öffentlichen Dateien eines Projekts, werden vom Front Controller über den Pfad von der Konstante SF_ROOT_DIR erreicht. Normalerweise befindet sich das Wurzelverzeichnis eine Ebene über dem web/ Verzeichnis. Es kann jedoch eine vollständig andere Struktur definiert werden. Stellen Sie sicher, dass Ihre Hauptverzeichnisstrukturen von zwei Verzeichnissen gebildet werden, eine für die öffentlichen und eine für den privat Bereich:

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

In diesem Fall ist das Wurzelverzeichnis das symfony/ Verzeichnis. So muss der Front Controller index.php, wie folgt, einfach das SF_ROOT_DIR definieren, damit die Anwendung funktioniert:

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

Kapitel 19 finden Sie mehr Informationen darüber, wie Sie symfony so einrichten, damit es auf einer spezifischen Verzeichnisstruktur arbeitet.

Die Konfiguration der Hauptanwendung

Die Konfiguration der Hauptanwendung werden in Dateien gespeichert, die im myproject/apps/myapp/config/ Verzeichnis abgelegt werden:

  • app.yml: Diese Datei enthält anwendungsspezifische Konfigurationen; das heißt, globale Variablen, die Geschäfts- oder Anwendungslogik zu einer Anwendung definieren, wo es nicht Notwendig ist diese in einer Datenbank abzulegen. Steuersätze, Versandkosten und E-mail Adressen werden häufig in dieser Datei gespeichert. Sie ist bei der Voreinstellung leer.
  • config.php: Diese Datei lädt das Urprogramm der Anwendung, dies bedeutet, dass sie alle grundlegenden Initialisierungen erldedigt, um die Anwendung starten zu können. Hier können Sie Ihre Verzeichnisstruktur oder anwendungsspezifische Konstanten definieren (Kapitel 19 liefert mehr Details darüber). Es beginnt, indem es die config.php vom Projekt einschließt.
  • factories.yml: Symfony definiert eigene Klassen, um die Ansicht, die Anfrage, die Antwort, die Sitzung und so weiter abzuarbeiten . Wenn Sie Ihre eigenen Klassen benutzen möchten, ist diese Datei die Richtige, wo Sie sie spezifizieren können. In Kapitel 17 finden Sie mehr Informationen darüber.
  • logging.yml: Diese Datei definiert die Genauigkeit der Informationen die in den Logs notiert werden muss, um Ihnen das Managen und das aufspühren der Fehler Ihrer Anwendung zu helfen. Der Gebrauch dieser Konfigurationdatei wird in Kapitel 16 erklärt.
  • routing.yml: In dieser Datei, werden die Regeln des Routings, das die unlesbares und für Lesezeichen nicht geeigneten URLs in "smart" und deutlichere URLs umwandelt gespeichert. Bei einer neuen Anwendung exestieren bereits einige voreingestellten Richtlinien. Kapitel 9 ist ganz dem Thema Verweise und Routing gewidmet.
  • settings.yml: Die Haupteinstellungen einer symfony Anwendung werden in dieser Datei definiert. Hier können Sie, bei Internationalisierung die voreingestellte Sprache, das Timeout der Anfrge und ob das Cachen eingeschaltet wird angeben. Mit einer "Einlinien" Änderung in dieser Datei, können Sie die Anwendung schließen und können somit die Wartung oder das Upgraden eines der Bestandteile durchführen. Die allgemeinen Einstellungen und ihr Gebrauch wird in Kapitel 19 beschrieben.
  • view.yml: Die Struktur der voreingestellten Ansicht (Name des Layouts, des Titels und der Meta-Tags; Voreingestellte Sytelsheets- und Javascriptdateien die eingebunden werden; Voreingestellter Content-Type und so weiter) wird in dieser Datei eingestellt. Sie definiert auch den Standardwert von Meta und von Titel-Tag. Kapitel 7 erklärt Ihnen mehr über diese Datei. Diese Einstellungen können für jedes Modul überschrieben werden.

Die Konfiguration der Internationalisierung

Internationalisierte Anwendungen können Seiten in einigen Sprachen anzeigen. Dieses erfordert eine spezifische Konfiguration. Es gibt zwei Plätze für die Konfiguration der Internationalisierung:

  • i18n.yml der Anwendung im config/ Verzeichnisses: Diese Datei definiert allgemeine Einstellungen der Übersetzungen, wie die voreingestellte Kultur für die Übersetzung, ob die Übersetzungen von der Datei oder von einer Datenbank kommen, sowie deren Format.
  • Übersetzungdateien im i18n/ Verzeichnis der Anwendung: Diese sind im Allgemeinen die Wörterbücher und geben eine Übersetzung für jede der Phrasen die in Templates der Anwendung verwendet werden und somit die Seiten den übersetzten Text anzeigen, wenn der Benutzer zwischen den Sprachen schaltet.

Beachten Sie, dass die Aktivierung der i18n Eigenschaften in der settings.yml Datei eingestellt wird. Sie finden in Kapitel 13 mehr Informationen über diese Eigenschaften.

Die Konfiguration der Module

Bei der Voreinstellung hat ein Modul keine spezifische Konfiguration. Aber wenn erforderlich können Sie einige Einstellungen der Anwendung für ein gegebenes Modul überschrieben werden. Zum Beispiel können Sie die HTML Beschreibung aller actions eines Moduls ändern, oder eine spezifische Javascriptdatei mit einbinden. Sie können auch beschließen neue Parameter hinzuzufügen, die einem spezifischen Modul eingeschränkt gekapselt abgelegt werden.

Wie Sie wahrscheinlich Vermuten, müssen sich die Konfigurationsdateien eines Moduls im myproject/apps/myapp/modules/mymodule/config/ Verzeichnis befinden. Diese Dateien sind, wie folgt:

  • generator.yml: Für die Module, die entsprechend einer Datenbanktabelle (Scaffoldings und Administrations) erzeugt werden, definiert diese Datei, wie die Schnittstelle die Datensätze und Spalten anzeigt, und welche Interaktionen dem Benutzer angeboten werden (Filter, sortieren, Buttons und so weiter). In Kapitel 14 wird das Thema näher erklärt.
  • module.yml: Diese Datei enthält Benutzerspezifischen Parameter, die zu einem Modul zugeorndet sind (gleichwertig mit dem app.yml, aber uf den Modulebene) und Konfigurationen für actions. Im Kapitel 6 erfahren Sie mehr drüber.
  • security.yml: Diese Datei beschränkt den Zugang für actions. Hier können Sie spezifizieren, dass eine Seite nur durch zugelassene Benutzer oder durch eine Teilmenge zugelassene Benutzer mit Ausnahmegenehmigungen angezeigt werden darf. In Kapitel 6 wird das Thema näher erklärt.
  • view.yml: Diese Datei enthält Einstellungen für die Ansichten von einer oder alle actions eines Moduls. Sie überschreibt die view.yml von der Anwendung und wird in Kapitel 7 beschrieben.
  • Dateien für die Validierung der Daten: Obgleich die YAML Dateien für die Validierung der Daten eines Formulars sich im validate/ Verzeichnis anstelle vom config/ befinden, sind diese ebenfalls Konfigurationsdateien eines Moduls. Sie erlernen in Kapitel 10 wie man sie einsetzt.

Die meisten Konfigurationsdateien der Module bieten die Fähigkeit an, Parameter für alle Ansichten oder alle actions eines Moduls zu definieren oder für eine Teilmenge von ihnen.

SIDEBAR Zu viele Dateien?

Sie konnten durch die Anzahl den Konfigurationsdateien überwältigt werden, die in der Anwendung vorhanden sind. Aber behalten Sie bitte das folgende Punkte im Auge:

Die meiste Zeit besteht keine Notwendigkeit die Konfiguration zu ändern, da die voreingestellten Konventionen die allgemeinen Anforderungen genügen. Jede Konfigurationsdatei hängt mit einer bestimmten Eigenschaft zusammen und die folgenden Kapitel schildern ihren Gebrauch eins nach dem anderen. Wenn Sie sich auf eine einzelne Datei konzentrieren, können Sie sofort erkennen was es tut und wie es organisiert ist. Für die professionelle Webentwicklung wird die voreingestellte Konfiguration häufig nicht vollständig eingestellt. Die Konfigurationsdatei lassen eine einfache Änderung der symfony Einstellungen ohne Code zu. Stellen Sie sich die Menge des PHP Codes vor die notwendig ist, um die selbe Steuerung zu erzielen. Wenn die ganzen Konfigurationen in einer Datei wären, wäre die Datei nicht nur vollständig unlesbar, Sie könnten zudem keine Konfigurationen auf mehreren Ebenen neu definieren (sehen Sie das "Konfiguration kaskadieren" unterteilen später in diesem Kapitel).

Das Konfigurationssystem ist eine der großen Stärken von symfony, weil es symfony verwendbar für fast jede Art der Webentwicklung bildet, und nicht nur für die, die das Framework ursprünglich bestimmt war.

Umgebungen

Im Laufe der Anwendungsentwicklung, benötigen Sie vermutlich parallel mehrere Sätze von Konfiguration. Beispielsweise betnötigen Sie eine Verbindung für Ihre Test-Datenbank während der Entwicklung und eine für Ihre realen verfügbaren Daten für die Produktivumgebung. Die Antwort auf die Notwendigkeit der gleichzeitigen Konfigurationen ist, symfony bietet verschiedene Umgebungen.

Was ist eine Umgebung?

Eine Anwendung kann in verschiedenen Umgebungen laufen. Die unterschiedlichen Umgebungen teilen sich die gleiche PHP-Code (abgesehen vom Front Controller), können aber völlig unterschiedliche Einstellungen besitzen. Für jede Anwendung, bietet symfony drei voreingestellte Umgebungen: Produktiv (prod), Test (test) und Entwicklung (dev). Es steht Ihnen auch frei, weitere Umgebungen hinzuzufügen.

Im grundegenommen, sind Umgebungen und Konfiguration Synonyme. Zum Beispiel, logt eine Testumgebung Warnungen und Fehler, während eine Produktivumgebung nur Fehler logt. Das Caching ist meistens in der Entwicklungsumgebung deaktiviert, jedoch in der Test- oder Produktivumgebung aktiviert. Die Test- oder Entwicklungsumgebung benötigen oft Testdaten in der Datenbank anders bei einer Produktivumgebung. Dementsprechend unterscheiden sich die Datenbankverbindungen zwischen den Umgebungen. Alle Umgebungen laufen auf der selben Maschine, bis auf den Produktiv-Server, auf dem nur die Produktivumgebung läuft.

In der Entwicklungsumgebung, wo die Logging-und Debug-Einstellungen aktiviert sind, ist die Wartung wichtiger als die Leistung. Im Gegenteil ist die Produktivumgebung auf Leistung optimiert, so dass viele Funktionen deaktiviert sind. Eine gute Faustregel ist, das Sie die Funktionen solagen in der Entwicklungsumgebung arbeiten, bis Sie damit zufrieden sind und dann in der Produktivumgebung wechseln, um die Geschwindigkeit zu überprüfen.

Die Testumgebung unterscheidet sich von der dev Produktiv- und Entwicklungsumgebung. Sie interagieren ausschließlich mit dieser Umgebung über die Befehlszeile für die Funktionsprüfung und das Batch-Scripting. Folglich ähnelt die Testumgebung der Produktivumgebung, nur erfolgt der Zugriff nicht über einen Web-Browser. Es simuliert die Verwendung von Cookies und andere HTTP-spezifische Komponenten.

Um die Umgebung Ihrer Anwendung zu ändern, änder Sie einfach den Front Controller. Bis jetzt haben Sie nur die Entwicklungsumgebung gesehen, da die verwendeten URLs in diesen Bespiel der Front Controller aufgerufen wird:

http://localhost/myapp_dev.php/mymodule/index

Wenn Sie sehen wollen, wie die Anwendung in der Produktivumgebung reagiert, rufen Sie den Produktiv Front Controller auf:

http://localhost/index.php/mymodule/index

Wenn Ihr Webserver mod_rewrite unterstüzt, können Sie kundenspezifischen symfony rewriting rules verwenden, das in web/.htaccess definiert ist. Dort ist voreingestellt, der Produktiv Front Controller definieret und lässt folgende URLs zu:

http://localhost/mymodule/index

SIDEBAR Umgebungen und Server

Vermischen Sie nicht die Begriffe Umgebung und Server. Verschiedene Umgebungen, sind in symfony verschiedene Konfigurationen und entsprechen einem Front Controller (das Skript, dass die Anfragen bearbeitet). Unterschiedliche Server entsprechen unterschiedlichen Domainnamen in der URL.

http://localhost/myapp_dev.php/mymodule/index
       _________ _____________
        Server    Umgebung

Normalerweise arbeiten Entwickler an Anwendungen auf einem Entwicklungsserver, getrennt vom Internet und wo der ganze Server und die PHP Konfiguration nach Wunsch angepasst werden kann. Wenn die Zeit für das Freigeben der Anwendung zur Produktion kommt, werden die Anwendungsdateien auf den Produktivserver hochgeladen und für den Endbenutzern zugänglich gemacht.

Dies bedeutet, daß viele Umgebungen auf jedem Server vorhanden sind. Sie können zum Beispiel die Produktivumgebung sogar auf Ihrem Entwicklungsserver laufen lassen. Jedoch sollte generell, nur die Produktivumgebung auf dem Produktivserver zugänglich sein, um allgemeine Gefahren der Serverkonfiguration und -sicherheit zu vermeiden.

Um eine neue Umgebung hinzuzufügen, ist es nicht notwendig ein neues Verzeichnis zu erstellen oder die symfony CLI zu verwenden. Erstellen Sie einfach einen neuen Front Controller und ändern Sie die Definition der Umgebungsnamen in der Datei. Diese Umgebung übernimmt die ganze Standardkonfiguration plus die allgemeinen Einstellungen, die für alle Umgebung gelten. Das folgende Kapitel zeigt Ihnen, wie das ereichen können.

Die Konfiguration Kaskade

Die gleiche Einstellung kann mehrmals in unterschiedlichen Stellen definiert werden. Zum Beispiel können Sie den MIME-Type Ihrer Seiten für die ganze Anwendung auf text/html einsetellen, außer den Seiten eines rss Moduls, dass ein text/xml als MIME-Type benötigt. Symfony gibt Ihnen die Fähigkeit, die erste Einstellung in myapp/config/view.yml und die Zweite in myapp/modules/rss/config/view.yml zu schreiben. Das Konfigurationssystem weiß, daß eine Einstellung, die auf der Modulebene definiert wird, eine Einstellung überschreiben muß, die auf dem Anwendungsebene definiert wird.

Tatsächlich gibt es einige Konfigurationsebenen in symfony:

* Granulierende Ebenen:
  * Die Voreinstellungen im Framework agbelegt
  * Die globalen Einstellungen für das gesamte Projekt (in `meinprojekt/config/`)
  * Die lokalen Einstellungen für die Anwendung eines Projekts (in `meinprojekt/apps/meineanwendung/config/`)
  * Die lokalen Einstellungen für ein Modul eingeschrängt (in `meinprojekt/apps/meineanwendung/modules/meinmodul/config/`)
* Umgebungsebenen:
  * Für eine Umgebung spezifiziert
  * Für alle Umgebungen

Von allen Eigenschaften, die individuell eingestellt werden können, sind viele davon umgebungsabhängig. Infolgedessen werden viele YAML Konfigurationsdateien durch Umgebungen, plus die restlichen Einstellugen der allegemeinen Umgebung aufgeteilt. Das Resultat ist, die typische symfony Konfiguration wie der folgende Codeabschnitt 5 aussieht:

Codeabschnitt 5-12 - Die Struktur der Symfony Konfigurationsdateien

# Einstellungen der Produktivumgebung
prod:
  ...

# Einstellungen der Enticklungsumgebung
dev:
  ...

# Einstellungen der Testumgebung
test:
  ...

# Einstellungen der individuellen Umgebung
myenv:
  ...

# Einstellungen für alle Umgebungen
all:
  ...

Zusätzlich definiert das Framework selbst Standardwerte in den Konfigurationsdateien, die nicht in dem Projektbaumstruktur sind, aber in $sf_symfony_data_dir/config/>Verzeichnis Ihrer symfony Installation. Die voreingestellten Konfigurationen werden in diese Dateien eingestellt, wie in Codeabschnitt 5-13 gezeigt. Diese Einstellungen werden durch alle Anwendungen übernommen.

Codeabschnitt 5-13 - Die Standardwerte der Konfiguration, in $sf_symfony_data_dir/config/settings.yml

 # Standardeinstellungen:
 default:
   default_module:         default
   default_action:         index
   ...

Diese Standardefinitionen werden im Projekt der Anwendung und in den Modulkonfigurationdateien kommentiert wiederholt, wie der Codeabschnitt 5-14 zeigt, damit Sie wissen, daß einige Parameter durch Standardwerte definiert werden und daß sie geändert werden können.

Listing 5-14 - Die Standardeinstellungen, werden als Information in myapp/config/settings.yml wiederholt

#all:
 #  default_module:         default
 #  default_action:         index
 ...

Dies bedeutet, daß eine Einstellung mehrmals definiert werden kann, und der tatsächliche Wert resultiert aus einer Definitionskaskade. Eine Parameterdefinition in einer genannten Umgebung hat eine höhere Priorität, als die gleiche Parameterdefinition für die allegemeine Umgebung die vorher über eine Standardkonfiguration definiert wurde. Eine Parameterdefinition auf einer, Modulebene hat eine höhere Priorität, als die gleiche Parameterdefinition auf einer Anwendungsebene, die vorher über eine Projektebene defininiert wurde. Dieses kann in der folgenden Prioritätsliste abgebildet werden:

  1. Module
  2. Anwendung
  3. Projekt
  4. Spezifische Umgebungen
  5. Allegemeine Umgebung
  6. Standard

Das Caching der Konfiguration

Die parsen von YAML und das abarbeiten der Konfigurationskaskade in der Laufzeit, stellen signifikante Overheads für jede Anfrage dar. Symfony hat einen eingebauten Zwischenspeicher für Konfigurationen, die entworfen ist, um Anfragen zu beschleunigen.

Die Konfigurationsdateien, unabhängig vom Format, werden durch speizelle Klasse, Handler genannt, die sie in PHP Code umwandeln. Im der Entwicklungsumgebung überprüfen die Hander bei jeder Anfrage die Konfiguration auf Änderungen um Wechselwirkung zu fördern. Sie analysieren die vor kurzem geänderten Dateien, damit Sie eine Änderung in einem YAML sofort erkennen können. In der Produktivumgebung tritt die Verarbeitung einmalig während der ersten Anfrage auf und dann wird der verarbeitete PHP Code im Zwischenspeicher für folgende anfragen gespeichert. Dadurch wird die Leistung garantiert, da bei jeder folgende Anfrage in der Produktivumgebung den definierten PHP Code durchführt.

Wenn zum Beispiel die app.yml Datei folgende Einstellung enthält:

all:                   # Einstellung für alle Umgebungen
  mail:
    webmaster:         webmaster@example.com

dann enthält das Datei config_app.yml.php im cache/ Verzechnis Ihres Projektes, folgendes:

[php]
<?php

sfConfig::add(array(
  'app_mail_webmaster' => 'webmaster@example.com',
));

Die Konsequents ist, dass die YAML Dateien die meiste der Zeit nicht vom Framework geparsed werden, sondern die Konfigurationen aus dem Cache verwendet werden. In der Entwicklungsumgebung jedoch, vergleicht symfony systematisch die Änderungenzeiten der YAML-Dateien und die der zwischengespeicherten Dateien und bereiten nur die wieder auf, die sich seit der vorhergehende Anfrage geändert haben.

Dieses stellt einen Hauptvorteil gegenüber vielen PHP Framework, in denen Konfigurationsdateien bei jeder Anfrage kompiliert werden, sogar in der Produktivumgebung. Anders als Java, besitzt PHP keinen Kontext zwischen den Anfragen. Für andere PHP Frameworks, die die Flexibilität über XML-Konfigurationsdateien halten, kostet das verarbeiten der Konfiguration bei jeder Anfrage Leistung. Dieses ist in symfony nicht der Fall. Dank des Cachingsystems, ist der Overhead, die durch Konfiguration verursacht werden, sehr niedrig.

Es gibt eine wichtige Konsequenz dieses Mechanismus. Wenn Sie die Konfiguration im Produktivumgebung ändern, müssen Sie das Reparsing aller Konfigurationsdateien erzwingen, damit Ihre Änderung in Betracht gezogen werden kann. Um dies zu ereichen, können Sie einfach den Inhalt im Verzeichnis /cache löschen, oder, was noch einfacher ist, durch das Ausführen des clear-cache symfony Tasks:

> symfony clear-cache

Die Konfiguration dem Code zugänglich machen

Alle Konfigurationsdateien werden schließlich in PHP umgewandelt, und viele der Einstellungen, die sie enthalten, werden automatisch durch das Framework, ohne weitere Intervention verwendet. Jedoch müssen Sie manchmal einige Einstellungen die in den Konfigurationsdateien definert werden, für Ihren Code zugänglich machen (in Actions, Templates, kundenspezifische Klassen und so weiter). Die Einstellungen, die in settings.yml, in app.yml, in module.yml, in logging.yml und in i18n.yml definiert werden, stehen Ihnen durch eine spezielle Klasse zur Verfügung, die sfConfig genannt wird.

Die Klasse sfConfig

Sie können die Einstellungen innerhalb der Anwendung durch die Klasse sfConfig zugänglich machen. Es ist ein Register für Konfigurationsparameter, mit einer einfachen Getter Klassenmethode, die von jedem Teil des Codes zugänglich ist:

[php]
// Einstellung abfragen
parameter = sfConfig::get('param_name', $default_value);

Beachten Sie, dass Sie auch Einstellugen wärend der Laufzeit neu definieren, oder überschreiben können:

[php]
// Einstellung definieren
sfConfig::set('param_name', $value);

Der Parametername ist die Hintereinanderschaltung einiger Elemente, durch Unterstrichen getrennt:

  • Ein auf dem Konfigurationsdateinamen bezogener Präfix (sf_ für settings.yml, app_ für app.yml, mod_ für module.yml, sf_i18n_ für i18n.yml, and sf_logging_ für logging.yml)
  • Die Elternteilschlüssel (falls definiert), in Kleinschreibung
  • Der Name des Schlüssels, in Kleinschreibung

Die Umgebung ist nicht enthalten, da Ihr PHP Code nur Zugang zu den Werten hat, die für die Umgebung definiert werden, in dem es ausgeführt wird.

Zum Beispiel wenn Sie die Werte zugänglich machen müssen, die in der Datei app.yml definiert werden, das in Codeabschnitt 5-15 gezeigt wird, benötigen Sie den Code, das in Codeabschnitt 5-16 gezeigt wird.

Codeabschnitt 5-15 - Beispiel app.yml Konfiguration

all:
  version:        1.5
  .general:
    tax:          19.6
  default_user:
    name:         John Doe
  mail:
    webmaster:    webmaster@example.com
    contact:      contact@example.com
dev:
  mail:
    webmaster:    dummy@example.com
    contact:      dummy@example.com

Codeabschnitt 5-16 - Zugriff der Konfigurationeinstellungen für PHP in der dev Umgebung

[php]
echo sfConfig::get('app_version');
 => '1.5'
echo sfConfig::get('app_tax');   // beachten Sie, dass Kategorieüberschriften ignoriert werden
 => '19.6'
echo sfConfig::get('app_default_user_name');
 => 'John Doe'
echo sfConfig::get('app_mail_webmaster');
 => 'dummy@example.com'
echo sfConfig::get('app_mail_contact');
 => 'dummy@example.com'

Die Konfigurationseinstellungen haben in symfony alle Vorteile der PHP Konstanten, aber ohne die Nachteile, da der Wert geändert werden kann.

In dieser Hinsicht ist die Datei settings.yml, in der Sie die Frameworkeinstellungen für eine Anwendung einstellen können, das Äquivalent zu einer Reihe von sfConfig::set() Aufrufe. Codeabschnitt 5-17 interpretiert die Aufrufe, wie Codeabschnitt 5-18 aufzeigt.

Codeabschnitt 5-17 - Auszug aus settings.yml

all:
  .settings:
    available:              on
    path_info_array:        SERVER
    path_info_key:          PATH_INFO
    url_format:             PATH

Codeabschnitt 5-18 - Wie symfony die settings.yml interpretiert

[php]
sfConfig::add(array(
  'sf_available' => true,
  'sf_path_info_array' => 'SERVER',
  'sf_path_info_key' => 'PATH_INFO',
  'sf_url_format' => 'PATH',
));

Siehe Kapitel 19 für die Bedeutungen der Konfigurationen, die in der Datei settings.yml vorgenommen werden können.

Kundenspezifische Anwendungskonfigurationen und app.yml

Die meisten Einstellungen die sich auf die Eigenschaften einer Anwendung beziehen, sollten in der Datei app.yml im Verzeichnis myproject/apps/myapp/config/ gespeichert werden. Diese Datei ist umgebungsabhängig und voreingestellt leer. Stellen Sie dort Ihre Einstellungen die Sie einfach geändert haben möchten ein und benutzen Sie die sfConfig Klasse, um diese Einstellungen für Ihren Code zugänglich zu machen. Die Codeabschnitt 5-19 zeigt ein Beispiel.

Codeabschnitt 5-19 - Beispiel app.yml um Credit Card Operators Accepted zu definieren

all:
  creditcards:
    fake:             off
    visa:             on
    americanexpress:  on

dev:
  creditcards:
    fake:             on

Um zu erfahren ob die fake Kreditkarten in der gegenwärtigen Umgebung angenommen werden, holen Sie den Wert von:

[php]
sfConfig::get('app_creditcards_fake');

TIP Jedes mal wenn Sie sich dabei erwischen eine Konstante oder eine Einstellung für Ihr Skript zu definieren, überlegen Sie ob es vieleicht nicht in der app.yml ablegen sollten. Dieses ist ein sehr bequemer Platz, um alle Einstellungen für Ihre Anwendung zu speichern.

Wenn die Komplexität an den kundenspezifischen Parametern so sehr ansteigt, um sie in der app.yml Syntax abzulegen, können Sie Ihre eigene Syntax definieren. Für diesen Fall, können Sie die Konfiguration in einer neuen Datei speichern, dass von einem neunen Konfigurationshandler interpretiert werden kann. Im Kapitel 19 erfahren Sie mehr über Konfigurationshandler.