Odlično, sedaj, ko sem create "vrgel" ven iz resource z except, pa deluje :) Očitno da Laravel prednost resource (v tem primeru ne bere od vrha navzdol v routes.php) in če ima določen Controller tega definiranega, bo najprej pogledal za Action (KrnekiController@create) znotraj resource, dobil URI (krneki/create) in ker ni definiranega {parametra}, kreiral "napačen" url - krneki?id=97, če si prav to razlagam... Sedaj, ko sem to odstranil, pa pravilno pogleda v Route::get('krneki/create/{id}', 'CategoriesController@create'); in seveda generilia pravilen url krneki/97. Super, hvala ti za pomoč :)

Ali si mogoče že v prvo preveril z resource() in ti deluje? :/

(uporabljam Laravel 5.1)

Deluje, če nimam zapisano resource, ampak routes definiram sam.

Recimo, če zapišem

Route::get('kr_neki/create/{id}', 'KrNekiController@create');

Route::resource('kr_neki', 'KrNekiController');

Ne deluje

Če zapišem

Route::get('kr_neki/create/{id}', 'KrNekiController@create');

Route::get('kr_neki/{id}', 'KrNekiController@show');

Route::get('kr_neki/{id}'', 'KrNekiController@destroy');

....

pa deluje :/

Ampak mi je malo mimo, da bi moral zdaj ročno zapisati vse routes samo zato, ker bi rad v create vključil parameter :/

Po moje v prvem primeru ne bi smelo biti težav, ker je Route::get('krneki/create/{id}', 'KrNekiController@create') zapisan nad Route::resource(...) ampak ga očitno ne prepiše. Lahko preveriš, če se tebi zgodi podobno (1. primer -- pod Route::get('krneki/create/{id}', 'KrNekiController@create'); zapišeš še Rote::resource(...))? 2x sem preveril imena in sem vse prav zapisalo tako da mi ni jasno v čem je težava.

Laravel "helper function" action() ne generirala pravilnega url-ja v primeru create metode.

Zapisano imam na primer

action('KrnekiController@create', [0])

Generira se url...

url_pot?0

Seveda bi lahko zapisal

action('KrnekiController@create', ['id' => 0])

in bi se generiral url...

url_pot?id=0

ampak ni to to. Želim, da se generira takšen url kot ga action() genrira pri vseh ostalih privzetih "resource" metodah s parametri ali pri custom metodah. Vedno se generira pravilni url (url_pot/0) le pri tej privzeti besedi "create" me zajebava.

V routes.php sem definiral pravilni route

Route::get('kr_neki/create/{id}', 'KrnekiController@create');

Route::resource('kr_neki', 'CategoriesController');

Če ne bom našel nobene druge rešitve, pač ne bom uporabil action() ampak bom v *.blade.php ročno zapisal celoten url in potem lepo delujem ampak je potem to spet tako tako, če se kasneje odločim spremeniti url v routes.php moram potem pot spremeniti tudi v blade (lahko bi pa tudi metodo preimenoval in potem deluje ampak to spet ni to).

Id v create metodi nujno potrebujem, ne vem, kako je sicer to v skladu z dobro prakso ampak ga potrebujem.

Seveda, jaz sem v oklepaju primerjal parentid z id query-ja v oklepaju in ker jasno v tabeli nikjer ni parentid = id, mi je je za vse count-e zapisalo 0. Lahk bi vedel, da ne gre za isti id :) Hvala Vini za pomoč, sedaj, jasno, deluje tako kot sem želel.

Imam spodnjo tabelo

Recimo, da želim izpisati vse vnose s parentid = 0 ampak ob pogoju, da mi še izpiše seštevek kolikokrat se id posameznega vnosa ponovi še v parentid. Upam, da sem razumljivo vprašal.

Zapisal sem query...

SELECT id, (SELECT COUNT(*) FROM categories WHERE parent_id = id) FROM categories WHERE parent_id = 0

ki mi vrne

kar pa ni pravilno, ker bi moralo pri id=3 biti zapisano 2

Recimo, če za test zapišem

SELECT id, (SELECT COUNT(*) FROM categories WHERE **parent_id = 3**) FROM categories WHERE parent_id = 0

count query deluje pravilno

Kakšna ideja, kaj počnem narobe, da mi ne zazna pravilnega id-ja?

Še ena opazka glede PATCH...

Just as a side note, PATCH is not yet a standard. I've encountered an issue where one customer's firewall/proxy/cache/whatever is turning our front end's PATCH into METHOD_OTHER (this is according to Bugsnag) before it reaches our API, which Laravel then cannot route.

Unless you know for certain, PUT is safer, and it might be best to put a header/flag in the request to say that a partial update. It's not ideal, but hopefully things will improve soon!

Očitno bom raje uporabljal kar PUT...

Tisti, ki programirate v Laravel, katero metodo uporabljate za update? PUT ali PATCH, me čisto informativno zanima.

bostjan:

Točno to kar ti je spicey napisal si zamešal. PUT in PATCH nista noben POST, ampak PUT IN PATCH. POST se naredi samo zato ker brskalniki ne podpirajo patch in put in se potem s hidden elementom naredi fake metoda.

Kako ti pa potem zadeve v ozadju dela......to je pa stvar tebe. Načeloma ti lahko podatke urejaš na get in na put brišeš. Lahko nove kreiraš z DELETE, ..... To je stvar programerja ki ureja.

Se pravi kako narediš put in patch je tvoja stvar. Razliko kako NAJ BI bilo ti je pa vini napisal.

Ja saj to sem zgoraj napisal kot odgovor spicey ;) Metodo PUT/PATCH/DELETE pač "fejkamo" preko POST s hidden input, ker teh metod brskalnik ne pozna potem pa preko vrednosti za _metod (vidimo za katero "fake" metodo gre) naredimo kar želimo (generiramo SQL za UPDATE, DELETE... ). To je meni jasno. Malo sem bil v dvomim kakšna je točno razlika med PUT in PATCH, to je vini v principu pojasnil AMPAK očitno se tega pri Laravel ne držijo (me čisto informativno zamina)?

Sem zdajle dumpal query v primeru za PUT in v primeru za PATCH. V obeh primeri se v Laravel generira enak query... Recimo, če spremenim ime (input name, ostali inputi ostanejo enaki)...

pri PATCH...

string'update categories set name = ?, updated_at = ? where id = ?' (length=67)

pri PUT se generira query

string'update categories set name = ?, updated_at = ? where id = ?' (length=67)

Query-a sta identična torej je pri Laravel čisto vseeno ali uporabiš PUT ali PATCH, ker se očitno ne držijo tega, kar je zapisal Vini?

spicey:

When should we use the PATCH HTTP method?

The HTTP methods PATCH can be used to update partial resources. For instance, when you only need to update one field of the resource, PUTting a complete resource representation might be cumbersome and utilizes more bandwidth

• See more at: http://restcookbook.com/HTTP%20Methods/patch/#sthash.5NNILvjJ.dpuf
  

Malo si preberi o REST-u, pa boš bolje razumel. (ker mi, glede na tvoje vprašanje, deluje, da gledaš ti na to s stališča PHP-ja oz Laravela, ne pa HTTP metode)

Ne gledam iz stališča Laravela. Mi je jasno, da gre tu za HTTP request v originalu s POST metodo ter hidden input z metodo PUT, PATCH (pač za spremembo resource) in da lahko tak način implemnentiraš vsepovsod... Laravel sem omenil, ker me zanima, kako je rešeno tukaj + smisel dveh metod.

Vini:

Glavna razlika je v tem, da je PUT namenjen zamenjavi celotnega resourca, PATCH pa se uporablja za modifikacijo obstoječega. Če v obeh primerih podaš vse lastnosti resourca, potem razlike efektivno res ni. Je pa vprašanje, če Laravel res upošteva tole ali ne, ga ne poznam. Poskusi narediti PUT s kakšnim manjkajočim propertyjem resourca, načeloma bi ti moral manjkajočega v resourcu izpraznit.

Približno tako sem si tudi sam vse skupaj razlagal in sem že prej naredil test tako, da en input ni bil določen (file) in pri PUT bi mi verjetno moralo potem to polje v bazi "izprazniti" ampak mi ga ne in ostane nespremenjeno.

Recimo, da imam (dumpal sem request, enkrat za PATCH, drugič za PUT)...

Pa recimo, da sem spremenil samo vrednost "name".

V 1. primeru (PATCH) mi potem updata samo polje "name"?

V 2. primeru (PUT) pa bi mi moralo v bazi updatat name, url (+polje img, ki ga nisem spreminjal - v inputu nisem dodal nove slike zato te vrednosti v requestu ni - ampak mi ga ne, polje img v bazi ostane nespremenjeno)?

Sicer pa ne vidim potem nekega velikega smisla v PUT metodi, če pa lahko vedno uporabim PATCH in je to to? Ali v katerem primeru bi potem sploh prišla prav PUT metoda?

(* da ne bo kdo zmeden zakaj je v polju zapisano 6, dve vrednosti sem z grafičnim programom odstranil :D jasno, med njimi ni bilo img, ker je polje ne vsebuje, ker ni določena)

Pri Laravel lahko za update izberem metodo PUT ali PATCH in mi ni jasno, v čem je razlika? Načeloma uporabljam PATCH ampak če za metodo izberem PUT, update-anje še vedno deluje brez težav in mi ni jasno v čem je sploh razlika?