Как стать автором
Обновить

Комментарии 29

Перешёл по первой ссылке… интересно…

Прошу прощения. Поправил ссылку.

Опять же ИМХО, но как можно его назвать фреймворком, если в нём из коробки только роутинг? Даже реализации контейнера нет...

trawl, app/Provider/AppProvider.php — такую портянку теперь обязательно писать?
Прекрасно что ребята повыкидывали всё на свете из фреймворка, так что даже не понятно, а что там вообще осталось, но вот такой бойлер плейт огорчает.

Добавлена фабрика для создания экземпляра приложения;

наверное это хорошо для гибкости, только подталкивает к созданию многофункциональных комбайнов, теперь можно делать два в одном, три в одном и так далее, только зачем? может быть просто сделать два или три отдельных приложения которые будут шарить одни и те же либы (пакеты, зависимости)?
С другой стороны если делать тестирование на коленке, то наверное удобно, на одном и том же сервере можно прогнать один и тот же тест на двух немного разных реализациях.

Обработчик запроса приложения теперь принимает только объект запроса (в старой версии принимал объекты запроса и ответа).

Раньше можно было на каждом этапе что то в ответ добавить, но видимо это ни кому не нужно.

Лично мне не понятно зачем всё это было сделано. Фреймворк это всё такие готовый набор инструментов и какие то направляющие для работы, а теперь 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.

Slim использует PSR-11-совместимый контейнер, но не благоприятствует контейнерам с autowire:
Обращаемся к исходному коду:
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, если он может инициализировать запрошенный элемент. А слим потом его из контейнера спокойно себе получит. Не вижу, честно говоря, проблем с автовайрингом

Если контейнер от ларавеля (пробовал Slim 4 Alpha/beta именно с ним) не является нормальным autowire-контейнером, то Вы, вероятно, правы и я ошибаюсь на этот счёт

Я не знаю, как устроен контейнер от ларавеля, но если он при вызове метода get может вернуть запрошенный объект, а при вызове has с тем же аргументом возвращает false, то он не является нормальным:)

Ну да, в интерфейсе комментарий к ->has():
* Returns true if the container can return an entry for the given identifier.
А в Illuminate\Container ->has() возвращает значение $this->bound()
Ну да, как-то не нормально :)

Исходя из кода (пробежался глазами диагонально) можно предположить, что контейнер требует предварительной настройки связей запрашиваемых имен и возвращаемых элементов. То есть, это не совсем авто вайринг:)

Нет, я был не прав. Он действительно autowire через рефлексию. Но вот метод has не проверяет возможность автоматической инициализации! Действительно, странно

Slim всё же привычнее Falcon и легче Lumen. Кажется, дальше уже только чистый php… ну как Gentoo =)
Забавно, что чистый PHP, считающийся одним из самых простых языков, теперь сравнивают с Gentoo.
Если работаем с git, добавим файл .gitignore и внесем туда директорию vendor (и диреткорию своей IDE при необходимости)

Не засоряйте .gitignore локальными правилами, используйте для этого глобальный файл, напрмер:
git config --global core.excludesfile ~/.gitignore_global

т.е. после выполнения команды можно внести /.idea в ~/.gitignore_global и забыть?

Все верно. У меня там
.idea/
.DS_Store

После внесения легко проверяется с помощью git status
И сразу ваши коллеги понапихают туда запрещенки, если владелец репозитория не следит за этим и не проверяет весь код.
Я сторонник прописывания правил для ОС и популярных IDE: понятно, что принципиально это некорректно, однако на практике полезно.

Спасибо, не знал. После git init всегда делал 'echo ".idea/" >.git/info/exclude'

на самом деле

И как теперь гуглить подключение шаблонизатора slim к фреймворку slim? Провальное название, не делайте так, всегда проверяйте нейминг перед!

Не понял, о чём Вы

Гугление вряд ли бы помогло.
Первый комит шаблонизатора: 12 Sep 2010
Первый комит фреймворка: 20 Sep 2010
Ну и сомневаюсь, что кто-то захочет подключать шаблонизатор на Ruby к фреймворку на php

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.