Development

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

You must first sign up to be able to contribute.

Rozdział 19 - Opanowanie plików konfiguracyjnych Symfony

Teraz, gdy znasz już symfonie bardzo dobrze, masz możliwości zagłębienia się w kod, by zrozumieć projekt jądra i odkryć nowe ukryte możliwości. Ale zanim poszerzysz klasy symfony, by dopasować je do własnych wymagań, powinieneś bliżej przyjrzeć się plikom konfiguracyjnym. Wiele fukcjonalności jest już zbudowane i zawarte w symfonii i mogą być aktywowane poprzez zmianę w pliku konfiguracyjnym. To znaczy, że możesz zmienić zachowanie jądra symfonii bez przepisywania jego klas. Ten rozdział zabierze Cię w głąb plików konfiguracyjnych i ich pełnych mocy możliwości.[[BR]]

Ustawienia Symfony

Plik myapp/config/settings.yml zawiera główne ustawienia symfony dla aplikacji myapp. Widziałeś już funkcje wielu ustawień z plików z wcześniejszych rozdziałów, ale odwiedźmy je ponownie.[[BR]] Jak wyjaśnia rozdział 5, ten plik jest zależny od środowiska, co znaczy, że każde ustawienie może przyjmować inne wartości dla każdego środowiska. Pamiętaj, że każdy parametr zdefiniowany w tym pliku jest dostępny z wewnątrz kodu PHP przez klasę sfConfig. Nazwa parametru jest nazwą ustawienia z prefixem sf_. Na przykład, jeśli chcesz dostać wartość parametru cach, musisz tylko wywołać sfConfig::get('sf_cache').[[BR]]

Domyślne Moduły i Akcje

Kiedy zasady routingu nie definiują parametrów module oraz action, wartości z pliku settings.yml są używane w zamian.[[BR]]

  • default_module: Domyślny module wywołania parametrów. Domyślnie do modułu default.
  • default_action: Domyślny action wywołania parametrów. Domyślnie do akcji index.

Symfonia dostarcza domyślne strony w razie sytuacji specjalnych. W wypadku błędu routingu, symfony wywołuje akcje z modułu default, który znajduje się w folderze $sf_symfony_data_dir/modules/default/. Plik settings.yml definiuje, która akcja jest wywoływana zależnie od błędu:[[BR]]

  • error_404_module i error_404_action: Akcja wywoływana, gdy wprowadzony przez użytkownika URL nie pasuje do żadnej trasy lub kiedy występuje sfError404Exception. Domyślną wartością jest default/error404.
  • login_module i login_action: Akcja wywoływana, gdy nieautoryzowany użytkownik próbuje uzyskać dostęp strony zdefiniowanej jako secure w pliku security.yml (zobacz [rozdział 6] (http://www.symfony-project.com/translated_book/1_0/pl_PL/06-Inside-the-Controller-Layer), aby uzyskać szczegóły). Domyślna wartość to default/login.
  • secure_model i secure_action: Akcje wywoływane, gdy użytkownik nie przeszedł wymaganej autoryzacji dla akcji. Domyślna wartość to default/secure.
  • module_disabled_module i module_disabled_action: Akcje wywoływane, gdy użytkownik wywołuje moduł zdeklarowany jako nieaktywny(disabled) w module.yml. Domyślna wartość to default/disabled.
  • unavailable_module i unavailabled_action: Akcja wywoływana, gdy użytkownik wywołuje stronę z nieaktywnej(disabled) aplikacji. Wartość domyślna to default/unavailable. By zdezaktywować aplikację, zmień parametr available na off w pliku settings.yml.
Przed umieszczeniem aplikacji do używania, powinieneś dopasować te akcje, ponieważ domyślne moduły szablonów zawierają logo symfony na stronie. Zobacz Figure 19-1 zrzut ekranu z jednej takiej strony, stronę błędu 404. *figure 19-1 - Default 404 error page* nie można otworzyć obrazka[[BR]] Możesz zastąpić domyślne strony na dwa sposoby:[[BR]]
  • Możesz stworzyć swój własny moduł domyślny w aplikacji w folderze modules/ , pozmieniać wszystkie akcje zdefiniowane w pliku settings.yml (index, error404, login, secure, disabled, i unavailable) i wszystkie powiązane biblioteki (indexSuccess.php, error404Success.php, loginSuccess.php, secureSuccess.php, disabledSuccess.php i unavailableSuccess.php).
  • Możesz zmienić domyślne ustawienia modułu w pliku settings.yml, by używać stron z Twojej aplikacji.
[[BR]] Dwie inne strony świadczą o interfejsie symfony i również muszą być ustawione przed umieszczeniem do używania. Te strony nie są w domyślnym module, ponieważ są one wywoływane, gdy symfony nie może prawidłowo wystartować. W zamian znajdziesz te domyślne strony w folderze $sf_symfony_data_dir/web/errors/ :[[BR]]
  • error500.php: Strona wywoływana, gdy występuje wewnętrzny błąd serwera w środowisku produkcyjnym. W innym środowisku (gdzie SF_DEBUG jest ustawione na true), gdy błąd występuje, symfony wyświetla pełną, wyraźną wiadomość na temat błędu wywołania (zobacz rozdział 16 by poznać szczegóły).
  • unavailable.php: Strona wywoływana, gdy użytkownik wywołuje stronę podczas czyszczenia cache (to jest, pomiędzy wywołaniem zadania symfony clear-cache a końcem wykonywania tego zadania). W systemie z bardzo dużym cache, proces czyszczenia cache może zająć kilkadziesiąt sekund. Symfony nie może wywoływać zapytań z częściowo wyczyszczonym cache, więc zapytania otrzymana przed końcem tego procesu są przerzucane na tą stronę.
By ustawić te strony, po prostu stwórz strony error500.php i unavailable.php w swojej aplikacji w folderze web/errors. Symfony użyje ich zamiast swoich własnych.[[BR]] >**NOTE** >By mieć przekierowanie zapytania do strony unavailable.php, gdy potrzeba, musisz zmienić check_lock na on w aplikacji w settings.yml. Sprawdzanie jest domyślnie dezaktywowane, ponieważ dodaje bardzo niewielki dodatek do każdego zapytania.[[BR]] Opcjonalna aktywacja elementów ------------------------------ Niektóre parametry pliku settings.yml kontrolują opcjonalne funkcjonalności framework-a ,które mogą być włączone lub wyłączone. Dezaktywacja nieużywanych funkcjonalności polepsza trochę działanie, więc upewnij się, że przejrzałeś listę ustawień w tabeli 19-1 przed umieszczeniem swojej aplikacji.[[BR]] *Table 10-1 - Optional Features Se Through settings.yml*
Parametr Opis Wartość domyślna
use_database Uaktywnia menagera bazy danych, Zmień to na off, jeśli nie chcesz używać bazy danych on
use_security Uaktywnia bezpieczeństwo funkcjonalności (akcje bezpieczeństwa i autoryzacji; zobacz rozdział 6). Domyślny filtr bezpieczeństwa(sfBasicSecurityFilter) jest aktywny tylko jeśli jest to ustawione na on on
use_flash Uaktywnia flesh-owe parametry funkcjonalności (zobacz rozdział 6). Zmień to na off jeśli nigdy nie używasz metody set_flash() w swoich akcjach. Flash-owy filtr (sfFlashFilter) jest aktywny tylko jeśli jest to ustawione na on. on
i18n Uaktywnia interface translacyjny (zobacz rodział 13). Zmień to na on dla wielojęzycznej aplikacji off off
logging_enabled Uaktywnia logowanie wydarzeń symfony. Zmień to na off jeśli chcesz zignorować ustawienia logging.yml i wyłączyć kompletnie logowanie. on
escaping_strategy Uaktywnia i ustala zasady zwracania na zewnątrz cech/funkcjonalności (zobacz rozdział 7). Zmień to na off jeśli nie używasz zbiornika $sf_databc w swoich szablonach. bc
cache Uaktywnia szablony caching (zobacz rozdział 12). Zmień to na on jeśli jeden z modułów zawiera plik cache.yml. Filtr cache (sfCacheFilter) jest aktywny tylko jeśli jest na on. off in development, on in production
web_debug Uaktywnia web debug toolbar dla łatwego debugowania (zobacz rozdział 16). Zmień to na on żeby wyświetlić toolbar na każdej stronie. web debug filter (sfWebDebugFilter) jest aktywny tylko jeśli jest na on. on in development, off in production
check_symfony_version Uaktywnia sprawdzanie wersji symfony dla każdego zapytania. Zmień to na on dla automatycznego czyszczenia cache po uaktualnieniu frameworka. Zostaw to ustawione na off jeśli zawsze czyścisz cache po uaktualnieniach. off
check_lock Uaktywnia system blokad w aplikacji, sterowany przez clear-cache i wyłączone zadania( zobacz wcześniejszą sekcję). Zmień to na on by mieć wszystkie zapytania do zablokowanych aplikacji przepisane do strony $sf_symfony_data_dir/web/errors/unavailable.php off
compressed Uaktywnia kompresję odpowiedzi PHP. Zmień to na on by skompresować wychodzący HTML przez uchwyt kompresyjny PHP . off
use_process_cache Uaktywnia optymalizację symfony bazującą na akceleratorze PHP. Kiedy taki akcelerator (na przykład, APC, XCache, albo eAccelerator) jest zainstalowany, symfony bierze zalety tej funkcjonalności by zatrzymać obiekty i konfiguracje w pamięci pomiędzy zapytaniami. Zmień ten parametr na off w development albo kiedy nie chcesz akceleratora optymalizacji PHP. Zauważ, że nawet jeśli nie masz zainstalowanego żadnego akceleratora, zostawienie tego ustawionego na on nie będzie działało szkodliwie. on
[[BR]] Konfiguracja funkcjonalności ---------------------------- Symfony używa niektórych parametrów z settings.yml by zmienić zachowanie wbudowanych funkcjonalności jak walidacja form, cache, i trzy-częściowe moduły.[[BR]] ###Ustawienia uników wyjściowych Wyjściowe escaping ustawień kontrolują sposób w jaki zmienne są dostępne w szablonach (zobacz rozdział 7). Plik settings.yml zawiera dwa ustawienia dla tych cech:[[BR]]
  • ustawienia escaping_strategy mogą mieć wartość bc, both, on albo off.
  • ustawienia escaping_method mogą być zmienione na ESC_RAW, ESC_ENTITIES, ESC_JS, albo ESC_JS_NO_ENTITIES.
###Ustawienia Routingu Dwa ustawienia routingu (zobacz [rozdział 9] (http://www.symfony-project.com/translated_book/1_0/pl_PL/09-Links-and-the-Routing-System)) znajdują się w settings.yml:
  • Parametr suffix zmienia domyślną końcówkę dla generowanych URL-ów. Domyślna wartość to kropka(.), i oznacza to brak końcówki. Zmień to na na przykład .html, by mieć wszystkie URLS wyglądające jak na statycznej stronie.
  • Parametr no_script_name uaktywnia nazwę front contlorera w generowanych URL-ach. Ustawienie no_script_name może być tylko dla pojedynczej aplikacji w projekcie, o ile nie trzymasz front controllera w różnych folderach i zmieniasz domyślne reguły przepisywania URL. Jest to zazwyczaj on dla środowiska produkcyjnego w głównej aplikacji i off dla innych.
  • ###Ustawienia walidacji form Ustawienie walidacji form kontroluje sposób wysyłania wiadomości o błędach przez Validation helpers look (zobacz rozdział 10). Te błędy są zawarte w tagach
    , i używają one ustawień validation_error_ class jako atrybuty class i ustawienia validation_error_id_prefix do zbudowania atrybutu id. Domyślne wartości to form_error i error_for_, więc atrybuty wyjścia wywołują helpera form_error() do wczytania nazwy foobar będzie class="form_error" id="error_for_foobar".[[BR]] Dwa ustawienia decydują który characters precende i przekazuje każdą wiadomość o błędzie: validation_error_prefix i validation_error_suffix. Możesz zmienić je do dopasowywania wszystkich wiadomości o błędach od razu. [[BR]] ###Ustawienia Cache Ustawienia cache są zdefiniowane w cache.yml w większej części, poza dwiema w settings.yml: cache uaktywnia mechanizm szablonów cache, a etag uaktywnia uchwyt ETag po stronie serwera (zobacz rozdzial 15).[[BR]] ###Ustawienia logowania Dwa ustawienia logowania (zobacz rozdział 16) są umieszczone w settings.yml:
    • error_reporting ustala które wydarzenia są logowane w logach PHP. Jako domyślne, jest to ustawione na 431 dla środowiska produkcyjnego (więc logowane wydarzenia to E PARSE, E COMPILE ERROR, E_ERROR, E_CORE_ERROR, i E_USER_ERROR) i 4095 dla środowiska rozwojowego (E_ALL i E_STRICT).
    • Ustawienia web debug aktywują web debug toolbar. Zmień je na on tylko dla rozwojowego i testowych środowisk.

    Ścieżki do asset-ów

    Plik settings.yml zawiera również ścierzki do asset-ów. Jeśli chcesz użyć innej wersji asset niż tej dostarczonej z symfony, możesz zmienić te ustawienia ścieżek:

    • Rich text editor JavaScript plik znajdujący się w rich_text_js_dir (domyślnie , js/tiny_mce)
    • Prototype libraries znajdujące się w prototype_web_dir (domyślnie, /sf/prototype)
    • Pliki potrzebne do generatora administracji znajdujące się w admin_web_dir
    • Pliki potrzebne do web debug toolbar znajdujące się w web_debug_web_dir
    • Pliki potrzebne do kalendarza javascript znajdujące się w calendar_web_dir
    [[BR]]

    Domyślne Helpery

    Domyślnie helpery, ładowane są dla każdego szablonu, i zdeklarowane w ustawieniach standard_helpers (zobacz rozdział 7). Domyślnie są to grupy helperów Partial, Cache, i Form. Jeśli używasz grup helperów w wszystkich szablonach aplikacji, dodając ich nazwę w ustawieniach standard_helpers oszczędź sobie trudu deklarowania tego używając use_helper() w każdym szablonie.[[BR]]

    Aktywne Moduły

    Aktywowane moduły z plug-ins albo z jądra symfony są zdeklarowane w parametrze enabled_modules. Nawet jeśli paczka modułu zawiera moduł, użytkownik nie może żądać tego modułu jeśli nie jest on zdeklarowany w enabled_modules. Domyślnie moduł, który jest dostarczony przez domyślną stronę symfony (kongratulacyjna, strona nie znaleziona, itd), jest jedynym uaktywnionym domyślnie modułem. [[BR]]

    Ustawiania znaków alfanumerycznych

    Ustawienie rodzaju odpowiedzi jest ogólnym ustawieniem aplikacji, ponieważ jest ono używane przez wiele komponentów frameworka (szablony, wyjściowe escaper, helpery, itd). Zdefiniowane w ustawieniu charset, domyślnie mające wartośc utf-8.[[BR]]

    Configuracja Wszechstronna

    Plik settings.yml zawiera o kilka więcej parametrów, uzywanych wewnętrznie do zmiany zachowań jądra symfony.[[BR]]

    Listing 19-1 wyświetla je tak jak wyglądają w pliku konfiguracyjnym.[[BR]]

    Listing 19-1- Miscellaneous Configuration Settings, in myapp/config/settings.yml >php -v

    # Remove comments in core framework classes as defined in the core_compile.yml 
    strip_comments:         on
    # Functions called when a class is requested and not already loaded
    # Expects an array of callables. Used by the framework bridges.
    autoloading_functions:  ~
    # Session timeout, in seconds
    timeout:                1800
    # Maximum number of forwards followed by the action before raising an exception
    max_forwards:           5
    # Global constants
    path_info_array:        SERVER
    path_info_key:          PATH_INFO
    url_format:             PATH
    

    [[BR]]

    SIDEBAR Dodawanie własnych ustawień aplikacji

    Plik settings.yml definiuje ustawienia symfony dla aplikacji. Jak omówiono w rozdziale 5, kiedy chcesz dodać nowy >parametr, najlepszym miejscem na to jest plik myapp/config/app.yml. Ten plik jest również zależny od środowiska, i >zdefiniowane ustawienia dostępne są przez klasę sfConfig z app_prefix.

    >php -v
    all:
      creditcards:
        fake:             off    # app_creditcards_fake
        visa:             on     # app_creditcards_visa
        americanexpress:  on     # app_creditcards_americanexpress
    

    Możesz również napisać plik app.yml w folderze konfiguracji projektu, i daje to możliwość zdefiniowania własnych >ustawień projektu. Configuracja kaskad również odnosi się do pliku, więc ustawienia zdefiniowane w pliku aplikacji >app.yml odsuwają ten który jest zdefiniowany na poziomie projektu[[BR]]

    Poszerzać autoładowane elementy

    Ładowanie automatyczne elemetnów, skrótowo wyjaśnione w rozdziale 2, zwalnia cię z umieszczania klas w swoim kodzie jeśli są one umieszczone w ustalonych folderach. Znaczy to że możesz po prostu pozwolić frameworkowi zrobić to dla ciebie, pozwala to załadować tylko niezbędne klasy w stosownym czasie, i tylko gdy tego potrzebujesz.[[BR]]

    Plik autoload.yml wyświetla listę ścieżek w których klasy autoładowane są zgromadzone. Pierwszy raz gdy ten plik konfiguracyjny jest tworzony, syfony analizuje wszystkie foldery zapisane w pliku. Za każdym razem gdy plik kończących się na .php jest znajdowany w jednej z tych ścieżek, foldery i nazwy klas znalezione w tym pliku są dodawane do wewnętrznej listy autoładowanych klas. Ta lista jest przechowywana w cache, w pliku nazwanym config/config_autoload.yml.php. Potem w czasie uruchamiania, gdy klasy są używane, syfony patrzy w listę po klasy i załącza pliki .php automatycznie.[[BR]]

    Autoładowanie działa dla wszystkich plików .php zawierających klasy i/albo interfejsy.[[BR]]

    Domyślnie, klasy składowane w następujących miejscach w twoim projekcie czerpią korzyści z autoładowania automatycznie:

    • myproject/lib/
    • myproject/lib/model
    • myproject/apps/myapp/lib/
    • myproject/apps/myapp/modules/mymodule/lib
    [[BR]]

    Nie ma pliku autoload.yml w domyślnym folderze konfiguracyjnym aplikacji. Jeśli chcesz zmienić ustawienia frameworka – na przykład, by załączać automatycznie klasy umieszczone w innym miejscu niż w twojej strukturze plików – stwórz pusty plik autoload.yml co unieważni ustawienia z $sf_symfony_data_dir/config/autoload.yml albo dodaj swoje własne.[[BR]]

    Plik autoload.yml musi wystartować z autoload: klucz i lista lokacji gdzie symfony powinno spojrzeć po klasy. Każda lokacja wymaga etykiety; to daje jej możliwość odsunąć wejścia symfony. Dla każdej lokacji, dostarcza nazwę (pokaże się to jako komentarz w config_autoload.yml.php) i ścieżkę absolutną. Potem zdefiniuj czy szukanie ma być rekursywne, co kieruje symfony by zobaczyć wszystkie podkatalogi w poszukiwaniu plików .php, i wykluczy podkatalogi które chcesz. Listing 19-2 pokazuje lokacje które są używane jako domyślne w synftax.[[BR]]

    Listing 19-2 Domyślna konfiguracja Autoloading, w $sf_symfony_data_dir/confgi/autoload.yml >php -v autoload:

      # jądro symfony
      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
    
     # projekt
     project:
        name:           project
        path:           %SF_LIB_DIR%
        recursive:      on
        exclude:        [model, symfony]
    
     project_model:
        name:           project model
        path:           %SF_MODEL_LIB_DIR%
        recursive:      on
    
     # aplikacja
     application:
        name:           application
        path:           %SF_APP_LIB_DIR%
        recursive:      on
    
    modules:
        name:           module
        path:           %SF_APP_DIR%/modules/*/lib
        prefix:         1
        recursive:      on
    

    A rule path może zawierać wildcards i używać plik parametrów ścieżek z pliku constans.php (zobacz następną sekcję). Jeśli używasz tych parametrów w pliku konfiguracyjnym, muszą one składać się z wielkich liter, zaczynać i kończyć na %.[[BR]]

    Edytowanie twojego własnego autoload.yml doda nowe lokacje do symfony’s autoloading, ale ty możesz chcieć rozwinąć ten mechanizm i dodać swoje własne autoładowalne uchwyty do uchwytów symfony. Jest to możliwe poprzez parametr autoloading_functions w pliku settings.yml. Oczekuje to tablicy callables as a wartości, jak poniżej:[[BR]]

    >php -v
    .settings:
      autoloading_functions:
        -[myToolkit, autoload]
    

    [[BR]]

    Kiedy Symfony zliczy nowe klasy, spróbuje najpierw swojego własnego systemu autładowania (I użyje lokacji zdefiniowanych w autoload.yml). Jeśli nie znajdzie przez to definicji klas, spróbuje innych funkcji autoładowania z settings.yml dopóki klasy nie zostaną znalezione. Więc możesz dodać tak dużo mechanizmów autoładowania jak tylko chcesz – na przykład, by dostarczyć pomost między innymi komponentami frameworka (zobacz rozdział 17). [[BR]]

    Własna struktura plików

    Za każdym razem kiedy framework używa ścieżek by coś znaleźć (z klas jądra do szablonów, plug-ins, konfiguracje, i takie tam), używa ścieżek zmiennych zamiast o fan aktualnych ścieżek. Zmieniając te zmienne, możesz kompletnie zmienić strukturę folderów w projekcie symfony, i zaadaptować organizację plików według wymagań każdego klienta.[[BR]]

    CAUTION Zmienianie struktury folderów w projekcie symfony jest możliwe ale nie koniecznie jest to dobry pomysł. Jednym z >zaskoczeń frameworka takiego jak symfony jest to że każdy projektant stron internetowych może spojrzeć na projekt i czuć >się jak w domu, ponieważ respektuje on konwencje. Przemyśl dobrze swoją decyzję zanim zdecydujesz użyć innej struktury >folderów.[[BR]]

    Prosta struktura plików

    Ścieżki zmienne są zdefiniowane w pliku $sf_symfony_data_dir/config/constans.php, zawierają bootstraps aplikacji. Te zmienne znajdują się w obiekcie sfConfig, dzięki czemu są one łatwe do uzyskania. Listing 19-3 pokazuje listing of the path variables i directory they reference.[[BR]]

    ''Listing 19-3 - Default File Structure Variables, from $sf_symfony_data_dir/config/constants.php''[[BR]] >php -v sf_root_dir # myproject/ # apps/ sf_app_dir # myapp/ 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 # myapp/ 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/

    [[BR]]

    Każda ścieżka do kluczowego folderu jest zdeterminowana przez parametr kończący z _dir. Zawsze używaj zamiennych ścieżeks zamiast prawdziwych (relative or absolute) ścieżek plików, po to żebyś mógł je zmienić jeśli będzie to potrzebne. Na przykład, kiedy chcesz przenieść plik do folderu uploads/ w aplikacji, powinieneś użyć sfConfig::get(‘sf_upload_dir’) jako ścieżka zamiast SF_ROOT_DIR.’/Web/uploads/’.[[BR]]

    Moduł struktury folderów jest definiowany w czasie rzeczywistym, kiedy system routingowy decyduje o nazwach modułu ($module_name). Jest to budowane automatycznie zgodnie z nazwami ścieżek zdefiniowanych w pliku constans.php, jak pokazano na Listing 19-4.[[BR]] >php -v Listing 19-4 - Default Module File Structure Variables sf_app_module_dir # modules/ module_name # mymodule/ 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/ [[BR]]

    Więc, na przykład ścieżka do folderu validate/ w bieżącym module jest budowana dynamicznie w czasie rzeczywistym: [php] <?php sfConfig::get('sf_app_module_dir').'/'.$module_name.'/'.sfConfig::get('sf_app_module_validate_dir_name') [[BR]]

    Dopasowywanie struktury plików

    Prawdopodobnie będziesz potrzebował zmodyfikować domyślną strukturę plików projektu jeśli tworzysz aplikacje dla klienta, który już ma ustaloną strukturę folderów I który nie chce zmieniać jej by dopasować do logiki symfony. By unieważnić zmienne the sf_XXX_dir i sf_XXX_dir_name z sfConfig, możesz sprawić by symfony pracowało w zupełnie innej strukturze folderów niż domyślna struktura. Najlepszym miejscem żeby to zrobić jest w aplikacji plik config.php.[[BR]]

    CAUTION Użyj aplikacji config.php I nie the Project one to override the sf_XXX_dir i sf_XXX_dir_name >zmienne z sfConfig. Plik config/config.php projektu jest ładowany bardzo wcześnie w życiu zapytania, w czasie kiedy >klasa sfConfig jeszcze nie istnieje, I kiedy plik constans.php jest jeszcze nie załadowany.[[BR]]

    Na przykład, jeśli chcesz by cała aplikacja dzieliła wspólne foldery dla szablonów layout-u, dodaj tą linie do pliku myapp/config/config.php by zastąpić ustawienia sf_app_template_dir:[[BR]]

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

    [[BR]]

    Zauważ, że plik config.php aplikacji nie jest pusty, więc jeśli potrzebujesz załączyć tam plik definicji struktury, zrób to na końcu pliku.[[BR]]

    Modyfikowanie Korzenia Projektu Web

    Wszystkie ścieżki zbudowane w constans.php bazują na folderze root projektu, który jest stale zdefiniowany w front kontrolerze (SF_ROOT_DIR). Zazwyczaj, katalog root jest jeden poziom powyżej katalogu Web/, ale możesz użyć innej struktury. Zakładając że twoja główna struktura folderów jest stworzona z dwóch katalogów, jednego publicznego i drugiego prywatnego, jak pokazano na listing 19-5. To zdarza się zazwyczaj kiedy umieszczasz projekt na serwerze dzielonym.[[BR]]

    ''Listing 19-5 - Example of Custom Directory Structure for a Shared Host'' >php -v symfony/ # Private area apps/ batch/ cache/ ... www/ # Public area images/ css/ js/ index.php [[BR]]

    W tym wypadku, katalogiem root jest folder symfony/. Więc front kontroler index.php po prostu potrzebuje zdefiniowania SF_ROOT_DIR jako następująca dla pracy aplikacji:[[BR]] [php] <?php define('SF_ROOT_DIR', dirname(FILE).'/../symfony'); [[BR]] W dodatku, odkąd przestrzenią publiczną jest www/ zamiast zwyczajnego web/, musisz zmienić dwie ścierzki plików w pliku config.php aplikacji, tak jak poniżej: [[BR]]

    [php]
    <?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'),
      ));
    

    [[BR]]

    Linkowanie do bibliotek Symfony

    [[BR]] Ścieżki do plików frameworka są zdefiniowane w projekcie w pliku config.php, jak możesz zobaczyć w listing 19-6. [[BR]]

    ''Listing 19-6 - The Paths to the Framework Files, in myproject/config/config.php'' [php] <?php // symfony directories $sf_symfony_lib_dir = '/path/to/symfony/lib'; $sf_symfony_data_dir = '/path/to/symfony/data'; [[BR]]

    Te ścieżki są initializowane kiedy wywołujesz symfony init-project w wierszu poleceń, I odwołują się do instalacji symfony używanej do budowy projektu. Są one oba używane poprzez wiersz poleceń i poprzez architekturę MVC. [[BR]]

    To znaczy że możesz zmienić je do innej instalacji symfony poprzez zmienienie ścieżek do plików frameworka.[[BR]]

    Te ścieżki powinny być absolutne, ale poprzez użycie dirname(FILE), możesz odwołać się do plików w środku struktury projektu i ochronić niezależność wyboru folderu dla instalacji projektu. Na przykład, wiele projektów wybiera by mieć folder lib/ symfonii jako symboliczny link to folderu projektu lib/symfony, i tak samo w przypadku folderu data/symfonii, jak poniżej:[[BR]] >php -v myproject/ lib/ symfony/ => /path/to/symfony/lib data/ symfony/ => /path/to/symfony/data [[BR]]

    W tym wypadku, plik config.php projektu potrzebuje tylko definiować ścieżki jak poniżej: [[BR]] [php] <?php $sf_symfony_lib_dir = dirname(FILE).'/../lib/symfony'; $sf_symfony_data_dir = dirname(FILE).'/../data/symfony'; [[BR]] Ta sama reguła obowiazuje jeśli zdecydujesz dołączyć do symfony pliki takie jak svn:externals w folderze projektu lib/vendor/ :[[BR]]

    >php -v
    myproject/
      lib/
       vendor/
         svn:externals symfony http://svn.symfony-project.com/trunk/
    

    [[BR]]

    W tym wypadku, plik config.php powinien wyglądać tak jak to: [[BR]] [php] <?php $sf_symfony_lib_dir = dirname(FILE).'/../lib/vendor/symfony/lib'; $sf_symfony_data_dir = dirname(FILE).'/../lib/vendor/symfony/data'; [[BR]]

    TIP Czasami, różne serwery uruchamiające aplikację symfony nie mają tych samych ścieżek do bibliotek symfony. Jednym sposobem by to rozwiązać jest wykluczyć plik config.php projektu z synchronizacji (dodając to do rsync_exclude.txt). Inną metodą jest by trzymać ścieżki w rozwojowej i produkcyjnej wersji config.php, ale by mieć te ścieżki sprowadzone do symbolicznych linków które zmieniają się w zależności od serwera.

    [[BR]]

    Rozumienie konfiguracji uchwytów

    [[BR]] Każdy plik konfiguracyjny ma uchwyt. Praca nad konfiguracją uchwytów polega na konfiguracji kaskad, i by zrobić zamianę pomiędzy plikami konfiguracyjnymi a zoptymalizowanym kodem PHP wywoływanym w czasie rzeczywistym.[[BR]]

    Domyślne ustawienia uchwytów

    [[BR]]

    Domyślna konfiguracja uchwytów jest umieszczona w $sf_symfony_data_dir/config/config_handlers.yml. Ten plik linkuje uchwyt do plików konfiguracyjnych zgodnie z ścieżkami plików. Listing 19-7 pokazuje zawartość tego pliku. [[BR]] ''Listing 19-7 - Extract of $sf_symfony_data_dir/config/config_handlers.yml'' >php -v config/settings.yml: class: sfDefineEnvironmentConfigHandler param: prefix: sf_

    config/app.yml:
      class:    sfDefineEnvironmentConfigHandler
      param:
        prefix: app_
    
    config/filters.yml:
      class:    sfFilterConfigHandler
    
    modules/*/config/module.yml:
      class:    sfDefineEnvironmentConfigHandler
      param:
        prefix: mod_
        module: yes
    

    [[BR]] Dla każdego pliku konfiguracyjnego (config_handlers.yml identyfikuje każdy plik poprzez ścieżke do pliku z wildcard-em), klasa uchwytu jest zdefiniowana pod kluczem class.[[BR]]

    Ustawienia plików konfiguracyjnych trzymane przez sfDefineEnvironmentConfigHandler mogą być dostępne wprost w kodzie poprzez klase sfConfig, i parametr key zawierający wartość prefixa.[[BR]]

    Możesz dodać lub zmienić uchwyty używane do tworzenia każdego pliku konfiguracyjnego – na przykład, by użyć INI albo XML zamiast plików YAML.[[BR]]

    NOTE Konfiguracja uchwytu dla pliku config_handlers.yml jest sfRootConfigHandler i oczywiście, nie może być zmieniona.

    [[BR]]

    Jeśli nigdy nie potrzebowałeś modyfikować sposobu parsowania konfiguracji, stwórz pusty plik config_handlers.yml w swoim folderze config/ aplikacji i zastąp linie klasy tą która sam napisałeś.[[BR]]

    Dodawanie swoich własnych uchwytów

    [[BR]]

    Używanie uchwytów współgrać z plikami konfiguracyjnymi daje nam dwie ważne korzyści:[[BR]]

    • Plik konfiguracyjny jest zamieniany w wywoływalny kod PHP, i ten kod jest przechowywany w cache. To znaczy że konfiguracje są parsowane tylko raz podczas tworzenia, i performance jest optymalna.
    • Plik konfiguracyjny może być zdefiniowany na różnych poziomach (projektu i aplikacji) i ostatnia wartość parametru zwróci z kaskad. Więc możesz zdefiniować parametry na poziomie projektu i zastąpić je bazując na per-application.
    [[BR]]

    Jeśli czujesz jak pisać swoje własny uchwyt konfiguracyjny, podążaj za przykładową strukturą użyta przez framework w folderze $sf_symfony_lib_dir/config/.[[BR]]

    Załóżmy, że twoja aplikacja zawiera klasę myMapAPI, która dostarcza interfejs trzyczęściowej mapy dostarczania serwisu. Ta klasa musi być zainicjalizowana z URL i nazwą użytkownika, jak jest to pokazane na Listing 19-8.[[BR]]

    ''Listing 19-8 - Example of Initialization of the myMapAPI Class'' [php] <? $mapApi = new myMapAPI(); $mapApi->setUrl($url); $mapApi->setUser($user); [[BR]]

    Możesz chcieć zebrać te dwa parametry w swoim dopasowanym pliku konfiguracyjnym nazwanym map.yml, który mieści się w aplikacji w folderze config/. Ten plik konfiguracyjny może zawierać co następuje:[[BR]] >php -v api: url: map.api.example.com user: foobar
    W celu przetworzenia tych ustawień na kod porównywalny do Listing 19-8, musisz zbudować uchwyt konfiguracyjny. Każdy uchwyt konfiguracyjny musi rozszerzać sfConfigHandler i dostarczać metodę execute(), która oczekuje tablicy ścieżek plików do plików konfiguracyjnych jako parametry, i musi zwrócić dane do zapisania w pliku cache. Uchwyty dla plików YAML powinny rozszerzać klasę sfYamalConfigHandler, która dostarcza dodatki funkcjonalności do parsowania YAML. Dla pliku map.yml, typowy uchwyt konfiguracyjny może być napisany jak pokazano na listing 19-9. [[BR]]

    ''Listing 19-9 - A Custom Configuration Handler, in myapp/lib/myMapConfigHandler.class.php'' [php] <?php class myMapConfigHandler extends sfYamlConfigHandler { public function execute($configFiles) { $this->initialize();

        // Parse the yaml
        $config = $this->parseYamls($configFiles);
        $data  = "<?php\n";
        $data. = "\$mapApi = new myMapAPI();\n";
    
        if (isset($config['api']['url'])
         {
          $data. = sprintf("\$mapApi->setUrl('%s');\n", $config['api']['url']);
         }
    
        if (isset($config['api']['user'])
        {
          $data. = sprintf("\$mapApi->setUser('%s');\n", $config['api']['user']);
        }
    
        return $data;
      }
    }
    

    [[BR]]

    Tablica $configFiles którą symfony podaje do metody execute() będzie zawierać ścieżki do plików map.yml znalezionych w folderze config/. Metoda parseYamls() będzie trzymać konfigurację kaskady.[[BR]]

    W celu to współpracy tego nowego uchwytu z plikiem map.yml, musisz stworzyć plik konfiguracyjny config_handlers.yml z następującą zawartością:[[BR]] >php -v config/map.yml: class: myMapConfigHandler [[BR]]

    NOTE Klasa musi być albo automatycznie ładowana (tak jak w tym przypadku) albo zdefiniowana w pliku którego ścieżka jest zapisana w pliku parametr pod parametrem klucz.

    [[BR]]

    Kiedy potrzebujesz kod bazowany na pliku map.yml i wygenerowany uchwyt myMapConfigHandler w swojej aplikacji, wywołaj następującą linie:[[BR]] [php] <?php include(sfConfigCache::getInstance()->checkConfig(sfConfig::get('sf_app_config_dir_name').'/map.yml')); [[BR]]

    Podczas wywoływania metody checkConfig(), symfony szuka istniejących plików map.yml w folderach konfiguracyjnych I przetwarza ja z uchwytem zdefiniowanym w pliku config_handlers.yml, jeśli map.yml.php jeszcze nie istnieje w cache albo jeśli plik map.yml jest aktualniejszy niż cache.[[BR]]

    TIP Jeśli chcesz uchwyt środowiskowy w pliku konfiguracyjnym YAML, uchwyt może rozwijać klasę sfDefineEnvironmentConfigHandler zamiast sfYamlConfigHandler. Po wywołaniu metody parseYaml() do zwrócenia konfiguracji, powinieneś wywołać metodę mergeEnvironment(). Możesz to wszystko zrobić w jednej lini wywołując $config= $this->mergeEnvironment($this->parseYamls($configFiles));.

    [[BR]]

    SIDEBAR Używanie istniejących konfiguracji uchwytów

    Jeśli tylko potrzebujesz zezwolić użytkownikom na zwracanie wartości z kodu poprzez sfConfig, możesz użyć klasy uchwytu >konfiguracyjnego sfDefineEnvironmentConfigHandler. Na przykład, by mieć url i dostępne parametry użytkownika jak >sfConfgi::get(‘map_url’) i sfConfig::get(‘map_user’), zdefiniuj swój uchwyt następująco:[[BR]]

    >php -v
    config/map.yml:
      class: sfDefineEnvironmentConfigHandler
      param:
        prefix: map_
    

    Bądź ostrożny i nie wybieraj prefixu który już używa inny uchwyt. Istniejące prefixy to sf_, app_ i mod_.

    [[BR]]

    Kontrolowanie ustawień PHP

    [[BR]]

    By mieć środowisko PHP kompatybilne z zasadami i najlepszymi praktykami sprawnego rozwoju, symfony sprawdza i zmienia kilka ustawień konfiguracji php.ini. To jest właśnie celem php.yml. Listing 19-10 pokazuje domyślny plik php.yml.[[BR]]

    ''Listing 19-10 - Default PHP Settings for Symfony, in $sf_symfony_data_dir/config/php.yml'' >php -v set: magic_quotes_runtime: off log_errors: on arg_separator.output: | &

    check:
      zend.ze1_compatibility_mode: off
    
    warn:
      magic_quotes_gpc:            off
      register_globals:            off
      session.auto_start:          off
    

    [[BR]]

    Główne celem tego pliku jest sprawdzanie czy konfiguracja PHP jest kompatybilna z twoją aplikacją. Jest to również bardzo użyteczne by sprawdzić, czy ustawienie twojego servera rozwojowego jest tak podobne do produkcyjnego serwera jak to tylko możliwe. To dla tego powinieneś sprawdzić konfigurację serwera produkcyjnego na początku swojego projektu, i zraportować te ustawienia PHP w pliku php.yml w swoim projekcie. Możesz potem rozwijać i testować z zaufaniem że nie zobaczysz żadnego błędu kompatybilności kiedy rozmieścisz swój projekt na platformie produkcyjnej.[[BR]]

    Zmienne zdefiniowane pod nagłówkiem set są modyfikowane (mimo tego jak były zdefiniowane w serwerowym pliku php.ini). Zmienne zdefiniowane pod kategorią Warn nie mogą być zmodyfikowane w locie, ale symfony może odpalić nawet jeśli nie są one prawidłowo skonfigurowane. Jest to po prostu uznane za złą praktykę mieć te ustawienia na on, i symfony będzie logowało ostrzeżenia w tym wypadku. Zmienne zdefiniowane pod kategorią check nie mogą być zmodyfikowane w locie, ale muszą mieć konkretną wartość aby uruchomić symfony. Więc, w przypadku, wystąpienia jakiegoś wyjątku sprawdź czy plik php.ini nie jest prawidłowy.[[BR]]

    Domyślny plik php.yml zmienia log_errors na on więc możesz śledzić błędy w projekcie symfony. Jest to również zalecane by register_globals było ustawione na off by zapobiec naruszeniu ochrony. Jeśli nie chcesz by symfony zabiegało o te ustawienia, lub jeśli chcesz odpalić projekt z magic_quotes_gpc i register_globals ustawione na on bez ostrzeżeń, stwórz plik php.yml w folderze config/ twojego projektu i zastąp ustawienia które chcesz zmienić. Dodatkowo jeśli twój projekt wymaga rozszerzenia, możesz ustalić to pod kategorią rozrzeżenia. Oczekuje to na tablice z nazwami rozszerzeń, jak poniżej:[[BR]] >php -v extensions: [gd, mysql, mbstring] [[BR]]

    Podsumowanie

    Pliki konfiguracyjne mogą decydująco zmienić sposób w jaki pracuje framework. Ponieważ symfony polega na ustawieniach nawet dla cech jądra i autoładowania pliku, może zaadoptować wiele więcej środowisk niż standardowy serwer dedykowany. Ta wielka konfiguralność jest jedną z mocnych stron symfony. Nawet jeśli jest to czasami odstraszające dla nowo przybyłych, którzy widzą w plikach konfiguracyjnych wiele aspektów do nauki, pozwala to aplikacją symfony być kompatybilnymi z wielką ilością platform i środowisk. Kiedy zostaniesz mistrzem konfiguracji symfony, żaden serwer nigdy nie odmówi uruchomienia twojej aplikacji!