Сергей Протько: Возможно уже надоел, но не могли бы вы осветить еще один момент: как тогда должен происходить вызов самих миддлеверов? Что должно их агрегировать. Допустим роутер нашел нужный роут и перед его вызовом нашел миддлеверы связанные с этим роутом. Каким образом можно их вызвать?
Сергей Протько: Наверное глупый вопрос, но все же: как я понял next - это следующий миддлевер, а если так, то у них тоже должен быть общий интерфейс и на вход он тоже должен принимать два аргумента, request и next. И каким тогда образом вызывается сама цепочка миддлеверов?
Сергей Протько: Подобную фичу видел в Laravel и в Kohane. Так вот, в laravel если все маршруты обрабатываются контроллерами можно вызвать артизан команду php artisan route:cache что сгенерирует кеш-файл маршрутов и по заверениям разработчиков выигрыш в производительности от данной фичи заметно большой, вот и интересно как подобное реализуется.
Спасибо за линк, в итоге сделал следующим образом: унаследовал от класса ImageCollection класс ImageCollectionProxy который принимает собственно объект Lazy и по требованию предоставляет ImageCollection в доменном объекте остается только проверить instanceof и если проходит, то вызвать метод load() объекта ImageCollectionProxy.
Register::auth()->is_authorized() в моем случае я достаю из реестра приложения объект отвечающий за аунтефикацию пользователя и в случае, если пользователь авторизован перекидываю его в корень
Тут дело в том, что на странице /login выводиться форма регистрации или форма авторизации ну соответственно отлавливаю какая из форм отправлена и обрабатываю в одном действии
Ну примерно так я и представляю весь этот процесс, но вот допустим есть следующая ситуация: авторизировался пользователь иван петров, затем он поменял имя в вк и стал петром ивановым, не суть важно, а в моей базе забиты его старые данные меня интересует эта заморочка, дергать каждый раз метод апи или просто оставить старые данные?