Фронт-контролер

Фронт-контролер - це патерн програмування; він є розділом коду, через який проходять всі запити, що обслуговуються додатком.

В Symfony Skeleton цю роль переймає файл index.php у каталозі public/. Цей PHP-скрипт виконується найпершим при обробці запиту.

Головною ціллю фронт-контролера є створенна екземпляра Kernel (більше про це за секунду) для обробки запиту та повернення результуючої відповіді у браузер.

Так як маршрут кожного запиту прокладено через нього, фронт-контролер може бути використаний для виконання глобальної ініціалізації до установки ядра або його декорування за допомогою додаткових функцій. Приклади включають у себе:

• Конфігурацію автозавантажувача або додавання додаткових механізмів автозавантаження;
• Додаванння HTTP-рівня кешування, огорнувши ядро екземпляром HttpCache ;
• Підключення компонента Debug.

Ви можете обрати використовуваний фронт-контролер, додавши його в URL:

1

http://localhost/index.php/some/path/...

Як ви можете побачити, цей URL містить PHP-скрипт, який буде використано як фронт-контролер. Ви можете використати це, щоб легко перемикатися на користувацький фронт-контролер, розташований у каталозі public/.

Формально, скрипт bin/console, використовуваний при запуску Symfony у командному рядку, - це теж фронт-контролер, тільки використовуваний не для мережі, а для запитів командного рядку.

Клас Kernel

Клас Kernel - це ядро Symfony. Він відповідає за пакети, використовувані вашим додатком, і надає їм конфігурацію додатку. Він створює сервіс-контейнер до обслуговування запитів у своєму методі handle().

Ядро, використовуване у додатках Symfony, розширюється з Kernel і використовує MicroKernelTrait. Клас Kernel залишає деякі методи з KernelInterface нереалізованими, а MicroKernelTrait визначає декілька абстрактних методів, так що ви повинні реалізувати їх всі:

registerBundles()

Повинен повернути масив усіх необхідних для запуску додатку пакетів.

configureRoutes()

Додає індивідуальні маршрути або колекції маршрутів у додаток (наприклад, завантаження маршрутів, визначених у деякому файлі конфігурації).

configureContainer()

Завантажує конфігурацію додатку з файлів конфігурації або використовуючи метод loadFromExtension() і може також реєструвати нові параметри контейнера та сервіси.

Щоб заповнити ці (невеликі) пробіли, ваш додаток повинен створити підклас ядра та реалізувати ці методи. Результуючий клас за угодою називається AppKernel.

Цей клас використовує імʼя середовища, яке передається методу ядра constructor і яке доступне через getEnvironment(), щоб вирішити, які пакети створювати. Логіка для цього знаходиться в registerBundles().

Ви, авжеж, вільні створювати ваші власні альтернативні або додаткові варіанти Kernel. Все, що вам потрібно - це адаптувати (або додати новий) ваш фронт-контролер, щоб скористатися новим ядром.

1
2
3

# .env
# встановити як 1, щоб включити режим налагодження
APP_DEBUG=0

1
2
3
4
5

# Використати режим налагодження, визначений у файлі .env
$ php bin/console command_name

# Ігнорувати файл .env, і включити режим налагодження для цієї команди
$ APP_DEBUG=1 php bin/console command_name

1
2
3

# config/packages/twig.yaml
twig:
    debug: '%kernel.debug%'

1
2
3
4
5
6
7
8
9
10
11
12

<?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:twig="http://symfony.com/schema/dic/twig"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/twig
        https://symfony.com/schema/dic/twig/twig-1.0.xsd">

    <twig:config debug="%kernel.debug%"/>

</container>

1
2
3
4
5
6
7

// config/packages/twig.php
use Symfony\Config\TwigConfig;

return static function (TwigConfig $twig) {
    // ...
    $twig->debug('%kernel.debug%');
};

Середовища

Як було щойно відмічено, Kernel повинен реалізувати інший метод - configureContainer(). Цей метод відповідає за завантаження конфігурації додатку з правильного середовища.

Середовища детально описувалися у попередній статті, і ви напевно памʼятаєте, що Symfony за замовчуванням використовує три: dev, prod і test.

По факту, ці імена - не більше, ніж рядки, передані з фронт-контролера у конструктор Kernel. Це імʼя потім може бути використане у методі configureContainer(), щоб вирішити, які файли конфігурації варто завантажити.

Клас Symfony Kernel за замовчуванням реалізує цей метод, завантажуючи спочатку файли конфігурації, знайдені у config/packages/*, а потім файли, знайдені у config/packages/ENVIRONMENT_NAME/. Ви, авжеж, вільні реалізовувати цей метод по-іншому, якщо вам потрібен більш витончений спосіб завантаження конфігурації.

1
2
3
4
5
6

your-project/
├─ var/
│  ├─ cache/
│  │  ├─ dev/   # каталог кешу для середовища *dev*
│  │  └─ prod/  # каталог кешу для середовища *prod*
│  ├─ ...