Size: a a a

2021 September 19

EG

Egor Gruzdev in Laravel Pro
А почему ты решил, что это происходит не классе FormRequest?
источник

d.

dev . in Laravel Pro
чаще всего бесполезная трата времени. аргумент про смену бд неубедителен.
вещь полезная когда заведомо известно что данные будут браться откуда-то с другого места но временно давайте брать из бд. например пока из бд потом из эластика.

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

MR

M R in Laravel Pro
1) распределение обязанностей
2) если для этого предоставлен функционал, наверное он не просто так?
источник

M

Maxx in Laravel Pro
если код используется лишь однажды, не лучше ли держать его поближе к тому месту, где он нужен?
ладно б ещё если было там мощное переиспользование, но тут — зачем наворачивать кучу лишних классов?
источник

MR

M R in Laravel Pro
это не требует много времени, и когда проект состоит не из пару строк кода, им легче управлять, так как знаешь что и где
источник

MR

M R in Laravel Pro
это принцип ООП
ты можешь писать так, как пишешь
я лишь предлагаю
источник

EG

Egor Gruzdev in Laravel Pro
Ответ не на мой вопрос?

Я попросил уточнить, как автор ответа определил, что приведенный кусок кода находится в контролере, а не в классе отвечающим за валидацию, т.е. FormRequest
источник

MR

M R in Laravel Pro
)))
источник

MR

M R in Laravel Pro
я вроде скинул код из From Request?
источник

MR

M R in Laravel Pro
сходств вроде нет :т
источник

MR

M R in Laravel Pro
и да, конечно он мог выделить валидацию в другой метод, но где? в контроллере?)
А если создал отдельный класс, то зачем? если для этого уже есть возможность в ларе) Чтобы другой разработчик, при встрече кода искал этот злоебучий класс?)
источник

EG

Egor Gruzdev in Laravel Pro
Изучи документацию еше раз по классу FormRequest, в частности методы типа preValidation(), withValidator() и др.

В данном случае after мог быть вызван в методе withValidator()
источник

MR

M R in Laravel Pro
верно, но зачем тогда привязывать $request?
источник

MR

M R in Laravel Pro
я не понимаю, вы тут доебаться ради или как?)
источник

EG

Egor Gruzdev in Laravel Pro
А вот это как раз и ответ на мой вопром, значит топикстартер использовал фасад Validator в контролере.

Хотя это не протеворечит подходу Laravel, а если у автора liveware, то там нет возможности использовать FormRequest
источник

EG

Egor Gruzdev in Laravel Pro
Даже в мыслях не было.
источник

MR

M R in Laravel Pro
возможно)
а возможно он сделал так: $request = $this->request)
источник

MR

M R in Laravel Pro
даже если и так, как по мне реализовать это в rules() будет читабельнее
источник

EG

Egor Gruzdev in Laravel Pro
Тогда вот так $rеquest = $this
Помню так приходилось делать в PHP 5.3, пока не научили функции замыкания видить окружение объекта
источник

?

? in Laravel Pro
А где лучше всего валидировать значение тогда, которое в любом случаи нужно будет смотреть в БД, например тот же имейл при создании кастомера?
источник