Не работает привязка моделей (model binding) без добавления к маршруту middleware('web') - как так-то?

ну если у тебя api то да, вообще ты можешь создавать свои middlewareGroups в Kernel и в провайлере привязывать их ко всем маршрутам, типо такого

Route::prefix('api')
            ->as('api.')
            ->middleware('api')
            ->namespace($this->namespace . '\API')
            ->group(base_path('routes/api.php'));

П.с отметь ответ решением, если помогло)

Не работает привязка моделей (model binding) без добавления к маршруту middleware('web') - как так-то?

Роми, покажи как ты обьявил свои кастомные роуты

Ошибка 405 (Method Not Allowed) при вополнении запроса через Axios?

php artisan route:list что говорит о наличии такого маршрута?

Не работает привязка моделей (model binding) без добавления к маршруту middleware('web') - как так-то?

Роми, так оно и работает через миделварь, твои роуты не причем

Но мой тебе совет не использовать это

Не работает привязка моделей (model binding) без добавления к маршруту middleware('web') - как так-то?

В что у тебя в Kernel?

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

jazzus, у вас и фронт на blade?

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

Роми, промкод не свойство, он дает какой-то бонус

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

jazzus, ну выглядит неплохо конечно) Возможно я просто привык делать как делаю

Зачем тебе ее в отдельный маршрут, а не параметром в реквест и в метод index

В индекс есть пагинация, в latest ее нет, и там только 3 модели отдается. По этому разделил на разные роуты. Так удобнее

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

jazzus,

Так и я о том. С ресурсами один раз копировать и вставить (если ide барахлит). А свои маршруты - 6 раз)

После гошки это вообще норма, копировать и вставлять))))

Просто пример роутов из последнего приложения что делаю, для понимания твоего

Route::group(['prefix' => 'fcm-tokens', 'middleware' => 'pre.auth:api'], function () {
    Route::post('/store', 'FcmTokenController@store');
    Route::post('/delete', 'FcmTokenController@delete');
});

Route::group(['prefix' => 'ratings'], function () {
    Route::get('/', 'RatingController@index');
});

Route::group(['prefix' => 'articles'], function () {
    Route::get('/index', 'ArticleController@index');
    Route::get('/latest', 'ArticleController@latest');
    Route::get('/search', 'ArticleController@search');
});

Route::group(['prefix' => 'youtube-videos'], function () {
    Route::get('/index', 'YoutubeVideoController@index');
    Route::get('/latest', 'YoutubeVideoController@latest');
});

Ну политики да, стоило бы использовать наверное. Ну я я обычно обхожусь так user->relations()->where('...)->firstOrFail()

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

jazzus, у меня нет проблем с тем, что бы скопировать, и вставить))

А чистых круд роутов со всеми методами практически не бывает в моей практике

Но согласен, что зависит от приложения, и если тебе удобно этим пользоваться, то круто)

На то и фреймворк, что бы предоставить множество инструментов, а мы программисты уже решаем как и где их использовать)

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

jazzus, применение промокода, это create, store или index?

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

jazzus, да, не использую

Бесполезные вещи как по мне. В реальном приложении очень редко нужен обычный crud.

А политики впринципе неудобная вещь, и мало полезная.

Есть другие инструменты

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

Роми, опять же, это все решается документаций) я лично не вижу никакого смысла в put и patch. И не использую.

А мои фронты используют те методы, которые я для них сделал и описал. Вот и все.

Остальное просто разговоры неочем, многие умники любят болтать, а не делать)

Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

Роми, ну да, действительно.

В любом случае, толку от него никакой нет.

Даже html 5 форма только get или post бывает

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

jazzus, если потом в админ Admin/PostController добавится что-то, как ты будешь делать? например возможность изменить дату для post

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

jazzus, почему тогда это разные котроллеры))

Вообще я предпочитаю дублирование такой логики, нежели писать что-то универсально, но сложное, а потом еще появляются всякие if когда в части кода меняются условия

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

jazzus, а ты юзаешь один форм реквест для разных контроллеров?

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

jazzus, https://github.com/adelf/freelance-example

Посмотри полный пример из книги, там есть форм реквесты

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

jazzus,

форм реквест можно юзать

я же не говорю что их не нужно юзать, и сам их юзаю. Поверь мне, доку лары знаю не хуже тебя)

Ты писал тесты?

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

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

jazzus, дело не в понтах, просто когда в 10+ местах кода меняется тот же статус, обязательно нужно его валидировать в самой сущности

Особенно когда логика статусов сложная, не может быть заказ готов, пока со склада не отгружен товар (условно)