Laravel: molio bih malo objašnjenje (get(), get('key') )

dmitrecic · rujan 2018 15:58 26

Molio bih Laravel majstore za malo objašnjenje (ili upute):
Kako do jednog rezultata iz query-a?
Recimo:

NekaKlasa::where(‘id’,’=’,$id);
query vraća jedan row sa poljima: ‘naslov’, ‘opis’, ‘jezik’
Kako do vrijednosti u polju ‘opis’?
collect([‘naslov’=>‘Neki naslov’, ‘opis’=>‘Neki opis’, ‘jezik’=>‘Neki jezik’])
Kako do vrijednosti u polju ‘opis’?

Uspijem to napraviti, ali nikako mi nije kristalno jasno koja metoda se koristi u kojem slučaju. Pa mi treba pojašnjenje.
(smotan sam, a kaj sad…)

ivanm · rujan 2018 07:07 27

Ne radim sa Laravelom, ali nije mi bas jasno pitanje.

Što točno vrati, kako izgleda dataset koji dobiješ, object, array?
ako je objekt opis dohvatis sa $object->opis; u slucaju arraya $arr[‘opis’]

Najbolje da napišeš što ti ispiše var_dump

dmitrecic · rujan 2018 07:41 27

Odgovorio si mi savršeno, sad mi je kristalno jasno (ne šalim se)
Nije mi bilo jasno jer u jednom slučaju podatke dohvaćam s ->get() i funkcionira, dok u drugom slučaju ista metoda ne funkcionira, već moram koristiti ->get(‘key’). I nije mi bilo jasno zašto i u čemu je problem. Nakon pokušaja/pogrešaka uspijem dobiti rezultat, ali to nije ono što želim.
I ti mi kristaliziraš situaciju - objekt/array je razlika u datasetu (novi sam u OOP pa nisam niti uzimao u obzir da to mogao biti razlog)
Hvala!

ognjen · rujan 2018 09:08 27

Where vrati objekt tipa Illuminate\Database\Eloquent\Builder koji ima metodu get, ta get motoda vrati objekt tipa Illuminate\Database\Eloquent\Collection koji opet ima metodu get

dmitrecic · rujan 2018 09:22 27

Sve 5, postalo mi jasno čim je @ivanm spomenuo objekte i array-e u dobivenom datasetu

tpojka · rujan 2018 11:27 27

@ognjen ti je ilustrov’o dobro.

get() koristiš da dohvatiš set upisa

$posts = Post::where(['status' => active])->get();// moguće 0 ili više vraćenih rezultata

Najčešće ćeš provjeravari da li ima ijedan vraćen rezultat sa

if ($posts->isEmpty()) {/*case*/}
// ili
if ($posts->isNotEmpty()) {/*case*/}

Docs.

Kako get(array $columns = ['*']) po default-u vraća sva polja iz tabele, možeš obezbijediti ključeve ali u praksi je mnogo češće ubaciti select('field1', 'field2', 'field3')

$posts = Post::select('id', 'title', 'created_at')->where(['status' => active])->get();

Tako da get() vraća collection.
Kada imaš potrebu za jednim rezultatom, tipa determinišeš po id primary, (iako će get da vrati eventualan rezultat) trebalo bi koristiti find(), first(), findOrFail() ili firstOrFail(). U tom slučaju je vraćen eloquent model’s object (ili automatski 404 response object ako se koriste *OrFail()) i preporuka je da se koristi baš tako jer otvara mogućnosti za iskorištavanje punog eloquent potencijala (kad treba da se radi sync() sa relevantnim relacijama itsl.)
Napomena da find() može primiti i niz primarnih ključeva pa tako vratiti kolekcije ([prazan] niz):

$flights = App\Flight::find([1, 2, 3]);

Kad treba ispitati da li je model vraćen, koristi se prost upit o postojanju:

//$post = Post::where(['id' => 5])->first();
$user = User::where(['deleted_at' => null])->first();
if (!$user) {
    // code
}

dmitrecic · rujan 2018 13:55 27

find() koristim kada imam primarni ključ, primjer sa ‘id’ sam stavio primjera radi (ok, primjer sam trebao drugačije sročiti, bitno da ste shvatili za što sam trebao objašnjenje ). Čitam dokumentaciju i odmah radim na (svom) projektiću da kroz praksu naučim. Bitno da shvatim kako funkcionira i da pravilno naučim koristiti framework. Za sada jedino nisam siguran kada koristiti middleware, pa sam sebi u projektu iskoristio middleware za postavljanje jezika (locale) na kojem će se front-end prikazivati. Mogao sam i kroz view, međutim kroz middleware mi se činilo prikladnije?

ognjen · rujan 2018 08:48 28

Neznam jel prikladnije koristi middleware, no i ja sam ga koristio za multilanguage.
Subdoemna je odredjivala jezik, npr:
example.com => engleski
en.example.com => engleski
de.example.com => njemacki
…
dev.example.com => development engleski
dev.en.example.com => development engleski
dev.de.example.com => development njemacki

Ovo bijase middleware i posluzilo je OK:

<?php namespace App\Http\Middleware;

use Closure;
use App;

class LngSubMiddleware {

	/**
	 * Handle an incoming request.
	 *
	 * @param  \Illuminate\Http\Request  $request
	 * @param  \Closure  $next
	 * @return mixed
	 */
	public function handle($request, Closure $next)
	{
		$chunks = explode('.', $request->server('HTTP_HOST'));
		
		if ($chunks[0] == 'dev')
		{
			array_shift($chunks);
		}

		if (in_array($chunks[0], config('app.available_languages')))
		{
			App::setLocale($chunks[0]);
		}
		
		return $next($request);
	}

}

dmitrecic · rujan 2018 09:53 28

Ja koristim naziv drzave koji određuje jezik
npr:
example.com/croatia = engleski
example.com/kroatien = njemački
example.com/hrvatska = hrvatski
itd…
A u middleware uzmem Request::segment(1) i usporedim s varijablom u lang datoteci i dohvatim i postavim jezik. U principu je isto, samo imam više prostora da nazovem link u url-u kako želim

jorgovan · rujan 2018 19:46 28

Ja radim na slijedeci nacin:

Npr. ako imam
www.nesto.xy/hr/o-nama
www.nesto.xy/en/about-us

Rute drzim u bazi i dinamicki radim routing.

Ova obadva linka gledaju na controller About, metodu index.

Ruta mi izgleda :any/ruta = about

Provjerim iz baze da li mi je jezik na listi dozvoljenih.

Linkove na svakom pageu generiram dinamicki, imam library kojem predam npr. (About,index)
i ovisno koji je jezim odabran kreira mi link npr.
hr/o-nama.

Doduse radim u codeigniteru,vidio sam da ovo symfony ima jako dobro rijeseno.

dmitrecic · rujan 2018 21:27 28

Da, dinamičke urlove kreiram nazivima iz baze (u mom slučaju slug imena gradova) i po id-ovima članaka (oglasa). Pa mi linkovi izgledaju poput
example.com/croatia/cakovec/23.html
nije problem, to sam vrlo brzo savladao.

Ali što me stvarno razveselilo danas u Laravelu je - pagination. Gotov u 15 sekundi, nemreš vjerovat - fantastično!
Kad se naviknem na rad (i na kvalitetno kodiranje metoda, da nemam više od 10 linija koda po metodi, što još muku mučim ali ide) - ima da me nema!

ivanm · listopad 2018 08:17 1

Nemoj se slijepo držati pravila < 10 linija koda po metodi, lijepo je imati kratke metode koje rade samo određenu stvar, ali viđao sam i slučajeve kada se ovo forsira na kraju se jedna metoda razlomi na 3 bez realne potrebe samo kako bi se ispoštovao neki broj (ništa posebno se ne dobije u čitljivosti koda na kraju).

Prouči malo PHP Unit ako imaš vremena, unit testovi te jednostavno natjeraju da pišeš kvalitetniji kod, pravilo je jednostavno, ako je prekomplicirano napisati unit test za neku metodu, nešto u njoj smrdi i treba pogledati kako refaktorirati.
https://phpunit.de/

dmitrecic · listopad 2018 08:48 1

Hvala, pogledat ću i isprobati. Refactoring radim kada primjetim da može bolje i čitljivije. Ovo sa 10 linija max također ne uzimam kao obavezu, već kao “konstantu” oko koje se treba ravnati. U prosjeku (gledajući metode u klasi) trebao bih imati max 5 linija koda po metodi da mogu reći da ispravno pišem kod (i naravno da je u skladu s PSR standardima).

bozoou · listopad 2018 10:16 1

Zašto ne spomenuti u ovom kontekstu i DRY pristup. Osobno mislim da je to najlogičniji razlog koji u praksi ograničava veličinu neke metode…poštivajući DRY metode će upravo biti tako oko 10 linija koda…no to ne znači da neke metode neće biti samo jedna linija koda…isto kao što će neke biti 20 linija.

Što se same preglednosti tiče, ona automatski dolazi iz DRY pristupa …i iz pravilnog i jasnog naziva metode. Već tu nije bitno što je točno unutar metode, ako je jasna prijenosna funkcija metode…ili ti odnos inputa i outputa…kojeg tumaci ime metode. Zadržavajući te vanjske okvire istima, body metode smije konstantno evoluirati i nece biti problema. Tako da sa pravim postavljanjem tih vanjskih okvira, sam body metode ponekada mozemo i zbrljaviti u pocetku…a kasnije ga lako nadogradimo da pokrijemo sve iznimke na koje u startu nismo racunali. Ili da napisemo optimiziraniji kode…ili sto vec.

A sada ako neka metoda ne krsi DRY iako je malo duža…bože moj, nikakvog zla. Veće je možda zlo ju cjepkati na djelove koji se ne rejusaju naokolo. To ne pridonosi preglednosti…i u najboljem slučaju se svodi da smo ulagali dodatni trud da bi postigli efekt collapse/uncollapse sto svaki editor omogućava. A lakse je napraviti collapse/uncollapse nekog bloka unutar metode, nego ga traziti naokolo po skriptama gdje je definiran. Iako moderni editori omogucavaju i to…direktan skok na body metode s mjesta gdje se poziva. Pa ajde…to je onda izjednaceno kao collapse/uncollapse.
Svakako, kada se ima osjećaj da će se nesto kasnije rejusati…onda je jednostavnije u startu pakirati u zasebnu metodu.

Stoga, ja smatram da je poštivanje DRY pristupa Bog i batina…koja će automatski posložiti i prosječne dužine metoda i time preglednost. No na prvom mjestu će napraviti code lako održivim i manje bugovitim.

Ti kada si zamjenio mysql_escape sa svojom metodom koja ce raditi isto…upravo si napravio to da si uveo DRY pristup na razinu same sintakse jezika…jer se vise nisi usudio ponavljati na vise mjesta ni originalnu sintaksu.
Tako upravo programski jezici evoluiraju…jer (bubam primjer) nekada davno netko nije htio ponavljati iste blokove koda u assemblyu da dobije foreach ponasanje…pa je izmislio način da ima foreach metodu a da ne krsi DRY.
Danas bi za tebe bilo nosense da ne vjeruješ php-u u konzistentnost da ce zadrzati foreach, pa da warpas njegov foreach unutar svoje foreach metode koju ces rejusati.
…ali te opet mysql_escape izdao. Tanka je granica. No nedvojbeno pokazuje moć DRY pristupa.

dmitrecic · listopad 2018 10:42 1

Eto, pa ja sad neka odlučim hoću li cjepkati metode koje se koriste (zapravo) samo jednom, ili ih zadržati unutar metode… Osobno mi to ima logike i tako sam počeo (jer ima smisla, skraćuje pisanje koda i lako je pratiti kod), međutim kada prijeđe u naviku kao primjerice i formatiranje poput:
If (nesto)
{
Nesto
}

i

If(nesto){
Nesto
}
pa uletiš u tim pa ti spočitavaju da “to tako nije ispravno”…

bozoou · listopad 2018 11:29 1

Kada mi netko spočitava da nesto nije dobro…a ne zna objasniti bitnu logiku iza njegovog pristupa…smatram da taj nije shvatio bit i ljepotu programiranja.
Programiranje će vječno evoluirati…i nema ultimativnog ispravnog. Poanta je olaksati posao…uciniti ga brzim procesom…odrzivim i skalabilnim.
Istina, tu neki standardi dobro dođu da olakšaju timsko funkcioniranje…ali isto tako će svi ti standardi koji su tu samo radi toga…biti pregaženi.
Recimo, u budućnosti ćemo 100% programirati tako da ćemo razgovarati sa računalom gdje će on sam prepoznavati ponavljajuće metode i refraktorirati ih na način da se održi DRY …i tko će te tu pitati kako se formatiraju viticaste zagrade kada ih nece ni bit u takvom obliku kreiranja koda. Tako da, neki igrači slobodno mogu gaziti standarde…ako pritome uvode dobre novitete…koji će postati novi standardi. Ili barem pokusavaju biti inovativni. Da su svi oduvijek mislili jednako…nista nebi napredivalo. I danas bi asembly bio standard.

A što se tiče vitičastih, ne trebamo čekati ni govorno programiranje…već danas neki editori idu u smjeru da preformatiraju tabove i viticaste u stil koji odgovara onom tko programira. Doduse, to se tek pojavilo i trenutno je jako lose.
No vec takva inovativnost rjesava problem razlicitih formatiranja viticastih

Btw. Zamislite kada ce se govorom moci isprogramirati samo najosnovnije sintakse…pa kada djeca počmu pričati sa računalima i govorom počmu raditi na napretku tog govornog parsera? To ide zasigurno u točku gdje se neće moći razlikovati svijest toga parsera od ljudske…jer je funkcija jako eksponencijalna. Kao što je eksponencijalan i razvoj asemblya koji je također alat pomoću kojeg se razvija taj isti alat. Sve što vidimo i koristimo su nadograđene metode koje postoje na tim najprimitivnijim razinama programiranja.
Budućnost će biti zanimljiva, isprika na malom offtopicu

bozoou · listopad 2018 11:44 1

P.S. U govoru, svaka riječ je metoda. Isto tako je svaka rečenica metoda koja se sastoji od pod metoda, ili ti riječi.
Tako da općeniti razvoj programiranja i kreiranje svih tih metoda…niti nije ništa drugo nego djelovanje naših riječi kroz strojno/mehaničko tijelo.
Eksuali, nase tijelo evoluira u strojno…kako bi naš unutarnji program mogao doći do izražaja na što jednostavniji način kroz strojno tijelo. Danas to radimo tipkajuci kod, sutra govorom…a prekosutra cemo izravno misliti unutar strojeva, zaobilazeći i govor.
Ništa drugo se ne dešava upravo sada unutar nas…to je repetativni proces koji prožima sve faze evolucije. Čak i biblija kaže, ako se ne varam: “na početku bijaše riječ”
Naravno, ova riječ koja nas prožima, je također evoluirani oblik nekakve vrste sloga…koji prožima sve i egzistira na vrhu hijerarhije
Sry, ako odeh predaleko…pogotovo sto sam preskocio puno bitnih stvari koje prvo treba razumjeti…pa ovo vjerovatno zvuci kao cisti SF.

dmitrecic · listopad 2018 12:06 1

Bavim se programiranjem (svega i svačega) od svoje 12-e godine (što će reći - oko 30 godina, s prekidima). Znam o čemu govoriš i što želiš reći kroz filozofski pogled na materiju
Međutim, nikada nisam radio u timu, pa mi je sada bitno da naučim OOP - ispravno. Međutim, uvijek mogu primijeniti ovaj tvoj odgovor kao - odgovor

belmin · listopad 2018 12:46 1

Malo off: Jesi poceo vec aplicirati na oglase za poslove vani ?

tpojka · listopad 2018 13:22 1

Uvijek cijepaj methode dok god je smisleno. Za mene ovakav kod ima smsla i čitljiviji je x puta nego da strpam sve linije što hvataju ove dvije varijable u taj metod.

/**
 * @return int
 * @throws Exception
 */
public function calculateVar1AndVar2()
{
    try {
        $neededVar1 = $this->privateMethodThatReturnsVar1(); // can be anything from DB i.e. (?)
        $neededVar2 = $this->privateMethod2ThatReturnsVar2(); // can be anything from API i.e. (?)
        // making something with vars and set return
        $resultFromVarsMakeover = $neededVar1 + $neededVar2;

        return $resultFromVarsMakeover;
    } catch (\Exception $e) {
        throw $e;// or whatever needed here (log maybe?)
    }
}

/**
 * Gets DB table count
 * @return int
 */
private function privateMethodThatReturnsVar1()
{
    return 1;
}

/**
 * Gets Api items count
 * @return int
 */
private function privateMethodThatReturnsVar2()
{
    return 2;
}