Translation table + WTF

Musíš si uvědomit, že píšeš regulární výraz pro část URL nikoliv pro název presenteru. Tento regulární výraz už není dále filtrován či překládán. Pro více povolených variant lze použít znak | (např. <presenter uzivatele|neco dalšího>).

Ano to vím a proto se ptám jak to vyřešit abych si mohl určit presentery pro routu a zároveň mi fungovala translation table

nebo použít překladový slovník trochu jinak:

Route::setStyleProperty(
	'presenter',
	Route::FILTER_OUT,
	callback('HezkeUrl::getPresenterTranslation')
);
Route::setStyleProperty(
	'presenter',
	Route::FILTER_IN,
	callback('HezkeUrl::getPresenterName')
);

class HezkeUrl
static function getPresenterName($translation)
{
	if ($translation === 'uzivatel') return 'User';
	return NULL;
}

A když ti ty metody vrátí NULL tak se routa nematchne (lze dělat jen na povinné parametry)

Jestli to dobře chápu, problém je v tom, že překladová tabulka nefunguje jako filtr, tj. pokud překlad existuje, přeloží se, pokud neexistuje, bere se původní hodnota. Taky mě to překvapilo :-) Bylo by tedy vhodnější implementovat předkládací tabulku podobně jako funguje filtrovací callback?

Bude se to ještě řešit?

Pokaždé, když používám Route::FILTER_TABLE, tak musím dát do regulárního výrazu všechny možné části URL, aby routa „neodchytávala“ to, co nemá. Když je těch překládaných hodnot víc, tak je to nepřehledné a špatně se to upravuje.

Vysvětlím to na příkladu:

// regulární výraz je nutný, aby šla používat druhá routa
$router[] = new Route('<presenter registrace|prihlaseni|profil|vyhledavani|kontakt>/<action>[/<id>]', array(
	'presenter' => array(
		Route::FILTER_TABLE => array(
			'registrace' => 'Register',
			'prihlaseni' => 'Login',
			'profil' => 'Profile',
			'vyhledavani' => 'Search',
			'kontakt' => 'Contact',
		),
	),
	'action' => 'default'
));

$router[] = new Route('<article>/<action>', 'Article:default');

Zatím jsem se nesetkal s tím, že bych použil filtrovací tabulku a očekával, že projdou i hodnoty, které v tabulce nejsou. Nebylo by lepší, kdyby ta tabulka byla opravdu filtrovací?

No právě, že by mohlo. RouteList zkusí použít nejprve tu první, a teprve pokud by vrátila NULL, tak by teprve zkoušel použít tu druhou routu.

Takhle to funguje teďka: (viz API)

if (isset($meta[self::FILTER_TABLE][$params[$name]])) {
	$params[$name] = $meta[self::FILTER_TABLE][$params[$name]];
}

Myslím, že takhle by to bylo mnohem intuitivnější:

if (isset($meta[self::FILTER_TABLE])) {
	if (isset($meta[self::FILTER_TABLE][$params[$name]])) {
		$params[$name] = $meta[self::FILTER_TABLE][$params[$name]];
	} else {
		return NULL; // not matched
	}
}

Obdobně by se pak musela upravit i konstrukce URL.

tiez sa priklanam k nazoru uzivatela @jansfabik. Jasne, ze sa to da napisat pomocou FILTER_IN/OUT, ale FILTER_TABLE by bola pekna skratka. Osobne som tiez ocakaval, ze to bude fungovat ako ozajstny filter, takto implementovane je to pre mna nelogicke a radsej to nepouzivam =)