Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [Laravel] - jeden kontroler na jeden obiekt?
Forum PHP.pl > Forum > PHP > Frameworki
bialko0019
Hej.

Mam pytanie odnośnie podejścia pro do tematu. Załóżmy, że mamy w panelu admina 3 zakładki. Spotkania, Telefony oraz mój dashboard. W dashboardzie chcę wyświetlić dzisiejsze spotkania i telefony, w Telefony lista zaplanowanych telefonów, w Spotkania analogicznie - lista wszystkich moich spotkań. I teraz.

Czy do tego zrobić 3 kontrolery, w którym każdy będzie odpowiadał za swoje, czyli kontroller do dashboardu, kontroller do listingu spotkań i kontroller do telefonów, i do tego każdy ma mieć swoją klasę?

Czy może dwa kontrollery, jeden za dashboard, a drugi dać jako Activity (activity to rekordy zaplanowanych spotań i tel, gdzie jest koluman type warunkująca czy to tel, czy spotkanie).

Czy może jeszcze inna droga i jeden kontroller i jeden model - tylko wtedy w akcjach index(), store() itd kontrollera muszę dawać jakieś switch case żeby operować na danych i wyświetlać albo dashboard, albo spotkania albo telefony,

Które rozwiązanie lepsze - a może jeszcze inaczej? Wolałbym dać tel i spotkania jako jedna klasa, bo to są prawie identyczne kolumny w bazie (tylko spotkanie ma jedną kolumnę więcej). Pytam się, ponieważ tych opcji będzie z 15 więc wolałbym dobrze podejść do tematu.

Z góry dzięki za info :-)
markonix
Liczbę modeli determinuje liczba tabeli. Jeżeli spotkania i telefony to jedna tabela tylko z różną kolumną (type) to masz jeden model. Tu nie ma co zbytnio kombinować.
Liczba kontrolerów, nie wpłynie to mocno na jakość kodu. Warto się trzymać jakiegoś standardu wszędzie i tyle.
1 kontroler na jeden zasób - np. /articles (i w nim wszystko co z artykułem, wszystkie CRUD metody i pozostałe).
W Twoim przypadku skoro to jeden zasób to jak dla mnie Controller:

activities/index albo /home - dashboard
activities/meeting - spotkania
activities/calls- telefony

Czyli jeden kontroler, 3 metody.
bialko0019
Super, dziękuję za odpowiedź.

Czyli tak. Zrobiłem jeden model Activity (w nim są spotkania i telefony) i jeden kontroller. Ok, ale jak jest metoda index() to ona będzie odpowiadać za trzy różne podstrony?
Np. /dashboard , /meeting , /calls i w środku musiałbym jakiegoś switch case zrobić, żeby tylko odpowiednie dane wyciągać do odpowiednich podstron. Tak mam, ale wydaje mi się, że to chyba inaczej się powinno zrobić? Może jakas grupa routingów tylko potem jak jest metoda store() czy index() to odpowiada za kilka akcji? Np. na podstronie /meeting może być wyszukiwarka itd.

Zrobiłem tak, ale wg. mnie to paskudne... ;/

  1. class CrmController extends Controller
  2. {
  3.  
  4. public function index($page_name, Request $request, Menu $menu, Activity $activity, User $user, Checklist $checklist, Post $post, $id = NULL)
  5. {
  6.  
  7. $result = [];
  8. $result['user_menu'] = $menu->UserMenu();
  9.  
  10. switch($page_name)
  11. {
  12. case 'dashboard':
  13. $result['planned_meet_activity'] = $activity->GetTodayActivity('meet');
  14. $result['planned_call_activity'] = $activity->GetTodayActivity('call');
  15. $result['checklist_user'] = $checklist->GetNumMissingChecklist();
  16.  
  17. $result['appartments'] = $post->GetPost('id', ['guide' => 1]);
  18. $result['clients'] = $post->GetUserClients($logged_user);
  19. $result['missed_call'] = $post->GetUserClients($logged_user);
  20. break;
  21. case 'activity':
  22.  
  23. $result['sales_users'] = $user->GetSalesUser();
  24. $result['clients'] = $user->GetUser(['id', 'email'], [], 20);
  25. $result['search_params'] = $request->all();
  26.  
  27. if($request->isMethod('post')) {
  28.  
  29. $result['activity'] = $activity->SearchActivity($result['search_params']);
  30. return view('admin.crm.'.$page_name.'.listing', ['result' => $result]);
  31.  
  32. }
  33.  
  34.  
  35. if($id == NULL)
  36. {
  37. $result['activity'] = Activity::where('user_id', 1)
  38. ->paginate(1);
  39. return view('admin.crm.'.$page_name.'.listing', ['result' => $result]);
  40. }
  41. else
  42. {
  43. $result['activity'] = Activity::find($id);
  44. }
  45.  
  46.  
  47. break;
  48. }
  49.  
  50.  
  51. return view('admin.crm.'.$page_name.'.'.$page_name, ['result' => $result]);
  52.  
  53. }
  54.  


i plik rotues.php:

  1. Route::get('/admin-new/crm/{page_name}/{id?}', 'CrmController@index')
  2. ->name('crm')
  3. ->middleware('auth');
  4. Route::post('/admin-new/crm/{page_name}/{id?}', 'CrmController@index')
  5. ->name('crm')
  6. ->middleware('auth');

r4xz
Faktycznie, nie wygląda to ciekawie. Czemu nie zrobiłeś po prostu kilku wpisów w routingu i kilku metod tak jak markonix pisał?
bialko0019
Masz na myśli coś takiego: ?

Route::match(['get', 'post'], '/admin-new/crm/meeting', 'CrmController@index')->name('crm')->middleware('auth');
Route::match(['get', 'post'], '/admin-new/crm/calls', 'CrmController@index')->name('crm')->middleware('auth');
Route::match(['get', 'post'], '/admin-new/crm/dashboard', 'CrmController@index')->name('crm')->middleware('auth');

zamiast:
Route::match(['get', 'post'], '/admin-new/crm/{page_name}/{id?}', 'CrmController@index')->name('crm')->middleware('auth');

Ale to i tak, w metodzie @index muszę dać switchy albo coś innego, żeby wyświetlić odpowiedni widok i pobrać dane tylko dla danego widoku a nie dla wszystkich.. smile.gif

r4xz
Raczej:
  1. Route::match(['get', 'post'], '/admin-new/crm/meeting', 'CrmController@meeting')->name('crm')->middleware('auth');
  2. Route::match(['get', 'post'], '/admin-new/crm/calls', 'CrmController@calls')->name('crm')->middleware('auth');


Przy okazji do wyszukiwania polecam jednak samo get zasotosować, przynajmniej link można przeklejać itp smile.gif
markonix
Wykorzystaj grupowanie zamiast każdorazowego dodawania middleware do routes i nazwy muszą być unikalne inaczej ich nazywanie nie ma sensu.
Widzę też troszkę "błędów" w konwencji stylów kodów, no i gdzie jest zdefiniowane $logged_user i czemu nie Auth::user() ?
Aby zmniejszyć liczbę routes możesz użyć Resource()
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.