Bootstrap
Bootstrap – це завантажувальний код, який ініціалізує середовище, створює контейнер впровадження залежностей (DI) і запускає додаток. Ми обговоримо:
- як налаштувати застосунок за допомогою файлів NEON
- як працювати з режимами виробництва та розробки
- як створити контейнер DI
Додатки, чи то веб-додатки, чи то скрипти командного рядка,
починаються з ініціалізації середовища в тій чи іншій формі. У
стародавні часи за це міг відповідати файл з ім'ям, наприклад,
include.inc.php
, який включався у вихідний файл. У сучасних додатках Nette
він замінений класом Bootstrap
, який як частина додатка знаходиться
у файлі app/Bootstrap.php
. Це може виглядати, наприклад, так:
index.php
У випадку веб-додатків основним файлом є index.php
, який
знаходиться у загальнодоступному
каталозі www/
. Клас Bootstrap ініціалізує середовище і створює
контейнер DI. Потім він отримує з нього сервіс Application
, який
запускає веб-додаток:
Як ви бачите, клас Nette\Bootstrap\Configurator, який ми зараз представимо детальніше, допомагає в налаштуванні середовища та створенні контейнера впровадження залежностей (DI).
Режим розробки та режим виробництва
Nette поводиться по-різному залежно від того, чи запущено його на сервері розробки, чи на робочому сервері:
- 🛠️ Режим розробки
- Відображає панель налагодження Tracy з корисною інформацією (наприклад, SQL-запити, час виконання, використання пам'яті).
- Показує детальну сторінку помилок з трасуванням викликів функцій та вмістом змінних при виникненні помилки.
- Автоматично оновлює кеш при зміні шаблонів Latte, конфігураційних файлів тощо.
- 🚀 Виробничий режим
- Не відображає ніякої налагоджувальної інформації; всі помилки реєструються.
- Показує
ErrorPresenter
або загальну сторінку „Помилка сервера“, коли виникає помилка. - Кеш ніколи не оновлюється автоматично!
- Оптимізовано для швидкості та безпеки.
Режим визначається автоматично, тому в більшості випадків немає необхідності налаштовувати або перемикати його вручну:
- Режим розробки: Активний на localhost (IP-адреса
127.0.0.1
або::1
), якщо не використовується проксі (тобто на основі його HTTP-заголовків). - Виробничий режим: Активний скрізь.
Якщо ви хочете ввімкнути режим розробки в інших випадках, наприклад,
для програмістів, які отримують доступ з певної IP-адреси, ви можете
використовувати setDebugMode()
:
Ми безумовно рекомендуємо поєднувати IP-адресу з файлом cookie. Ми
зберігатимемо секретний токен у cookie nette-debug', например, `secret1234
, і
режим розробки буде активовано для програмістів із такою комбінацією
IP і cookie.
Можна повністю вимкнути режим розробника, навіть для localhost:
Зверніть увагу, що значення true
жорстко вмикає режим
розробника, чого ніколи не повинно відбуватися на робочому сервері.
Налагоджувальний інструмент Tracy
Для полегшення налагодження ми увімкнемо чудовий інструмент Tracy. У режимі розробника він візуалізує помилки, а в режимі виробництва – записує помилки в зазначений каталог:
Тимчасові файли
Nette використовує кеш для DI-контейнера, RobotLoader, шаблонів тощо. Тому необхідно задати шлях до директорії, де зберігатиметься кеш:
У Linux або macOS встановіть права на запис для
каталогів log/
і temp/
.
RobotLoader
Зазвичай ми хочемо автоматично завантажувати класи за допомогою RobotLoader, тому ми повинні запустити його і дозволити йому
завантажити класи з каталогу, в якому знаходиться Bootstrap.php
(тобто
__DIR__
) і всі його підкаталоги:
Альтернативний спосіб – використовувати лише автозавантаження PSR-4 Composer.
Часовий пояс
Configurator дає змогу вказати часовий пояс для вашого застосунку.
Конфігурація DI-контейнера
Частиною процесу завантаження є створення DI-контейнера, тобто фабрики об'єктів, яка є серцем усього додатка. Насправді це PHP-клас, створений Nette, який зберігається в каталозі кешу. Фабрика створює ключові об'єкти застосунку, а конфігураційні файли інструктують її, як їх створювати та налаштовувати, і таким чином ми впливаємо на поведінку всього застосунку.
Файли конфігурації зазвичай записуються у форматі NEON. Ви можете прочитати що можна налаштувати тут.
У режимі розробки контейнер автоматично оновлюється щоразу, коли ви змінюєте код або конфігураційні файли. У виробничому режимі він генерується лише один раз, а зміни файлів не перевіряються для досягнення максимальної продуктивності.
Файли конфігурації завантажуються за допомогою addConfig()
:
Метод addConfig()
може бути викликаний кілька разів для додавання
декількох файлів.
Підключення cli.php
не є друкарською помилкою, конфігурацію
також можна записати в PHP-файлі, який повертає її у вигляді масиву.
Альтернативно, ми можемо використовувати секцію includes
для
завантаження конфігураційних файлів.
Якщо елементи з однаковими ключами відображаються у файлах
конфігурації, вони будуть перезаписані або об'єднані у випадку
масивів. Пізніше включений файл має вищий пріоритет, ніж попередні.
Файл, зазначений у секції includes
, має вищий пріоритет, ніж файли,
включені в нього.
Статичні параметри
Параметри, що використовуються у файлах конфігурації, можуть бути
визначені в секції parameters
і
підхоплені (або перезаписані) методом addStaticParameters()
(у нього є
аліас addParameters()
). Важливо, що різні значення параметрів
викликають генерацію додаткових DI-контейнерів, тобто додаткових
класів.
У конфігураційних файлах ми можемо записати звичайну нотацію
%projectId%
для доступу до параметра з ім'ям projectId
.
Динамічні параметри
Можна також додати динамічні параметри в контейнер. Їхні різні значення, на відміну від статичних параметрів, не призведуть до генерації нових DI-контейнерів.
Змінні середовища можуть бути легко доступні з використанням
динамічних параметрів. Ми можемо отримати доступ до них через
%env.variable%
у файлах конфігурації.
Параметри за замовчуванням
Ви можете використовувати наступні статичні параметри у файлах конфігурації:
%appDir%
– абсолютний шлях до каталогу з файломBootstrap.php
%wwwDir%
– абсолютний шлях до каталогу, в якому знаходиться файл записуindex.php
%tempDir%
– абсолютний шлях до каталогу для тимчасових файлів%vendorDir%
– абсолютний шлях до каталогу, куди Composer встановлює бібліотеки%rootDir%
– абсолютний шлях до кореневого каталогу проекту%debugMode%
вказує на те, чи перебуває програма у режимі налагодження%consoleMode%
вказує на те, що запит надійшов через командний рядок
Імпортовані сервіси
Заглибимося далі. Хоча мета DI-контейнера у створенні об'єктів, може
виникнути необхідність вставити наявний об'єкт у контейнер. Це
робиться визначенням сервісу з атрибутом imported: true
:
Створюємо новий екземпляр і вставляємо його в Bootstrap:
Різні середовища
Не соромтеся налаштовувати клас Bootstrap
відповідно до ваших
потреб. Ви можете додати параметри до методу bootWebApplication()
, щоб
розрізняти веб-проекти. Крім того, ви можете додати інші методи, такі як
bootTestEnvironment()
для ініціалізації середовища для модульних тестів,
bootConsoleApplication()
для скриптів, що викликаються з командного рядка,
і так далі.