В книге просто и доходчиво… Приводится детальное описание причин,… почему настоящий руководитель должен вырасти внутри предприятия, а не быть привлеченным извне. Только человек, выросший в компании, прошедший с ней большой путь – желательно, лет в 15, понимает и чувствует ее, в прямом смысле.
т.е. Король прошёл на птицефабрике абсолютно иной, но успешный путь, и теперь рекомендует книгу, в которой вообще всё не так?
Не люблю я этих тайн мадридского двора, потому и не стал интересоваться подробнее
А поинтересовался бы, может и понял бы, что этот Король не просто "эффективный", а ещё и паразитирующий и не умеющий в честную игру.
Можно, учитывая это обстоятельство, писать промежуточное ПО, принимающее в конструкторе контейнер.
Можно переопределить \Slim\MiddlewareDispatcher путём наследования, а потом наследоваться от \Slim\App.
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/*.
Подвеска — адаптированные решения восьмого и десятого семейства Lada.
Это произошла такая нехилая адаптация, чтобы из макферсона сделать двухрычажную, которая как раз и использовалась Ладой/ВАЗом, но ДО восьмого семейства.
Т.е. в разрезе юнит-теста я должен был закончить тест-кейс на моменте проверки возвращаемого результата/исключения, а всё остальное — вынести в отдельный тест?
Но проверка, вызывался ли в сервисе метод сохранения данных — это же не интеграционное тестирование? Или в юнит-тестах нет необходимости проверять этот момент?
Но как тогда проверить, сохранилась ли сущность в БД
Конечно же, речь шла о проверке вызова метода сохранения.
В проектах на Symfony, как правило, репозитории используют только для выборки данных, а сохранение осуществляется через EM. Именно такой кейс и рассмотрен в статье
Ну не знаю… Сижу на Linux, но купил PHPStorm. Ни разу не пожалел.
Laravel умеет в ротацию логов из коробки. Есть драйвер
dailyРекомендую попробовать Deployer. Написан на php, Добавляется через Composer, изучается и прикручивается за вечер
т.е. Король прошёл на птицефабрике абсолютно иной, но успешный путь, и теперь рекомендует книгу, в которой вообще всё не так?
А поинтересовался бы, может и понял бы, что этот Король не просто "эффективный", а ещё и паразитирующий и не умеющий в честную игру.
Будет ли у вас онлайн трансляция или какая-нибудь другая возможность послушать/посмотреть/почитать доклады?
Как-то так:
т.е. в каждом релизе есть символьные ссылки на директории с общими файлами.
Спасибо спикерам за доклады! Спасибо 2гис за организацию!
Не понял, о чём Вы
Не знал. Спасибо!
т.е. после выполнения команды можно внести
/.ideaв~/.gitignore_globalи забыть?Можно, учитывая это обстоятельство, писать промежуточное ПО, принимающее в конструкторе контейнер.
Можно переопределить
\Slim\MiddlewareDispatcherпутём наследования, а потом наследоваться от\Slim\App.Но оба варианта
такое себе...Именно так!
Можно воспользоваться любым контейнером, который реализует PSR-11.
Прошу прощения. Поправил ссылку.
Конечно же не обязательно.
Можно сократить, сразу забиндив интерфейс к реализации, заменить
на
Можно инициализацию каждого элемента контейнера вынести в свой провайдер, а чтобы вручную не прописывать все провайдеры в бутстрапе, можно найти все файлы в указанной директории и подключить их.
Если нет необходимости использовать роутер в сервисах, контроллерах, командах и т.д., можно вообще через фабрику создать экземпляр приложения, вынести обработчик ошибок в
public/index.phpи вообще удалить AppProvider.Сделать можно так, как вам удобно.
Как уже ответили, и сейчас можно.
Я полагаю, что на данный шаг разработчики пошли во имя следования стандартам PSR (В частности, PSR-15 Middleware)
Slim — это микрофреймворк. А направляющие для работы в нём — пакеты psr/*.
Опять же ИМХО, но как можно его назвать фреймворком, если в нём из коробки только роутинг? Даже реализации контейнера нет...
В статье написано:
Это произошла такая нехилая адаптация, чтобы из макферсона сделать двухрычажную, которая как раз и использовалась Ладой/ВАЗом, но ДО восьмого семейства.
Передняя подвеска больше напоминает классическую (01-07), нежели 8 и 10 семейства...
Т.е. в разрезе юнит-теста я должен был закончить тест-кейс на моменте проверки возвращаемого результата/исключения, а всё остальное — вынести в отдельный тест?
Но проверка, вызывался ли в сервисе метод сохранения данных — это же не интеграционное тестирование? Или в юнит-тестах нет необходимости проверять этот момент?
Да, я не правильно выразился в высказывании
В проектах на Symfony, как правило, репозитории используют только для выборки данных, а сохранение осуществляется через EM. Именно такой кейс и рассмотрен в статье
Согласен, вариант хорош. Но как тогда проверить, сохранилась ли сущность в БД? Или сохранение тоже вынесено в репозиторий?
А я недавно как раз писал перевод поста, на котором и основан этот пакет