Nody (Dynamické routy)

Já jsem to vyřešil přes návrh 2. Stačí si napsat vlastní router.

Všechny routy uložíš do Cache. Trošku problémů je s vytvářením nodů ve stromových strukturách, ale třeba to nebudeš potřebovat.

Stačí upravit pak matchUrl a constructUrl.

V DB to ukládám:

notebooky/podle-hmotnosti/do-3kg ⇒ Eshop:Catalog:View:45

No si představ, že máš teda notebooky/podle-hmotnosti/do-3kg a změníš notebooky na „netbooky“, pak musíš všechny položky na této URL závisející také změnit.

Také ři každé změně čehokoliv musíš měnit tabulku s těmi aliasy(nody), což sice není problém, ale otrava.

Taky si myslím stačí pouze spustit dávku na přejmenování všech Nodu které obsahují to co chceš změnit nebo pokud to máš řešené tak že máš uloženou strukturu takto:

notebooky - kategorie
podle-hmotnosti - filtr
do-3kg - parametr filtru

tak nikde není psáno že musíš mít jednotlivé další parametry uloženyjako

notebooky/podle-hmotnosti/do-1kg
notebooky/podle-hmotnosti/do-2kg
notebooky/podle-hmotnosti/do-3kg
notebooky/podle-hmotnosti/do-4kg
notebooky/podle-hmotnosti/do-5kg

ale můžeš je mít uloženy jako

notebooky - #1
podle-hmotnostri - #2 - parrent #1
do-1kg - #3 - parrent #2
...
do-5kg - #n - parrent #2

a pak když změníš notebooky za netbooky tak se to automaticky promítne až do do-3kg…
# je bráno jako identifikátor (id)

Já jsem si vyrobil něco takového:

<?php
// pseudokód
class ArticleRouter {
	private $data;

	function __construct() {
		$arr = dibi::query("select id, url, parent from articles")->fetchAssoc("parent,#");
		$this->addArticlesWithParent(NULL, "", $arr);
	}

	function addArticlesWithParent($parentId, $startUrl, $articles) {
		// rekurzivně nacpat do pole $data
		foreach ($articles[$parentId] as $item) {
			$this->data[$item->id] = $startUrl . "/" . $item->url;
			$this->addArticlesWithParent($item->id, $startUrl . "/" . $item->url, $articles);
		}
	}

	function match(IHttpRequest $context) {
		// jestli je v poli $data, tak přidat do parametrů presenteru id
	}

	function constructUrl(PresenterRequest $request, IHttpRequest $context) {
		// if isset($data[$params["id"]) return $data[$params["id"]];
	}
}
?>

Nechce se mi to víc rozepisovat, snad je princip jasný. Myslím, že pro menší a střední weby je to dobré. Pro větší nevím, jestli je dobré přednačíst adresu tisíce článků.

Tak mě to nedalo a vydal jsem se to testovat…

Testovací aplikace

• 10000 Nodu/Rout (+1 univerzální na všechno, co neprojde)
• 1 Presenter:action – pouze načetl z DB (vždy sahal do DB) testovací text a vyrendroval ho společně s ID Nody/Routy. Text se tahal vždy stejný, tzn. z tabulky data na s id 1.
• Testování času běhu celé app od načtení Nette\loader po rendering (stopky se stoply až při samotném renderování) – All
• Testování času běhu od zavolání $application->run() po spuštění akce v presenteru ({Presenter}Presenter::action{Action}) – Router

Co se testovalo

1. možnost uvedená výše pod číslem 1
   1. pouze z DB
   2. cache
2. možnost uvedená výše pod číslem 2
   1. pouze z DB
   2. cache

X	1a	1b	2a	2b
All	1.2992276748	1.25103594859	0.03462378184	0.0349680980047
Router	0.471882522106	0.468844731648	0.00418408711751	0.00432453552882

Časy jsou průměrné, po otestování 100 různých url (prvních 10 záznamů + posledních 10 záznamů + prostředních 10 záznamů + 70 náhodných) – vždy se jednalo o stejný seznam (tzn. 1a byla testována na stejné url, jako ostatní – 1b, 2a, 2b). Jsou uvedeny v sekundách.

Z uvedené tabulky vyplývá, že možnost 2a je 37.5x rychlejší, pokud se týká celé aplikace a 112x rychlejší, pokud se týká routeru, než možnost 1a. U možnosti 2b vs. 1b je to 35x aplikace a 108x router. Jak je taky patrné s cache a bez ní, jsou rozdíly zanedbatelné. Nicméně tento test nebyl prováděn na produkčním prostředí za ostrého provozu, takže mohou být některé výsledky zkreslené. Se zapnutou cache by měly být aplikace rychlejší, než bez ní.

Až se budu po fotbale nudit tak na to kouknu… ale myslím že se to moc lišit nebude… :-)