PHP выполняет проверки типов в runtime.Значит, все аргументы дженериков должны быть доступны через reflection в runtime.А этого не может быть, потому что информация о аргументах дженериков после генерации конкретных классов стирается.
Как вариант - добавить в сгенерированые классы атрибуты, в которых уже эти данные предоставить
Увидел. Спорно, все-таки сама статья не об этом. И мне кажется, не хватает хаба "Я пиарюсь", т.к. по ссылке просят 8к рублей за реализацию шаблонов на PHP
Заодно можно будет избавится от массива, а сразу передавать нужные параметры в эвент. В противном случае каждый раз надо будет заходить в реализацию makeNotificationEvent, смотреть какой эвент должен создаться при order_created и какой массив параметров он ожидает
public function createOrder(CreateOrderRequest $request)
{
$this->notificationService->notify(new OrderCreatedEvent($order));
}
Можно ли использовать сервисы внутри сервисов?
Я бы однозначно не рекомендовал такую практику, так как этим вы нарушаете single responsibility принцип, делая ваш код, к тому же, достаточно запутанным.
Тут нет ошибки? Потому что во втором пункте вы по сути предлагаете использовать сервисы (OrderService и NotificationService) внутри сервиса (CreateOrderOperation)
Получается, если разработчик решил порефакторить код, а работа с переводами уже закончена, т.е. никто в админку не зайдет и не увидит этих сообщений, то могут быть проблемы?
Часто возникает дилемма — использовать существующий текст или создать новый? А вдруг в этом новом месте чуть-чуть другой контекст?
А вот эта проблема как решается? К примеру у нас есть одна и та же фраза, но в разных файлах и, соответственно, разный контекст. Правильно я понимаю, в админке будет зарегистрированы две фразы и соответственно то, где они вызываются, и переводчикам самим предлагается определить контекст перевода?
А если вдруг мы код отрефакторили и теперь эти фразы вызываются из другого места?
О чем и говорит TheCluster. Этого уже нет. Вот, к примеру, конфиг для демо приложения. Он отличается от дефолтного всего несколькими строчками.
Ну а что касается аннотаций, то их можно не использовать: php, yaml, xml — выбирай не хочу
Эти переменные используются в описании сервисов и конфигов, т.е. напрямую в коде обращения к ним нет. Загрузка идет через Dotenv компонент. Если вдруг понадобится, то можно обратится к ним стандартным способом, но это не рекомендуется и может привести к ошибкам компиляции контейнера.
Если речь про дефолтные значения, то их можно задать в конфиге:
parameters:
env(FOO): bar
но не думаю, что так кто-то делает, если они все равно загружаются из .env. Иначе это добавляет еще одно место, где нужно синхронизировать дефолтные значения.
Правильно понимаю, что вам нужно синхронизировать дефолтные значения не только в .env.example, но и везде, где эти переменные используются (к примеру, везде где есть вызов env('FOO', 'bar'))?
2.Тоже жду эту фичу. Проголосовать можно тут: https://youtrack.jetbrains.com/issue/IDEA-228145
Лео и Тиг, кстати, неплох, да еще и с пасхалками
Как вариант - добавить в сгенерированые классы атрибуты, в которых уже эти данные предоставить
Я бы посмотрел на тесты этого класса
Увы, да. В RFC как раз есть пример:
Это как раз сделано для того, чтобы в query builder нельзя было передать пользовательский ввод. Только через placeholder-ы
Уже есть: https://symfony.com/blog/new-in-symfony-5-3-inlined-serialization-context
В 5.3.0 эта проблема исправлена
Можно сохранять результаты парсинга в аттрибуты реквеста, а в декораторе к ArgumentResolverInterface удалять этот ключ
Можно сделать через соглашение. Сначала искать по имени аргумента
Можно воспользоваться благами php8
Чем не устроил
symfony/serializer
?Увидел. Спорно, все-таки сама статья не об этом. И мне кажется, не хватает хаба "Я пиарюсь", т.к. по ссылке просят 8к рублей за реализацию шаблонов на PHP
А при чем тут php?
Почему сразу не передавать
MailEventInterface
?Заодно можно будет избавится от массива, а сразу передавать нужные параметры в эвент. В противном случае каждый раз надо будет заходить в реализацию
makeNotificationEvent
, смотреть какой эвент должен создаться приorder_created
и какой массив параметров он ожидаетТут нет ошибки? Потому что во втором пункте вы по сути предлагаете использовать сервисы (
OrderService
иNotificationService
) внутри сервиса (CreateOrderOperation
)Получается, если разработчик решил порефакторить код, а работа с переводами уже закончена, т.е. никто в админку не зайдет и не увидит этих сообщений, то могут быть проблемы?
А вот эта проблема как решается? К примеру у нас есть одна и та же фраза, но в разных файлах и, соответственно, разный контекст. Правильно я понимаю, в админке будет зарегистрированы две фразы и соответственно то, где они вызываются, и переводчикам самим предлагается определить контекст перевода?
А если вдруг мы код отрефакторили и теперь эти фразы вызываются из другого места?
Как планируется вычленять переменные из строк?
И все-таки какие критерии?
Размер:
Количество файлов в скелете?
О чем и говорит TheCluster. Этого уже нет. Вот, к примеру, конфиг для демо приложения. Он отличается от дефолтного всего несколькими строчками.
Ну а что касается аннотаций, то их можно не использовать:
php
,yaml
,xml
— выбирай не хочуЭти переменные используются в описании сервисов и конфигов, т.е. напрямую в коде обращения к ним нет. Загрузка идет через Dotenv компонент. Если вдруг понадобится, то можно обратится к ним стандартным способом, но это не рекомендуется и может привести к ошибкам компиляции контейнера.
Если речь про дефолтные значения, то их можно задать в конфиге:
но не думаю, что так кто-то делает, если они все равно загружаются из
.env
. Иначе это добавляет еще одно место, где нужно синхронизировать дефолтные значения.Правильно понимаю, что вам нужно синхронизировать дефолтные значения не только в
.env.example
, но и везде, где эти переменные используются (к примеру, везде где есть вызов env('FOO', 'bar'))?