Данный пост написан на основе публикации Фабьена Потенсье.
В свое время в Symfony 3 появились каталоги bin/, src/, var/, что по-моему мнению очень удобно и понятно. Мы все привыкли работать с такими каталогами. В свою очередь, Symfony 4 движется в этом же направлении и предлагает обновленную структуру каталогов приложения.
Все тесты теперь будут располагаться непосредственно в каталоге tests/. Ранее в каталоге tests/ всегда присутствовали каталоги с именами бандлов вашего приложения в которых находились тесты. В Symfony 4, приложения не будут (или не обязательно должны) реализовывать код в каком либо бандле. Это позволит определить собственное пространство имен тестов для автозагрузки:
При установке шаблонизатора Twig, теперь будет создаваться каталог templates/ в корне приложения, где и будут размещаться все шаблоны. Мне очень нравится эта идея, потому что каталог Resources, который содержал в себе до этого и публичные файлы (css, js и т.п.) и шаблоны, вносил некоторый дискомфорт. Возможно, что каталог будет называться tpl/, это еще пока окончательно не известно. В целом, перемещение шаблонов из каталога src/ делает приложение более структурированным. Теперь в src/ лежит только код. Класс Kernel, который ранее располагался в папке app/, так же перемещен в src/ где ему и место.
Каталог config/ заменит существовавший ранее app/config. Параметры окружения, которые ранее определялись в файле parameters.yml, теперь конфигурируются с помощью переменных окружения операционной системы. По умолчанию в каталоге config/ вы обнаружите пустой файл container.yaml (yaml — это не опечатка, в Symfony 4 конфигурационные файлы в формате YAML, теперь имеют расширение yaml, вместо yml)в котором как и прежде можете определять конфигурацию контейнера. Так же там будет файл routing.yaml. В данных файлах вы будете определять только собственные настройки. Компоненты, установленные с помощью Composer, будут хранить свои настройки в отдельных файлах для каждого окружения.
Конфигурацию как и прежде можно будет задавать в трех форматах: YAML, XML, PHP. Помимо конфигурационных файлов, в каталоге config/ появится bundles.php, который будет представлен массивом бандлов, активных в вашей системе.
Изменения в этот файл будут вноситься автоматически плагином Synfony Flex, при установке или удалении любого бандла в системе с помощью Composer.
Небольшие изменения коснулись каталога var/. Теперь в var/cache/ будет храниться только «вечный» кеш (скомпилированный контейнер и переводы, или кеш доктрины например). Таким образом все файлы в var/cache/ должны иметь свой warmup класс. Никаких временных файлов, только кеш, который не изменяется после деплоя проекта. Это позволит сделать var/cache/ каталог доступным только для чтения. При таком подходе вы сможете работать с read-only файловыми системами (например как на платформах Heroku или SensioCloud).
Так же изменилось содержимое каталога public/. Убраны файлы config.php, .htaccess, favicon.ico, apple-touch-icon.png, robots.txt. Не каждый проект нуждается в этих файлах. Если вам потребуются шаблоны для этих файлов, то Symfony 4, предоставит вам возможность опционально получить их.
Изменился и фронт-контроллер. Теперь вместо привычных app.php и app_dev.php будет присутствовать один файл index.php для всех окружений:
Настройки, специфичные для конкретной платформы и окружения, ранее принято было хранить в конфигурационном файле app/config/parameters.yml. Теперь такие параметры следует задавать с помощью переменных окружения. Это дает некоторые преимущества перед использованием parameters.yml. Например вы можете динамически менять данные параметры без необходимости чистить кеш. Переменные окружения можно использовать совместно в нескольких приложениях и языках программирования. Наконец вы можете администрировать данные параметры с помощью сторонних приложений.
На боевом сервере такой подход выглядит весьма привлекательно. Но в момент разработки приложения, использование переменных окружения может доставить много неудобств. Symfony 3.3 уже поставляется с компонентом Dotenv, который призван решить проблему. В корне вашего приложения будет располагаться файл .env, в котором можно определить переменные окружения. Компонент Dotenv, позволяет «переключаться» между использованием .env файла и реальными переменными окружения.
Во многих проектах существуют сценарии, для которых использование скриптов, написанных на PHP, не совсем целесообразно(например такие вещи как рестарт веб-сервера или перезагрузка конфигурации php-fpm после очередного деплоя).
Для этих целей предлагается использовать Makefile. Утилита make знакома всем. Ее использование лучше, чем выполнение скриптов с помощью Composer (если вы прописали их в composer.json). Так же утилита make выполняется централизованно на вашей системе и не зависит от PHP. Давайте рассмотрим реальный пример, в Symfony есть консольные команды для очистки и разогрева кеша. Использование двух команд в одном процессе работает не так как нужно, потому что PHP не умеет перезагружать классы если они изменились. Эту проблему можно легко решить с помощью вот такого Makefile:
Именно такой файл вы получите в стандартной сборке Symfony 4 приложения.
Я столкнулся с небольшой проблемой тестируя установку на Windows машине. Если для nix систем утилита make является стандартной, то на Windows нужно немного постучать в бубен. Проблема не в том, чтобы найти реализацию make для Windows, а в том, что в сценариях присутствуют вызовы таких команд test, rm и т.п. Обсуждение данного вопроса было тут.
Для себя я определил два способа решения этой проблемы:
1. Использовать GitBash в качестве терминала. Если вы используете Git, то скорее всего GitBash присутствует в вашей Windows системе.
2. Сегодня я настраивал свою любимую IDE PhpStorm на использование Cygwin терминала по умолчанию. И мне это решение понравилось больше, чем использование GitBash.
На этом пока все. Впереди материал о первых впечатлениях и инструкция по сборке приложения с помощью плагина Symfony Flex.
В свое время в Symfony 3 появились каталоги bin/, src/, var/, что по-моему мнению очень удобно и понятно. Мы все привыкли работать с такими каталогами. В свою очередь, Symfony 4 движется в этом же направлении и предлагает обновленную структуру каталогов приложения.
tests/ для тестов
Все тесты теперь будут располагаться непосредственно в каталоге tests/. Ранее в каталоге tests/ всегда присутствовали каталоги с именами бандлов вашего приложения в которых находились тесты. В Symfony 4, приложения не будут (или не обязательно должны) реализовывать код в каком либо бандле. Это позволит определить собственное пространство имен тестов для автозагрузки:
{
"autoload": {
"psr-4": {
"App\\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"App\\Tests\\": "tests/"
}
}
}
templates/ для шаблонов
При установке шаблонизатора Twig, теперь будет создаваться каталог templates/ в корне приложения, где и будут размещаться все шаблоны. Мне очень нравится эта идея, потому что каталог Resources, который содержал в себе до этого и публичные файлы (css, js и т.п.) и шаблоны, вносил некоторый дискомфорт. Возможно, что каталог будет называться tpl/, это еще пока окончательно не известно. В целом, перемещение шаблонов из каталога src/ делает приложение более структурированным. Теперь в src/ лежит только код. Класс Kernel, который ранее располагался в папке app/, так же перемещен в src/ где ему и место.
config/ для конфигураций
Каталог config/ заменит существовавший ранее app/config. Параметры окружения, которые ранее определялись в файле parameters.yml, теперь конфигурируются с помощью переменных окружения операционной системы. По умолчанию в каталоге config/ вы обнаружите пустой файл container.yaml (yaml — это не опечатка, в Symfony 4 конфигурационные файлы в формате YAML, теперь имеют расширение yaml, вместо yml)в котором как и прежде можете определять конфигурацию контейнера. Так же там будет файл routing.yaml. В данных файлах вы будете определять только собственные настройки. Компоненты, установленные с помощью Composer, будут хранить свои настройки в отдельных файлах для каждого окружения.
Конфигурацию как и прежде можно будет задавать в трех форматах: YAML, XML, PHP. Помимо конфигурационных файлов, в каталоге config/ появится bundles.php, который будет представлен массивом бандлов, активных в вашей системе.
//bundles.php
<?php
return [
'Symfony\Bundle\FrameworkBundle\FrameworkBundle' => ['all' => true],
'Symfony\Bundle\TwigBundle\TwigBundle' => ['all' => true],
];
Изменения в этот файл будут вноситься автоматически плагином Synfony Flex, при установке или удалении любого бандла в системе с помощью Composer.
var/cache/ только для кеша
Небольшие изменения коснулись каталога var/. Теперь в var/cache/ будет храниться только «вечный» кеш (скомпилированный контейнер и переводы, или кеш доктрины например). Таким образом все файлы в var/cache/ должны иметь свой warmup класс. Никаких временных файлов, только кеш, который не изменяется после деплоя проекта. Это позволит сделать var/cache/ каталог доступным только для чтения. При таком подходе вы сможете работать с read-only файловыми системами (например как на платформах Heroku или SensioCloud).
web/ переименован в public/
Так же изменилось содержимое каталога public/. Убраны файлы config.php, .htaccess, favicon.ico, apple-touch-icon.png, robots.txt. Не каждый проект нуждается в этих файлах. Если вам потребуются шаблоны для этих файлов, то Symfony 4, предоставит вам возможность опционально получить их.
Изменился и фронт-контроллер. Теперь вместо привычных app.php и app_dev.php будет присутствовать один файл index.php для всех окружений:
if (!getenv('APP_ENV')) {
(new Dotenv())->load(__DIR__.'/../.env');
}
if (getenv('APP_DEBUG')) {
if (isset($_SERVER['HTTP_CLIENT_IP'])
|| isset($_SERVER['HTTP_X_FORWARDED_FOR'])
|| !(in_array(@$_SERVER['REMOTE_ADDR'], ['127.0.0.1', '::1']) || PHP_SAPI === 'cli-server')
) {
header('HTTP/1.0 403 Forbidden');
exit('You are not allowed to access this file.');
}
Debug::enable();
}
// Request::setTrustedProxies(['0.0.0.0/0'], Request::HEADER_FORWARDED);
$kernel = new Kernel(getenv('APP_ENV'), getenv('APP_DEBUG'));
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);
Используем переменные окружения для конфигурации
Настройки, специфичные для конкретной платформы и окружения, ранее принято было хранить в конфигурационном файле app/config/parameters.yml. Теперь такие параметры следует задавать с помощью переменных окружения. Это дает некоторые преимущества перед использованием parameters.yml. Например вы можете динамически менять данные параметры без необходимости чистить кеш. Переменные окружения можно использовать совместно в нескольких приложениях и языках программирования. Наконец вы можете администрировать данные параметры с помощью сторонних приложений.
На боевом сервере такой подход выглядит весьма привлекательно. Но в момент разработки приложения, использование переменных окружения может доставить много неудобств. Symfony 3.3 уже поставляется с компонентом Dotenv, который призван решить проблему. В корне вашего приложения будет располагаться файл .env, в котором можно определить переменные окружения. Компонент Dotenv, позволяет «переключаться» между использованием .env файла и реальными переменными окружения.
Как насчет Makefile?
Во многих проектах существуют сценарии, для которых использование скриптов, написанных на PHP, не совсем целесообразно(например такие вещи как рестарт веб-сервера или перезагрузка конфигурации php-fpm после очередного деплоя).
Для этих целей предлагается использовать Makefile. Утилита make знакома всем. Ее использование лучше, чем выполнение скриптов с помощью Composer (если вы прописали их в composer.json). Так же утилита make выполняется централизованно на вашей системе и не зависит от PHP. Давайте рассмотрим реальный пример, в Symfony есть консольные команды для очистки и разогрева кеша. Использование двух команд в одном процессе работает не так как нужно, потому что PHP не умеет перезагружать классы если они изменились. Эту проблему можно легко решить с помощью вот такого Makefile:
cache-clear:
@test -f bin/console && bin/console cache:clear --no-warmup || rm -rf var/cache/*
.PHONY: cache-clear
cache-warmup: cache-clear
@test -f bin/console && bin/console cache:warmup || echo "cannot warmup the cache (needs symfony/console)"
.PHONY: cache-warmup
Именно такой файл вы получите в стандартной сборке Symfony 4 приложения.
Я столкнулся с небольшой проблемой тестируя установку на Windows машине. Если для nix систем утилита make является стандартной, то на Windows нужно немного постучать в бубен. Проблема не в том, чтобы найти реализацию make для Windows, а в том, что в сценариях присутствуют вызовы таких команд test, rm и т.п. Обсуждение данного вопроса было тут.
Для себя я определил два способа решения этой проблемы:
1. Использовать GitBash в качестве терминала. Если вы используете Git, то скорее всего GitBash присутствует в вашей Windows системе.
2. Сегодня я настраивал свою любимую IDE PhpStorm на использование Cygwin терминала по умолчанию. И мне это решение понравилось больше, чем использование GitBash.
На этом пока все. Впереди материал о первых впечатлениях и инструкция по сборке приложения с помощью плагина Symfony Flex.