Diskuze: Laravel metódy naprieč celou stránkou
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Člen
Zobrazeno 19 zpráv z 19.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Ja by som na tvojom mieste rozsiril kazdy controller o nejaky zakladny kontroller, napr: BaseController
class WelcomeController extends BaseController {
public function __construct()
{
parent::__construct();
}
...
a potom v samotnom BaseControlleri by som riesil veci co pojdu na kazdu stranku. Samozrejme vsetky controlleri budu musiet byt rozsirene o tento BaseController, aj tvoj EshopController.
Vsak tie "rovnake metody" si daj to konstruktoru BaseControllera, tak sa ti sami zavolaju. Napr:
class BaseController {
public function __construct()
{
$rovnake = new Rovnake();
$this->value = $rovnake->metody();
View::share('value', $this->value);
View::share('title', "Page");
}
WTF su best practices? Prosim, posli mi link.
Zrob jak si shaman radí.
Jednoducho si urobíš nejaký BaseController, z ktorého bude každý tvoj konkrétnejší kontroler dediť, a tak budeš mať opakujúcu sa funkciu (dáta pre header, footer) na jednom mieste. Ak musí v Laraveli kontroler niečo dediť z frameworku, tak to stačí v BaseController-u.
Ako aj to čo píše Shaman je riešienie aj keď sa mi úplne nepáči, pretože čo ak by mal rôzne pätičky a rôzne footre na rôznych stránkach a musel by to šialene dediť. Napríklad chcem typ hlavičky čislo 1 a typ pätičky číslo 3. To by tak jednoducho nevyriešil kvôli viacnásobnej dedičnosti. Aj keď je mi jasné, že vo väčšine prípadov toto problém nebude, iba som chcel poukázať na nedostatok tohto riešenia.
Laravel má na toto vec, ktorá sa volá View Composer, ktorý sa zavolá pri vykresľovaní určitého pohľadu. Môžeš ho teda naviazať priamo na header.blade.php (aspoň dúfam a ak nie tak na všetky view, ktoré ho includujú). Viac info tu https://laravel.com/docs/5.1/views#…, malo by to byť z tade jasné, ak nie poradím viac
https://translate.google.sk/#…
neexistuje jeden link kde by si to mal všetko vypísané
Mego napísal presne čo chce, a shaman-ove riešenie to rieši.
Ak potrebuješ v niektorom z view-ov inú hlavičku, tak si jednoducho prepíšeš v danom kontroleri metódu (v tomto prípade konštruktor), prípadne vygeneruješ extra dáta čo by nahradili tie "defaultné" (kľudne do inej premennej). Chápem že sa snažíš poukázať na univerzálne riešenie.
edit: za čo mám ten mínus a šaman nie?
áno rieši, ale zároveň sa mego pýtal aj na best practices tak preto som odpovedal tým štýlom. Ďalší problém toho riešenia je ak v jednej metóde v controlleru to chceš a v druhej nie. To by si to najprv musel "zrušiť" v konštruktore a následne "aktivovať" v tej metóde a to už by bol duplikovaný kód. A povedal by som, že toto sa bude veľmi často (hlavne v laraveli) stávať. Napríklad metóda create zobrazí formulár a metóda store uloží a presmeruje. V metode create ti to treba ale v store je úplne zbytočne. Čiže zbytočne by sa vykonával kód v tom konštruktore, ktorý pravdepodobne bude pristupovať k databáze. Samozrejme, všetko sa dá vyriešiť ale celé mi to pripadá také "hacky".
Opäť vravím dá sa to aj tak aj tak ale mego sa pýtal na best practise a tou je v laraveli view composer, ktorý bol urobený špeciálne na tieto prípady.
To mínus je preto lebo shaman ponúkol riešenie ale ty si ho už priamo nabádal aby ho použil, navyše mojim komentárom som reagoval aj na shamana, tvoj som si všimol až keď som ho mal dopísaný ... ale neber to prosím nejako zle
problém toho riešenia je ak v jednej metóde v controlleru to chceš a v druhej nie.
Asi viem čo máš na mysli. Napr. že na get request (zobrazenie stránky) sa spúšťa metóda create, a na post request (spracovanie formuláru) sa spúšťa metóda store. Pri post requeste je možno zbytočné v konštruktore vykonávať kód pre získanie dát do hlavičky/pätičky, to dáva zmysel napr. ak sa stránka pri chybe nezobrazuje ale presmeruje (tak ako v tunajšom php tutoriáli, tam sa zobrazí a z $_POST sa predvyplňa do šablóny).
Ono asi záleží aj na návrhu aplikácie. Ten laraverácky view composer nepoznám, bez neho by som vytvoril ten BaseController, ktorý by mohol mať metódu na získanie dát pre hlavičku/pätičku, a všetky metódy kde to treba by si tú metódu volali (1 riadok by sa opakoval, čo už). Stále sa mám čo učiť.
K mínusku: Čím ďalej tým viac si uvedomujem rozdiel medzi "ja by som to urobil tak..." a "urob to tak..." určite to neberiem zle a ani sa nehnevám.
áno presne tak som to myslel
prípadne možno by sa dal použiť trait, čím by vlastne "vložil" tie metódy na získavanie dát pre hlavičku do controlleru, bez použitia dedičnosti. Aj keď tam by bol potom problém s dependency injection, ale ako vravíš, záleží na návrhu
Dalo by sa to rozsirit jednoducho s kontrolou metody
class BaseController {
public function __construct()
{
if ($request->isMethod('get')) {
$rovnake = new Rovnake();
$this->value = $rovnake->metody();
View::share('value', $this->value);
View::share('title', "Page");
}
}
Dalsia moznost je zadefinovat "rovnake metody" v BaseControlleri a potom ich volat len tam kde chces:
class BaseController {
public function __construct()
{
}
public function rovnakeMetody()
{
// tutok nieco zrobit treba spolocne pre header a footer
}
public function ineMetody()
{
// nieco ine pre post requesty
}
}
a potom v EshopControlleri volas:
class EshopController extends BaseController
{
public function index() {
$this->rovnakeMetody();
}
public function store() {
$this->ineMetody();
}
}
Ked tak pozeram View composer, tak to vlastne riesi tiez. Prave ma napadlo, ze spravit middleware na get funkcie je dalsie riesenie. Ako vidime, rieseni je vela a kazde je vhodne pre urcite pripady. Preto nerad pocuvam best practices.
Pre mna hadat sa o best practices je ako hadat sa ze 5x3 = 3 + 3 + 3 + 3 + 3 ale nie 5 + 5 + 5.
MIddleware: Celu tvoju aplikaciu si predstav ako cibulu. Ked uzivatel pride k tvojej cibuli a pyta sa GET /jadrocibule , tak prechadza cez jednotlive vrstvy cibule az pride do stredu, kde je uz tvoj kontroler. Middleware su vsetky tie vrstvy medzi tym ako tvoja aplikacia zacne spracovavat route a tym kym sa spusti tvoj samotny kontroller. Middleware by som prelozil ako software uprostred.
Napriklad samotna authentifikacia je tiez middleware. Pred tym ako sa spusti kontroller, sa musi overit ci dany uzivatel ma spravny token a ci je teda authentifikovany. Middleware mozes pridat aj viac a vzdy sa spustaju v tom poradi ako ich zadefinujes. Dokonca mozes nastavit middleware aby sa vykonal az po cinnosti kontrollera.
Napriklad toto:
Route::get('admin/profile', ['middleware' => 'auth', function () {
//
}]);
kontroller pre admin/profile sa spusti az po tom ako auth zbehne.
Kazdy middleware ma vo vnutri $next, cim vola v poradi dalsiu vrstvu cibule a vracia $response pre dalsie middleware alebo kontroller. Pre tvoj pripad by handle() metoda middlewaru vyzerala asi takto
public function handle($request, Closure $next)
{
if($request->isMethod('get')) {
// zavolaj nejake "rovnake metody"
}
$response = $next($request);
return $response;
}
a tento middleware si zakvacis na vsetky route ktore chces. Ja neviem ci som ti middleware trochu vysvetlil, ale skus sa pozriet na dokumentaciu. https://laravel.com/…2/middleware
Lava odporúčam ti prečítať si celú dokumentáciu, middleware je jedna zo základných súčastí frameworku, v dokumentácii je dokonca v kategórii "The Basics". Očividne máš podstatné nedostatky v znalosti ako funguje framework. Dokumentáciu prečítaš max. za deň a dozvieš sa veľa vecí (samozrejme mimo iného čo je to middleware a čo je to view composer). Navyše to nie je úplne nudné čítanie, je to iné ako čítať dokumentáciu k mobilu, ktorý si dostal.
Stark Roman best practices majú svoj význam a ja som sa snažil poukázať prečo je jedno riešenie lepšie než druhé a teda je "better practice". Keď používaš príklad s číslami tak keď počítam na papiery 25 * 14, tak si čísla napíšem pod seba a vynásobím ich podľa známej techniky a nebudem počítať 25 + 25 + 25 + 25 + 25 + 25 + 25 + 25 + 25 + 25 + 25 + 25 + 25 + 25. Napríklad z tých dvoch riešení čo si napísal je prvé úplna blbosť (prepáč, že to tak napíšem). To druhé sa povedzme dá, ale išlo mu práve o to aby nemusel opakovať stále to isté (a to aj keď by sa jednalo len o jeden riadok).
Mayo, tvoje riesenie je jedno z rieseni. To ci je better practice alebo best practice nebudem rozhodovat, kazdy nech si spravi usudok a rozhodnutie sam. Poukazali sme tu 3 sposoby ako sa da jeho problem riesit. A ked nestaci, tak pridam riesenie cez Eventy. A netlac na nikoho ze ten View Composer je best practice a jedine spravne riesenie, lebo ti dam minusko takisto ako si ho ty dal Matusovi Petrofcikovi.
Tie pocty dvoch cisel je len priklad poukazujuci nad nezmyselnostou hadania sa ktora metoda je lepsia. Dufam ze si nemyslis naozaj ze to pocitam 5 + 5 + 5?
V mojom poslednom komentári som nikde nenapísal čo má použiť. Reagoval som na tvoj komentár kde si vlastne povedal, že akési best practices nemajú význam (nie úplne ale v podstate) a s tým nesúhlasím. Iba som povedal, že všeobecne existujú veci, ktoré sú lepšie a ktoré sú horšie. To, že sa dá niečo urobiť 10 spôsobmi neznamená, že 10 spôsobov je dobrých. Áno je dobré vedieť o 10 spôsoboch ale je aj dobré povedať aké sú ich nedostatky, lebo nie každý to vie sám uvážiť.
Iba tak pomimo ale hodí sa mi k tomuto jeden výrok Juvala Lowyho, ktorý je síce high level softvérový architect, ale to nijako nevadí.
For the beginner architect, there are many options for doing pretty much anything. But for the Master architect, there are only a few [1].
Toto teraz nepíšem nijako osobne (a to hlavne ten citát, v žiadnom prípade sa neoznačujem za toho "master"). Ešte raz zopakujem čo som chcel vyjadriť, lebo niekedy si ľudia domyslia aj to čo som povedať nechcel, netýka sa to teraz tohto vlákna ale všeobecne: Nie všetky riešenie sú na rovnakej úrovni jedno môže byť lepšie jedno horšie. Potom sú riešenia, ktoré sú vo väčšine prípadov lepšie ako druhé a teda má sa význam baviť o best practices.
Dufam ze si nemyslis naozaj ze to pocitam 5 + 5 + 5?
O to mi práve ide, počítaš to ako 5*3, lebo je to lepšie, je to lepšia metóda. Ak sa ma niekto spýta ako násobiť tak mu poviem, že tým klasickým spôsobom, lebo je to "best practise".
[1] zdroj: http://www.oreilly.com/pub/e/3281
Vdaka za link, urcite si to pozriem cez vikend. Ten citat som uz niekde videl a suhlasim s nim. Ale este pred zaciatocnikom architektom je zaciatocnik programator a ten ani nevie ake moznosti ma. Az clovek ktory vie o svojich moznostiach moze premyslat ktora moznost je better alebo best.
s tým súhlasím
inak ak by ťa zaujímalo od neho viac tak má celkom zaujímavé videá o architektúre idesign, ktorú vytvoril https://www.youtube.com/playlist?…
Zobrazeno 19 zpráv z 19.