Laravel Routing - útvonalválasztás (4. rész)

Attila | 2022. 02. 17. 18:45 | Olvasási idő: 2 perc

Címkék: #Laravel #Laravel 5.7 #Laravel 5.8 #Laravel 6 #Laravel 7 #Laravel 8 #MVC #Nézet (View) #Routing

Eddig egy egyszerűsített útvonalon haladtunk az MVC tervezési minta elemei mentén: a felhasználói kérés után a regisztrált útvonalak felől a nézetek felé vettük az irányt (szaggatott vonalú nyíl). Ez azonban a ritkább szituáció, sokkal jellemzőbb, ha az útvonalaktól a vezérlők felé haladunk, mivel a vezérlők hatékonyabban tudnak az üzleti logikáért és az adatbázisban lévő adatokért felelős modellekkel kapcsolatot fenntartani. A vezérlők összeszedik tehát a szükséges adatot és információt, majd azt tovább képesek adni a nézeteknek, ami már megjelenhet a felhasználók böngészőjén.
MVC-with-routes-sajat

Azoknál az útvonalaknál, amelyek a vezérlő felé vezették a felhasználói kérést, rögtön rá kell világítanom egy változásra, ugyanis a régebbi verziókban (v8 előtt) még más volt az útvonal definiálása. Ilyen az útvonal definiálása 7-es verziójú Laravel-ig:

Route::get('/posts/{post}', 'PostsController@show');

És így néz ki a 8-as (és azutáni) Laravel-ben:

Route::get('/posts/{post}',[App\Http\Controllers\PostsController::class, 'show']);

Az útvonal definiálásánál az utasítás első fele megegyezik, itt nincs újdonság. A get metódus 2. paramétere az, ami különböző, de végsősoron ott is mindkét helyen definiálásra kerül a vezérlő osztály neve (PostsController) és utána pedig az az "action" (metódus), amely a vezérlő osztályban van definiálva, tehát mindkét esetben a PostsController osztály show metódusa felé megy majd tovább a felhasználói kérés feldolgozása.

Ha a Laravel verziónknak megfelelően regisztráltuk az útvonalat: természetesen a korábbi verziójú útvonalat törölhetjük, megjegyzésbe tehetjük, de az is elegendő lenne amúgy, ha a mostani újat fentebb helyeznénk el, mint a korábbit, mert a Laravel az először "passzoló" útvonal felé fogja irányítani a kérés kiszolgálását. Ez utóbbit egy példával még úgy illusztrálnám, hogy mi akár egymás után bármennyiszer definiálhatnánk mondjuk a kezdőoldal ("/") útvonalát, a legelső előfordulás szerint történne meg a kezdőoldalt kérő kérés kiszolgálása.

Teszteljük a böngészőnket a következő weblinkkel: http://localhost:8000/posts/my-first-post

Azt a választ kapjuk, hogy a PostsController nem létezik, ami igaz is. Orvosoljuk ezt a hibát!

Két módon tehetjük meg (a második lesz a jobb megoldás):

  1. Manuálisan hozzáadjuk a VSCode-ban a könyvtárstruktúrában a fájlt: itt lesz a helye: app / Http / Controllers → ha ezt megtesszük és frissítjük utána a böngészőt, akkor már nem a PostsController-t fogja hiányolni, hanem a benne (elvártan) ott lévő show action metódust. Ha beleírjuk a show metódust és visszatérünk egy sima "hello" kiíratással, akkor már működni is fog az oldalunk a böngészőben. Kicsit felturbózhatjuk a show metódus magját az előző blogbejegyzésekben összeállított logikával is és az is működni fog, de térjünk inkább rá a második Controller létrehozási módra, mert az lesz a jobb megoldás...
  2. Ha az első módszert megcsináltuk, akkor most töröljük azt a fájlt. Nyissunk egy terminált és írjuk be: php artisan. Itt láthatunk rengeteg parancsot, nekünk most a make szekcióra és azon belül is a Controller létrehozásra lesz szükségünk.

php artisan make:controller PostsController

public function show()
{
  return "my post";
}

Helyezzük el ezt a show metódust a PostsController osztályban.

Tipp:  figyeljünk a névkonvencióra, mert nem véletlenül lett ez a neve. Használjuk az első részt így, nagy kezdőbetűvel, valamint angolosan többes számban (s betű a végén), utána pedig következzen mindig a "Controller" szó.

Miért is állítottam, hogy a második volt a jobb megoldás?

Azért, mert így nem csak egy üres fájl jött létre a manuálisan kikeresett mappaszerkezetben, hanem egy olyan Controller fájl, amelyben a szükséges részek (php nyitó tag, névtér definiálás, importálás, osztálynév deklaráció és ősosztály meghatározás) is benne vannak.

Ha ezt végrehajtuk, akkor tehát létre is jön a Controller-ünk és a show metódus, valamint annak magjának hozzáadásával már működik is a webalkalmazásunk.

További információ: a php artisan parancs kiadásával terjedelmes listát kapunk a kiadható parancsokról, amelyekhez van egy-egy rövid leírás, de ha valamelyik parancsról több információt, paraméterezési beállítást szeretnénk megtudni, akkor mindig használhatjuk a -help kapcsolót. Ha például a Controller-ek létrehozásáról szeretnénk további információt megtudni, akkor adjuk ki ezt a parancsot:

php artisan -help make:controller

Na de mi a helyzet az adattovábbítással, amikor ezt az utat járja be a felhasználói kérés kiszolgálása?

Az útvonal módosításra nincs szükség, de a show metódust módosítsuk a PostsController osztályban így:

public function show($post)
{
  return $post;
}

Majd teszteljük újra a korábban is lekért weblink segítségével. Megjelenik a $post változó, ugye? Milyen király már ez? A show metódus paramétere lett gyakorlatilag az útvonalnál definiált wildcard érték ( {post} ). Innentől persze már akár újra átadhatnánk ezt a $post változót a nézetünknek és úgy jelenítenénk meg, ahogy szeretnénk... gyakorlásképpen meg is tehetitek ezt.

Ha nem menne, akkor itt mutatom a kódját és egyúttal megismerkedünk egy újabb Laravel-es segédmetódussal is, ez a compact() névre hallgat. Akkor nagyon hasznos, ha ugyanazzal a névvel szeretnénk átadni a nézetnek a változót, mint ahogy azt létrehoztuk, vagy megkaptuk paraméterként. Maradjon ez az egyetlen utasítás a show metódus magjában:

return view('post', compact('post'));

Tesztelés után így néz ki most a weboldalunk:

Így pedig már az útvonaltól eljutott az adat a Controller megfelelő action-jéhez (metódusához), majd ezen keresztül a megfelelő nézetnek is. "How cool is that?"