Налаштування Symfony (і середовищ)

13/07/2015 0 пакет, середовище, фронт-контролер, налаштування, конфігурація

Додаток складається з набору пакетів, що містять усі риси (“features” англійською або “фічі” у народі) та можливості вашого додатку. Кожен пакет можна налаштовувати відповідно до своїх потреб через файли конфігурації, написані у YAML, XML чи PHP. За замовчуванням, уся головна конфігурація “мешкає” у директорії app/config/ і головний файл у ній носить назву або config.yml, або config.xml, чи ж config.php (в залежності від формату, якому ви надаєте перевагу):

YAML

# app/config/config.yml
imports:
    - { resource: parameters.yml }
    - { resource: security.yml }

framework:
    secret:          "%secret%"
    router:          { resource: "%kernel.root_dir%/config/routing.yml" }
    # ...

# Twig Configuration
twig:
    debug:            "%kernel.debug%"
    strict_variables: "%kernel.debug%"

# ...

XML

<!-- app/config/config.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:framework="http://symfony.com/schema/dic/symfony"
    xmlns:twig="http://symfony.com/schema/dic/twig"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        http://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/symfony
        http://symfony.com/schema/dic/symfony/symfony-1.0.xsd
        http://symfony.com/schema/dic/twig
        http://symfony.com/schema/dic/twig/twig-1.0.xsd">

    <imports>
        <import resource="parameters.yml" />
        <import resource="security.yml" />
    </imports>

    <framework:config secret="%secret%">
        <framework:router resource="%kernel.root_dir%/config/routing.xml" />
        <!-- ... -->
    </framework:config>

    <!-- Twig Configuration -->
    <twig:config debug="%kernel.debug%" strict-variables="%kernel.debug%" />

    <!-- ... -->
</container>

PHP

// app/config/config.php
$this->import('parameters.yml');
$this->import('security.yml');

$container->loadFromExtension('framework', array(
    'secret' => '%secret%',
    'router' => array(
        'resource' => '%kernel.root_dir%/config/routing.php',
    ),
    // ...
));

// Twig Configuration
$container->loadFromExtension('twig', array(
    'debug'            => '%kernel.debug%',
    'strict_variables' => '%kernel.debug%',
));

// ...

У підрозділі “Середовища” (нижче) ви навчитеся тому, як правильно розміщувати будь-який файл чи формат.

Кожен запис вищого рівня типу framework чи twig визначає конфігурацію специфічного пакета. Для прикладу, ключ framework визначає налаштування для Symfony пакета ядра FrameworkBundle і включає налаштування для маршрутизації, шаблонування, та ін. систем ядра.

На даний момент вам не варто турбуватися про специфічні налаштування конфігурації кожної частини сайту. Файл конфігурації по замовчуванню уже містить доволі непогані та продумані настройки. Читаючи про Symfony більше, вікдриваючи для себе все нові й нові частини та розділи, ви навчитеся особливим хитрощам налаштування кожної окремої “фічі”.

Формати конфігурації

У подальших розділах усі приклади конфігурації ми подаватимемо у трьох форматах (YAML, XML та PHP). Кожен формат має як переваги, так і недоліки. Що використовувати - вибирати вам:

       - YAML: простий, охайний та легко читається (про формат YAML можна більше дізнатися за посиланням "YAML Формат");

       - XML: в рази потужніший за YAML і підтримує автозаповнення IDE;

       - PHP: дуже потужний, але читається і сприймається важче, ніж інші стандартні формати конфігурації.

Конфігурація по замовчуванню Dump

Ви можете скинути налаштування по замовчуванню для пакета у YAML до консолі, використовуючи команду config:dump-reference. Нижче ми розглянемо приклад скидання конфігурації по замовчуванню для FrameworkBundle:

$ app/console config:dump-reference FrameworkBundle

Можна також використовувати псевдонім розширення (extension alias), тобто, ключ конфігурації:

$ app/console config:dump-reference framework

За деталями радимо заглянути до Довідника, стаття “Як Поміщати Конфігурацію Сервісу До Пакета”, де ви знайдете інформацію про додавання конфігурації до вашого власного пакета.

Середовища

Додаток може запускатися у різних середовищах. Різні середовища використовують той самий PHP код (якщо не враховувати фронт-контролер), але різні налаштування конфігурації. Для прикладу, середовище dev завантажуватиме попередження та помилки, в той час як середовище prod вантажитиме лише помилки. Певні файли перебудовуються після кожного запиту у середовищі dev (для зручності програміста), але вони кешуються у середовищі prod. Усі середовища існують паралельно на одній машині й опрацьовують один і той же додаток.

Проект Symfony стартує, як правило, з трьома середовищами (dev, test і prod), однак створити ще якесь нове надзвичайно просто. Ви маєте змогу переглядати свій додаток у різних середовищах, просто змінивши фронт-контролер браузера. Для того, аби переглянути додаток в середовищі dev, зайдіть до нього через відповідний фронт-контролер:

http://localhost/app_dev.php/random/10

Якщо ви хочете глянути, як же буде виглядати і поводити себе додаток у середовищі prod, просто підключіть фронт-контролер prod:

http://localhost/app.php/random/10

Так як середовище prod оптимізоване під швидкість, то налаштування, маршрутизація і шаблони Twig компілюються до класів “чистого” PHP та кешуються. При перегляді змін у середовищі prod вам потрібно буде видалити ці кешовані файли, давши дозвіл на внесення змін:

$ php app/console cache:clear --env=prod --no-debug

При відкритті файлу web/app.php ви помітите, що він явним чином налаштований для використання у середовищі prod:

$kernel = new AppKernel('prod', false);

Для нового середовища можна створити новий фронт-контролер, скопіювавши цей файл і замінивши prod на інше значення.

Середовище test використовується при запуску автоматичних тестів, до нього не можна отримати доступу напряму через браузер. Детальніше про це читайте у розділі про тестування.

Налаштування середовища

Клас AppKernel відповідає за, власне, розміщення вибраного вами файлу з налаштуваннями:

// app/AppKernel.php
public function registerContainerConfiguration(LoaderInterface $loader)
{
    $loader->load(
        __DIR__.'/config/config_'.$this->getEnvironment().'.yml'
    );
}

Як вам уже відомо, розширення .yml можна замінити на .xml чи .php у тому випадку, коли вам зручніше створювати налаштування конфігурації в XML або ж у PHP. Варто зауважити, що кожне середовище розміщує свій власний файл з конфігураціями. Давайте подумаємо над тим, як повинен виглядати файл з конфігураціями для середовища dev.

YAML

# app/config/config_dev.yml
imports:
    - { resource: config.yml }

framework:
    router:   { resource: "%kernel.root_dir%/config/routing_dev.yml" }
    profiler: { only_exceptions: false }

# ...

XML

<!-- app/config/config_dev.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:framework="http://symfony.com/schema/dic/symfony"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        http://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/symfony
        http://symfony.com/schema/dic/symfony/symfony-1.0.xsd">

    <imports>
        <import resource="config.xml" />
    </imports>

    <framework:config>
        <framework:router resource="%kernel.root_dir%/config/routing_dev.xml" />
        <framework:profiler only-exceptions="false" />
    </framework:config>

    <!-- ... -->
</container>

PHP

// app/config/config_dev.php
$loader->import('config.php');

$container->loadFromExtension('framework', array(
    'router' => array(
        'resource' => '%kernel.root_dir%/config/routing_dev.php',
    ),
    'profiler' => array('only-exceptions' => false),
));

// ...

Ключ imports нагадує PHP оператор include та гарантує, що головний файл з конфігураціями (config.yml) завантажується першим. Решта файлу робить по замовчуванню налаштування для найтиповіших для середовища dev функцій.

Два інших середовища prod і test слідують за тією ж схемою: кожне середовище імпортує головний файл з конфігураціями і потім змінює дані налаштувань таким чином, аби відповідати потребам конкретного середовища. Усе це ми робимо для зручності, і на майбутнє це дозволить повторно використовувати більшість налаштувань та адаптовувати лише їх шматочки при переході на інші середовища.

Поділитися