Parametry pre action – pouzivanie a validacia
- westrem
- Člen | 398
Zdravim,
mam snahu spravit si vlastnu validaciu vstupnych parametrov pre rozne actions a
views a to pomocou anotacii.
Kym sa do samotnej implementacii ale pustim rad by som si ujasnil ako Nette
vlastne naraba s parametrami a to jednak s tymi uvedenimi ako argumenty pri
napr action
a persistentnymi.
Aby vsak nedochadzal k omylom, nastudovane mam v podstate vsetko co som vedel dohladat na strankach Nette, primarne teda dokumentaciu k Presenteru
Ide mi skor o odkazy priamo do kodu na API, kde sa deje nacitavanie jednak
persistentnych parametrov (to ak sa nemylim sa deje pomocou
loadState()
?) a druhorak o $_GET
a $_POST
parametry. Kde si ich Nette taha a pracuje s nimi? Nemozem sa k tomu miestu
v kode dopatrat.
Tiez mi nie je jasne, ako Nette vie urcit nasledovne: majme tuto action:
Dalej majme generovanie linku:
Vie mi niekto povedat, kde konkretne v kode dochadza k rozpoznaniu, ze
$limit
je nepovinny a k spravnemu napasovaniu uvedenych a neuvedenych parametrov? Stale
v tom citim urcitu magiu.
Dalej, rozmyslal som kam vobec umiestnit samotnu validaciu parametrov, a
jedine miesto, ktore ma napada a malo by byt aj z hladiska navrhu spravne je
startup
funkcia od BasePresenter
. Alebo mate
lepsi navrh?
PS: Ak by to bolo mozne, mohli by ste linkovat na API k verzii 0.9.x a nie k najnovsej 2. verzii.
PS2: Rad by som sa vyhol offtopic prispevkom ohladne validacie, ci ju robit az v modeli, ci vobec validovat alebo ju robit uz takto low-level na parametroch, to je v konecnom dosledku vec programatora a ja osobne preferujem v tomto pripade low-level uz na urovni parametrov a nie na urovni modelu.
Vopred dakujem za akekolvek nasmerovanie a hinty.
- westrem
- Člen | 398
Tak nakoniec sa mi podarilo najst pre mna dolezite miesta v kode a vysledok je podla mna hodne silna validacia vstupnych parametrov.
Co sa validuje
- persistentne parametry
- parametry akcie/render metody
V oboch pripade sa validuje ci uz uvedena hodnota v URL alebo defaultne
uvedena hodnota v zdrojaku. V pripade, ze sa validacia nepodari vyhodi sa
Exception, takze v ErrorPresenter si ju mozete
odchytit a podla nej nastavit napr nejaky pekny View s chybovou hlaskou.
Zapis
Validacne pravidla sa zapisuju anotaciami nasledovnym
stylom: @validate($var, callback [, $arg, $arg ..])
Ich umiestnenie je mozne bud pred metodou actionXY
alebo
renderXY
. Ak vsak existuju obe musia byt anotacie
uvedene pred metodou actionXY
.
Priklad:
Vyssie uvedene znamene presne to by ste si mysleli:
$id
musi byt cislo vecsie rovne ako 6$color
moze byt jedna z hodnot ‚red‘, ‚green‘, ‚blue‘$render
moze byt prazdny (nadobudat prazdnu hodnotu – na jej detekovanie sa nepouzivaempty
ale sofistikovanejsi sposob)
Specialitka
Neviem nakolko kto vyuziva persistentne parametre, ja som sa vsak obcas
dostal do situacie, ked som mal v presentere jeden persistentny parameter
$id
, ktory vsak sluzil roznym actions a vzdy na
tak trochu iny ucel (mohol nadobudat rozne typy hodnot).
Validacia pamata aj na tuto situaciu a je mozne nieco nasledovne:
Kesovanie
Aby sa urychlila validacia, resp spracovavanie anotacii, su tieto spracovane iba raz a potom su kesovane. Kes je nastavena tak, aby sa invalidovala pri kazdej zmene .php subory, ktory obsahuje definiciu presenteru.
Implementacia
Pouzitie
Danu funkciu si mozete dat napr do BasePresenteru
a volat ju pri
startup
metode takto:
Known issues
Pri implementovani ma zarazilo par veci, ktore Nette robi a jedna z nich sa mi nepodarila obist (bol by nutny zasah do FW). Ide o to, ze ak persistentnemu parametru nastavite nejaku default hodnotu napr:
Nette si zapameta, ze dany parameter bol typu integer
a
automaticky potom nastavuje tento typ akejkolvek hodnote parametru cim
znemoznuje pouzitie roznorodych validacii pre persistentny parameter ako je to
uvedene v sekcii „Specialitka“
Zaverom
V uvedenej implementacii je pouzitych vela mojich internych classes, nemal
som vsak tendenciu to z ukazkoveho kodu mazat – sluzi to aspon k tomu aby
ludia popustili uzdu fantazie a videli co vsetko je mozne docielit.
Taky zapis <=, 30
je podla mna ovela citatelnejsi ako
someNumberComparingFunction, <=, 30
.
Cely priklad ma preto posluzit najme ako zakladna kostra implementacie a miesto jej vyuzitia v Nette, kazdy si ju moze upravit a zmenit ako uzna za vhodne.
Dalej uz nejaku dobu premyslam, ze zverejnim niektore svoje validacne a helper classy a tym padom by mohla komunita pouzivat aj vyssie uvedene zapisy – toto vsak moze a nemusi nastat, zavysi ci budem mat cas na prepisanie danych tried do navonok konzsistentne pouzitelneho packagu.