Sloučení rout pro slug i null

@Infanticide0

Když je $user null, nic se nefiltruje a zobrazí se komplet data.
Routa /all je pro zobrazení stránky, kde je zobrazeno všechno.

Takhle bez detailních informací mě tyto dvě stránky přijdou duplicitní – obě zobrazí všechno (komplet data). Otázkou je, pokud duplicitní nejsou čím se liší a pokud duplicitní jsou, proč routu /all jednoduše neodstranit, nebo ji ponechat a pro $user = null vyhodit 404.

m.brecher napsal(a):

@Infanticide0

Když je $user null, nic se nefiltruje a zobrazí se komplet data.
Routa /all je pro zobrazení stránky, kde je zobrazeno všechno.

Takhle bez detailních informací mě tyto dvě stránky přijdou duplicitní – obě zobrazí všechno (komplet data). Otázkou je, pokud duplicitní nejsou čím se liší a pokud duplicitní jsou, proč routu /all jednoduše neodstranit, nebo ji ponechat a pro $user = null vyhodit 404.

Obě routy míří na jeden Presenter, ale neni to Homepage, takže routu potřebuje.
Presenter s $user=null zobrazuje třeba Datagrid všech dat ->findAll(), když $user je entita, Datagrid podle jeho id filtruje data ->findBy(..$user->id..).

zjednodušeně
.cz/123456 ⇒ data uživatele ID=123456 (ListPresenter)
.cz/all ⇒ data všech uživatelů (ListPresenter)
.cz ⇒ HomePresenter

A já nechci duplikovat parametry. Hledám něco jako <user ?? ‚all‘>

@Infanticide0 Aha, nedošlo mi, že už v té routě budeš mít Route::FilterIn a Route::FilterOut – v tom případě si tu „prázdnou“ hodnotu all můžeš pořešit už tam:

$router->addRoute("<user>[/<page=1 \d+>][/<perPage \d+>]", [
	'presenter' => 'List',
	'action' => 'default',
	'user' => [
		Route::FilterIn => function (string $user) {
			return $user === 'all' ? null : $this->orm->users->getById($user);
		},
		Route::FilterOut => function (User|null $user) {
			return $user === null ? 'all' : $user->id;
		},
	],
]);

@KamilValenta

routa má být každopádně co nejstriktnější

Hodně záleží na celkové situaci, takže nejde generalizovat, ale s typováním int již v routě nemám dobré zkušenosti. Při neplatném parametru router vyhodí 404 a chybí informace, ve kterém modulu a presenetru se tak stalo. Obvykle chceme 404 stránky vykreslovat do layoutu aktuálního modulu a to je v tomto případě problém. Naopak když se bude int parametru typovat až v metodě akce tak 404 vyhodí presenter a error presenter bude vědět ve kterém modulu se to odehrálo a vykreslí 404 stránku do layoutu správného modulu. Typování int parametru v routě samo o sobě žádné výhody nemá.

m.brecher napsal(a):

Hodně záleží na celkové situaci, takže nejde generalizovat

Celkem nezáleží, nedává smysl, aby router propustil pro něj nevalidní request a pak jej zařízl presenter.
Když pro zjednodušení přehlédnu filtrIn funkce, které do toho vnesou ještě větší přísnost, uvažujme dvě routy, jedna matchne čísla, druhá stringy:

$router->addRoute('<personalnumber>', ':Personal:List:default');
$router->addRoute('<slug>', ':Articles:Detail:default');

Pokud bude router moc benevolentní, url „/novinky-v-roce-2024“ se matchne na modul Personal a vyhodil by 404, sice krásně omalovanou layoutem z modulu Personal, ale druhá routa by ráda vrátila článek, který má…

ale s typováním int již v routě

Routy skutečně netypují.

Při neplatném parametru router vyhodí 404 a chybí informace, ve kterém modulu a presenetru se tak stalo. Obvykle chceme 404 stránky vykreslovat do layoutu aktuálního modulu a to je v tomto případě problém.

„Obvykle“ není „vždy“, ba dokonce možná ani ne „většinou“.
URL „/dvacetsedm“ je dle výše uvedených rout adept na 404 jakého modulu? Je to neexistující slug, nebo špatně zadané číslo?
Každopádně to není práce pro router. Ten má říct, zda je URL validní, nebo 404.
ErrorPresenter může o layoutu rozhodnout z debug_backtrace() a nebo query stringu.

Naopak když se bude int parametru typovat až v metodě akce tak 404 vyhodí presenter a error presenter bude vědět ve kterém modulu se to odehrálo.

Nikoliv. ErrorPresenter maximálně bude vědět, která routa byla „nejhladovější“ a matchnula to třeba i neprávem.

Editoval Kamil Valenta (28. 2. 19:40)

@Infanticide0

aby kód pro sloučené routy byl skutečně funkční, je potřeba zajistit, aby router mohl rozlišit nepovinné parametry $page a $perPage, které jsou za sebou, stačí dodat prefixy:

$router->addRoute('', 'Homepage:default');
$router->addRoute('<user all|\d+>[/page-<page>][/perPage-<perPage>]', 'List:default');

@KamilValenta

nedává smysl, aby router propustil pro něj nevalidní request a pak jej zařízl presenter.

Já to takto používám všude. V akci parametry requestu vždycky typuji. Potom je filtr regulárním výrazem \d+ v routě nadbytečný.

Pokud ovšem v jednom parametru chceme typem rozlišit dvě různé akce, pak je filtr v routě samozřejmě nutný. Také jsem to takto použil v parametru user:

$router->addRoute('<user all|\d+>.......', .....);

Parametry $page a $perPage žádnou paralelní routu nemají, filtry \d+ lze tedy vynechat a funkce zůstane stejná – proto jsem je tam nedal.

@Infanticide0

S null to prostě nefunguje. Proč?

Až teď jsem si všiml, že používáš jinou routu:

$router->addRoute("<user users|.+>", [
	'presenter' => 'UserList',
	'action' => 'default',
	'user' => [
		Route::FilterIn => function ($user) {
			bdump($user, "in");
			if($user === "users" || $user === null)
				return false;

			$up = explode('-', $user);
			return $this->orm->users->getBy(["id" => $up[0]]);
		},
		Route::FilterOut => function ($user) {
			bdump($user, "out");

			if($user instanceof User)
				return "$user->id-admin";

			return "users";
		},
	],
]);

Zde je pointa v primárním filtru parametru user v routě:

'<user users|.+>'

Použitý regulární výraz null nezachytí.

Tento regulární výraz by se dal zjednodušit:

'<user .+>'	// jednodušší
'<user>'	// ještě jednodušší

všechny varianty pro <user> matchnou jakýkoliv řetězec s výjimkou prázdného

ale routa by měla zachycovat jenom users nebo userId které je int, pak je lépe ji napsat takto:

$router->addRoute("<user users|\d+>", ...);

Routa kterou Ti navrhuji null nematchne, což je dobře, protože to by nedávalo smysl. Výpis pro všechny je pro $user === ‚users‘, co by se mělo vypisovat pro null ?? Tam není co vypsat.

Editoval m.brecher (29. 2. 21:14)