тут подмать о переделке действий с модалкой на ajax.

Придумали идею, нашли задачу, а она тут фактически и озвучена. В общем

• Делаем атрибут #IsAjax
• Преопределяем листенер или контроллер так, что бы он читал атрибут, и если нет, стандратный симфоневый путь, если стоит, то формируем саами ajax ответ с ошибкой.
• Продумываем дальше систему переводов и описаний ошибок и перетрящиваем дерево исключений
• Вспоминаем в каких ajax-роутах уже накручены try-catch и убираем их.

И вот у нас новый ajax роут, и нам вновь приходится в нем городить копипасту по формированию корректного ошибочного ответа апи. А после в планах еще и коменты на ajax перевести, это еще добаивть роутов. Так что задача весьма актуальна

Еще один плюс, если мы вынесем постройку меню в отдельные билдеры, у нас будет больше гибкости. Например самые важные и простые меню можно строить и не через евент, а вызывая напрямую из TwigExtension. Можно в TwigExtension оборачивать вызов евента в try { } catch и в случае ошибки вызывать какой-то базовый набор билдеров. которые точно пройдут успешно.

Это и решит проблемы очень похожих обработчиков. Т.е. каждый подписчик на MenuEvent на самом деле только слушает событие и вызывает соответствующий menuBuilder, оборачивая вызов в try { ... } catch. Билдеры могут быть организованы по своим правилам, например в одном классе обрабатывать и side и navbar меню. Вопрос кто будет зависеть от реквеста?

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

Вобще ошибки отрисовки меню не должны ронять важные детали проекта.

• Простое решение - завернуть отправку евента в try { ... } catch и в случае неуспеха не выводить данное меню. (но тут может быть сложно уйти из ошибки)
• Решение сложнее - как-то отлавливать исключение от каждого из обработчиков (т.е. сами функции build…Menu должны оборачивать сборку в try { ... } catch, чтобы другие обработчики имели шанс построить свои части меню. И в челом подписчик сам не должен определять логику меню, он должен как контроллер определять что будет выполнено на этапе.

А что будет, если какой-то плагин решит добавить свой пункт в меню и свалится с исключением? Не будет ли он бесконечно рисовать страницу ошибки со своим меню и вновь валиться?

О, я вспомнил нафига я начал описывать ошибки через int’вые коды вместо класса, текстовой константы и подобного. А потому что ErrorController получает FlattenException, который теряет кастомную инфу исключения. Зачем он нужен вопрос, но нам это надо будет учесть.

Пришло от tndt-11, так как там axiom должен поймать ошибку и корректно вывести