Validace parametrů v presenterech

Je to moc hezké, přidám tedy nějaké vlastní nápady:

Parametry typu array

Pokud je parametr typu array, někdy by se hodilo specifikovat i typ prvků v poli. Např. nějaké array $ids by mělo zřejmě být pole integerů. Jsem si velmi dobře vědom, že PHPdoc na tohle nemá specifikaci, což znamená, že bychom museli nějakou vhodnou syntaxi zvolit. Nejvhodnější mi připadá tato syntaxe:

/** @param array<int> */

Druhou možností je zápis ala C#:

/** @param int[] */

Parametry typu objekt

Někdy se hodí parametry typu objekt. Základem je onen zmiňovaný DateTime, ale napadá mě mnohem lepší příklad. Zejména uživatelům Doctrine 2 by se mohlo hodit předávat jako parametr přímo entitu. Typicky když máte $id tak k čemu vám je? Přece k tomu, abyste z modelu vytáhli daný záznam, ale samotné $id jinak vůbec nepotřebujete. Nebylo by ideální použít to takhle?

/**
 * @param ArticleEntity
 */
public function actionEdit(ArticleEntity $entity) {
	//nemusím volat obvyklé $this->getEm()->getRepository('ArticleEntity')->find($id);
	//ani testovat zda záznam skutečně byl nalezen a vyhazovat výjimku
	//práce s formulářem
}

Pokud entita s daným ID neexistuje, vyhodí se BadRequestException a action se ani nespustí. Může se spolehnout, že uživatel si skutečně řekl o existující článek a že nechtěl neexistující článek –157 nebo 36724.

Jak to tedy řešit? Samozřejmě objekty nemůžeme přímo předávat jako parametr. Můžeme ale mít mechanismus, který objekt dané třídy bude převádět na primitivní typ ($entity → $id, použije se když $entity předáte v šabloně jako parametr {link}) a samozřejmě onen primitivní typ zpět na objekt ($id → $entity, použije se v Presenteru před voláním actionXyz).

DateTime by se tedy převáděl na string podobu ve tvaru „Y-m-d H:i:s“, zpětná konverze je snadná.

<cokoli>Entity z Doctrine by se převáděly na int ID, zpětná konverze znamená dotaz na model. Tento dotaz nyní znovu a znovu píšeme ve většině action, pokaždé s kontrolou, zda záznam skutečně existuje.

Editoval jtousek (28. 2. 2011 20:57)

Automatické hledání entity může být pro určité projekty užitečná vlastnost, ale obecně do Nette se mi to nelíbí. Jestli to ve svém projektu potřebuješ, tak si to implementuj do startup.

Editoval Jan Tvrdík (28. 2. 2011 21:31)

Java-like zápis pole int[] $arr se mi líbí. A API pro mapování objektů, to zní taky moc zajímavě:-)

Pokud programuji nějaké dávkové úpravy většího množství entit tak potřebuju předávat pole poměrně často. (Sice to pole tvoří javascript, ale to je jedno.)

OK, chápu. Právě mě napadly ještě další problémy s tím mapováním objektů. Konkrétně dědičnost – nebyla by možnost aby každý zděděný presenter používal jiné objekty. Už mě i napadlo řešení, ale ke zveřejnění to má ještě daleko.

Má někdo nápad, jak elegantně pořešit validace persitentních parametrů?

jtousek napsal(a):

Dotaz: může mít komponenta (ne presenter) i neperzistentní parametry? Pokud ano, jak fungují? Ideálně příklad využití.

Proč by nemohla?

public function render($param)
{
	$this->template->param = $param; // sample
}

{var $param = 'foo'}
{control foo $param}

jtousek napsal(a):

Aha tys dal tu normální validaci do reflexe, takže to není omezené jen na komponenty / presentery. Zajímavé.

Tam to dal David, já to akorát nepřesunul jinam.

Může mít komponenta (ne presenter) i neperzistentní parametry? Pokud ano, jak fungují? Ideálně příklad využití.

Jedná se sice o off topic, ale rád bych ti v tom udělal jasno, už proto, že kolega Patrik se bohužel mýlí. Termín „parametry komponenty“ označuje (alespoň dle mého názoru) obsah proměnné PresenterComponent::$params. Pokud máš v presenteru komponentu nazvanou foo, tak parametr s názvem name a hodnotou abc bude v url reprezentován jako ?foo-name=abc. Perzistentní parametry komponenty jsou zvláštním druhem („podmnožinou“) parametrů komponenty, jedná se právě a pouze o takové parametry, které vrací metoda PresenterComponent::getPersistentParams.

A ta validace parametrů funguje i tady nebo jen v presenterech?

Validace bude fungovat i v handlerech signálů v komponentách.

Díky za reakci. Nečekal jsem, že se jí někdy dočkám :)

Souhlasím, že hlavním problémem je pole / objekt v situaci, kdy očekávám skalár. To, co navrhuješ, by mělo ve většině případů zabránit pádu aplikace. Jedná se tedy určitě o krok dopředu.

Vrátím se zase k výše uvedenému ukázkovému příkladu:

public function renderDefault($id)
{
        $page = dibi::fetch('SELECT * FROM [pages] WHERE [pageId] = %i', $id);
        if ($page === FALSE) throw new BadRequestException('Page not found!');
        $this->template->page = $page;
}

Stále zde bude problém s duplicitou (např. pro ?id=123ABC). Pokud doplníme jako výchozí hodnotu nulu, tak problém s duplicitou zmizí, ale objeví se dva problémy nové:

1. Akceptování ?id=123ABC nemusí být žádoucí (osobně bych čekal 404, ne přesměrování na ?id=123).
2. Nula získá speciální význam, takže najednou ji nelze mít v URL (?id=0 přesměruje na ?, aspoň myslím).

Anotace tento problém řeší velmi elegantně a čitelně. Bohužel máš pravdu, že lidé mají často v anotacích chyby. Osobně si to v rámci své perfekcionistické povahy docela hlídám, ale je mi jasné, že pro spoustu lidí to bude představovat problém.

Napadají mě tři způsoby, jak tento problém částečně řešit (nic ultimátního nemám).

1. Kombinace s tvým nápadem
Tvé řešení velmi elegantně chrání aplikaci před pádem, což je hlavní problém. Pokud bude anotační validace napsána omylem příliš přísně, tak si toho programátor (nebo jeho testy) všimnou, protože aplikace nebude fungovat. Pokud bude napsána volněji, tak tvá část řešení ochrání aplikaci před pádem a ostatní problémy jsou nekritické (duplicity, akceptování divných URL apod.).

2. Povinné uvedení názvu parametru
Jakkoliv se mi to hnusí, protože se jedná o zbytečnou a duplicitní informaci, tak je pravdou, že pokud by se povinně uváděl i název parametru, tak by to vedlo k výrazně nižšímu množství chyb způsobených nepozorností.

3. Přidat do Nette nástroj, který by problémy hledal
Nevím přesně, jak by fungoval, ale něco by se určitě napsat dalo :)

Připomínám existenci souvisejícího vlákna a experimentální implementace.

Díky, za implementaci. Asi by bylo dobré, založit pro to samostatné vlákno v changelogu. Takový BC break by neměl být utopen v rámci novinek v Nette 2.0.

Validace anotacemi mi ale stejně přijde hezčí :)

Varování: Následující věta obsahuje rýpnutí do tvé osoby.

Osobně bych to v souladu s mým názorem na vydávání verzí (představeným na Plzeňské Poslední sobotě, kdes bohužel nebyl) přesunul do větve (ta věc, které je pro rozumné vydávání verzí věc nezbytná a tebou zatím silně nevyužitá) pro 2.1, protože verzi 2.0 je třeba vydat a tohle bude vyžadovat dlouhodobější testování.

BTW: Nehledáš spíš ďáblova žalobce? Já myslel, že ten advokát jsem já. Ale možná se vůbec nechytám :)