Комментарии 29
Перешёл по первой ссылке… интересно…
Прекрасно что ребята повыкидывали всё на свете из фреймворка, так что даже не понятно, а что там вообще осталось, но вот такой бойлер плейт огорчает.
Добавлена фабрика для создания экземпляра приложения;
наверное это хорошо для гибкости, только подталкивает к созданию многофункциональных комбайнов, теперь можно делать два в одном, три в одном и так далее, только зачем? может быть просто сделать два или три отдельных приложения которые будут шарить одни и те же либы (пакеты, зависимости)?
С другой стороны если делать тестирование на коленке, то наверное удобно, на одном и том же сервере можно прогнать один и тот же тест на двух немного разных реализациях.
Обработчик запроса приложения теперь принимает только объект запроса (в старой версии принимал объекты запроса и ответа).
Раньше можно было на каждом этапе что то в ответ добавить, но видимо это ни кому не нужно.
Лично мне не понятно зачем всё это было сделано. Фреймворк это всё такие готовый набор инструментов и какие то направляющие для работы, а теперь Slim это что угодно и как угодно.
Slim PHP — собери свой набор!
Slim был микрофреймворком, на следующем этапе он проскочил нанофреймворки и просто растворился — перестал быть фреймворком — ни каких рамок, творчество без границ.
Раньше можно было на каждом этапе что то в ответ добавить, но видимо это ни кому не нужно.
Вы имеете ввиду middleware? Если да, то это можно делать и сейчас, при этом нет неоднозначности:
// До
function middleware($request, $response1, $next) {
$response2 = $next($request, $response1);
// Есть 2 ответа, какой использовать?
return $response2->withHeader('foo', 'bar');
}
// После
function middleware($request, $next) {
$response = $next($request);
return $response->withHeader('foo', 'bar');
}
app/Provider/AppProvider.php — такую портянку теперь обязательно писать?
Конечно же не обязательно.
Можно сократить, сразу забиндив интерфейс к реализации, заменить
<?php
// app/Provider/AppProvider.php
namespace App\Provider;
// ...
class AppProvider implements ServiceProviderInterface
{
public function register(Container $container)
{
// ...
/*
* Регистрируем обработчик результатов роутера
*/
$container->set(RouteResolver::class, function (ContainerInterface $container) {
return new RouteResolver($container->get(RouteCollectorInterface::class));
});
/*
* Связываем интерфес обработчика результатов роутера с реализацией
*/
$container->set(RouteResolverInterface::class, function (ContainerInterface $container) {
return $container->get(RouteResolver::class);
});
// ...
}
}на
<?php
// app/Provider/AppProvider.php
namespace App\Provider;
// ...
class AppProvider implements ServiceProviderInterface
{
public function register(Container $container)
{
// ...
/*
* Регистрируем обработчик результатов роутера
*/
$container->set(RouteResolverInterface::class, function (ContainerInterface $container) {
return new RouteResolver($container->get(RouteCollectorInterface::class));
});
// ...
}
}Можно инициализацию каждого элемента контейнера вынести в свой провайдер, а чтобы вручную не прописывать все провайдеры в бутстрапе, можно найти все файлы в указанной директории и подключить их.
Если нет необходимости использовать роутер в сервисах, контроллерах, командах и т.д., можно вообще через фабрику создать экземпляр приложения, вынести обработчик ошибок в public/index.php и вообще удалить AppProvider.
Сделать можно так, как вам удобно.
Раньше можно было на каждом этапе что то в ответ добавить, но видимо это ни кому не нужно.
Как уже ответили, и сейчас можно.
Я полагаю, что на данный шаг разработчики пошли во имя следования стандартам PSR (В частности, PSR-15 Middleware)
Лично мне не понятно зачем всё это было сделано. Фреймворк это всё такие готовый набор инструментов и какие то направляющие для работы, а теперь Slim это что угодно и как угодно.
Slim — это микрофреймворк. А направляющие для работы в нём — пакеты psr/*.
А можно еще подключить контейнер который поддерживает autowire, и жить сразу станет легче и веселей. Описывать придется только какие-то исключения.
Именно так!
Можно воспользоваться любым контейнером, который реализует PSR-11.
Обращаемся к исходному коду:
github.com/slimphp/Slim/blob/4.x/Slim/MiddlewareDispatcher.php#L162-L172
О каком полноценном Autowire можно говорить, если не объявленный заранее в контейнере Middleware будет создаваться с передачей одного параметра ContainerInterface?
Причём MiddlewareDispatcher создаётся в конструкторе App вот таким незатейливым кодом:
$this->middlewareDispatcher = new MiddlewareDispatcher($routeRunner, $container);
Т.е. его не переопределить
Можно, учитывая это обстоятельство, писать промежуточное ПО, принимающее в конструкторе контейнер.
Можно переопределить \Slim\MiddlewareDispatcher путём наследования, а потом наследоваться от \Slim\App.
Но оба варианта такое себе...
но не благоприятствует контейнерам с autowire
Или я не верно Вас понял, или Вы не правы. В коде, на который Вы ссылаетесь, идет сначала вызов ContainerInterface::has(). Нормальный autowire-контейнер должен возвращать true, если он может инициализировать запрошенный элемент. А слим потом его из контейнера спокойно себе получит. Не вижу, честно говоря, проблем с автовайрингом
Я не знаю, как устроен контейнер от ларавеля, но если он при вызове метода get может вернуть запрошенный объект, а при вызове has с тем же аргументом возвращает false, то он не является нормальным:)
* Returns true if the container can return an entry for the given identifier.
А в Illuminate\Container ->has() возвращает значение $this->bound()…
Ну да, как-то не нормально :)
Если работаем с git, добавим файл .gitignore и внесем туда директорию vendor (и диреткорию своей IDE при необходимости)
Не засоряйте .gitignore локальными правилами, используйте для этого глобальный файл, напрмер:
git config --global core.excludesfile ~/.gitignore_global
И как теперь гуглить подключение шаблонизатора slim к фреймворку slim? Провальное название, не делайте так, всегда проверяйте нейминг перед!
Микрофреймворк slim