2017-01-01 2 views
5

Я ищу информацию о соглашениях об именах, которые я использую для имен маршрутов и просмотра структур каталогов.Соглашения об именах маршрутов и просмотров

Скажем, у меня есть следующие маршруты:

Route::get('/teams/choose', '[email protected]')->name('teams.choose.index'); 

Route::post('/teams/choose', '[email protected]')->name('teams.choose'); 

Route::get('/teams/{team}/manage', '[email protected]')->name('teams.team.manage.index'); 

Для get маршрутов, я бы nornally поставил точку в структуре каталогов, совпадающим с именем маршрута. Например. resources/views/teams/team/manage/index.blade.php. Однако я чувствую, что это слишком много.

Я чувствую, что это будет путать все вокруг (для меня и других разработчиков), если бы я использовал структуру каталога представлений, как это, а не последний пример: resources/views/team/manage/index.blade.php - множественное число team не используется, поэтому, когда У меня есть другие взгляды, например (с использованием оригинального примера): resources/views/teams/choose.index они не визуально имеют отношение. То есть у них есть другой «корневой» каталог - teams vs team.

Любой вход или совет будут оценены.

ответ

7

Для маршрутов get я обычно помещал представления в структуру каталогов, соответствующую названию маршрута. Например. resources/views/teams/team/manage/index.blade.php. Однако я чувствую, что это слишком много.

Согласен.


От Laravel docs:

Laravel использует типичный RESTful "CRUD" подход при назначении ресурсов маршрутов к контроллеру. Каждый глагол (т.е. GET, POST, PUT, DELETE) получает назначенный URI, в действие (технически, метод управления) и имя-маршрута в (иногда, /path/to/blade/view).

Итак, с вашего сниппета:

// return view(teams.index) 
Route::get('/teams', '[email protected]'); 

// return view(teams.create) 
Route::get('/teams/create', '[email protected]'); 

// redirect('/home'); 
Route::post('/teams', '[email protected]'); 

// return view('teams.profile') 
Route::get('/teams/profile', '[email protected]')->name('profile'); 

Я использую эту resource table, чтобы напомнить мне, что состоятельным и что-не-делать все время.

Возможно, проверка некоторых из awesome Laravel codebases может помочь. Плюс, перспектива того, как другие команды делают вещи, всегда бесценна.

Я нашел это очень полезно:


Update

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

Отъезд Adam Wathan's talk at Laracon EU, как он показывает, как, все может быть CRUDDY с небольшим воображением.

+0

Большое спасибо! – AshMenhennett

Смежные вопросы