Nikita, тут это уместно, потому что можно очертить экшен как зависимость от репозитория и инстанцировать его вне экшена в сервис контейнере нормально, но репозитории не так часто инжектят в методы, чаще инжектят EntityManager (репозиторий будет получен уже внутри метода и связность кода будет ниже). В демке симфони просто не заморачивались с расширяемостью многих вещей, потому что это одноразовый проект, плюс ко всему есть принципы kiss и yagni (условно - не надо писать слишком гибкий код с первой попытки, потому эта гибкость может оказаться неоправдана с точки зрения бизнеса)
vicmalkovich, i5/8gb это очень мало для современной разработки. Windows для питона тоже не очень вариант, лучше линукс (или мак, если уже есть с ним опыт, но для разработки по нему тоже мнения расходятся)
Найдите где лежат логи ошибок веб сервера (apache или nginx) и логи ошибок php, после того как найдете, нужно закопипастить ошибку в гугл, 99% что легко решается
Dos,
На каждый тип нотификейшена свой месседж.
посмотрела исходники notifier - лично меня напрягает, что та есть прослойка под messenger, но эти message и messagehandler не расширяют интерфейсы messenger, т.е. как он их подхватит - непонятно. Можно еще в канал поддержки symfony в slack написать, там контрибьюторы часто тусят могут лучше подсказать
Dos,
1.1. Да, event dispatcher
1.2. Да
- в листенере/сабскрайбере создать, заполнить и сохранить NotificationEntity.
- создать класс NotificationMessage, который будет совместим с NotificationEntity (как передать энтити в месседж - документация).
- написать хэндлер для NotificationMessage (который имплементит Symfony\Component\Messenger\Handler\MessageHandlerInterface)
- в листенере/сабскрайбере вызвать MessageBus и задиспетчить ему Notification Message.
NotificationEntity тут нужно только в случае, если помимо непосредственно отправки нотификейшена нужен какой-то сбор данных или статистики по ним, т.е. для самого Messenger это не нужно.
- проверить, что bin/console messenger:consume ловит и обрабатывает сообщение
Я не совсем понимаю, с чем у Вас проблемы с базой) У messenger есть возможность задать разный транспорт для хранения очереди сообщений - можно в обычной базе (нп. mysql) - тогда нужно указать doctrine в качестве транспорта, если нужно использовать брокер сообщений, то можно указать amqp как транспорт. И там и там можно задать асинхронный режим обработки. Также для failed messages и retry обычно указывают doctrine как транспорт.
Я не могу показать свой проект (он под NDA), но там для этого случая нечему помочь - там самописный фреймворк с очередями на редисе, а для понимания messenger лучше почитать тексты из их курса - Messenger! Queue work for later, там до пятого или шестого видео можно смотреть бесплатно, а дальше текст к видео
Имхо такие вещи решаются не на голом языке, нужно ставить какие-то пакеты или сервисы морфологического анализа (если загнать данные в elasticsearch и делать запросы поиска к нему, то он должен анализировать корректно)
Borysenko, тогда надо врубить отображение ошибок в скрипте плюс посмотреть потребление памяти (memory_get_usage(), memory_get_peak_usage()), если будет течь именно память, то надо пробовать рекомендации по парсингу больших xml файлов (XMLReader, как описал Adamos)
Aleksandr231224, если вы упираетесь в непонимание того, как работает многостраничный сайт, то нужно почитать про настройку веб сервера и роутинг (правила перехода на страницы задаются в конфиге веб сервера, а реализация работы этих правил пишется в проекте через роутинг). В каждом фреймворке и цмс это реализуется немного иначе, но достаточно прочесть документацию и все станет понятно
