А
я надеюсь в роутере будет точка расширения парсера конфигурации
Size: a a a
2020 August 16
А
хотя тут можно на этапе вызова всё разрулить же
AP
В этом плане в моем коде будет уже легче, при построение роутов я убрал валидацию middleware-ов, валидация уже будет происходить только для route match перед вызовом
AP
Вот)) не успел написать
А
валидацию лучше оставить но ручным вызовом
А
ну или подумать как лучше сделать (может отдельный класс, может это запускатор мидлварей/экшенов будет делать, если попросить)
AP
Смысл валидации для тех путей, которые не будут матчить вообще?
А
Arman Poghosyan
Смысл валидации для тех путей, которые не будут матчить вообще?
просто отвалидировать. Как часть теста
AP
У меня же handler отдельный все делает теперь, он там и проверяет.
AP
ХЗ, зачем проверять формат на этом этапе, у меня может быть 100+ маршрутов, большинство которых вообще редко срабатывают, и для всех заранее валидировать? Если я не протестил свое приложения и пути, это же проблема моя - как разработчика
А
но функцию "прочекать все маршруты" тоже надо
AP
Так отдельно можно куда-то добавить метод для валидации, а не по автомату это делать для всех путей
А
Arman Poghosyan
ХЗ, зачем проверять формат на этом этапе, у меня может быть 100+ маршрутов, большинство которых вообще редко срабатывают, и для всех заранее валидировать? Если я не протестил свое приложения и пути, это же проблема моя - как разработчика
всякое бывает. Удалил класс, не найдя его упоминания в роутере в виде "class@method" и всё. Залил в прод и какойнить юзер наткнулся.
А
Arman Poghosyan
Так отдельно можно куда-то добавить метод для валидации, а не по автомату это делать для всех путей
я о том и говорю - ручная валидация нужна
AP
Может я тупо путь невозможный прописал, или еще что-то и никогда вообще вызова не будет, а валидация полюбому так срабатывает
AP
я о том и говорю - ручная валидация нужна
Ну ок, ручную валидацию добавлю, хотя пока не понятно куда - разберусь. А валидация сейчас срабатывает только в handler-е, я потом issue добавлю по формату вызова этого
DS
А как ещё? Это же весь смысл конфига и контейнера.
Тогда надо говорить что в контейнере не может быть объектов без стейта. Если позволяешь вызывать with* при конфигурировании, то значит ты задаешь стейт этих классов в контейнере.
AM
всякое бывает. Удалил класс, не найдя его упоминания в роутере в виде "class@method" и всё. Залил в прод и какойнить юзер наткнулся.
Лучше наткнулся чем "всё упало". Консольный чекер можно сделать или что-то такое.
DS
С точки зрения обычного пхп это объекты без стейта, с точки зрения рр они со стейтом
AM
В контейнере технически может быть то угодно...