Jak simulovat HttpRequest?
- Tomik
- Nette Evangelist | 485
Zdravím!
Rád bych do svého systému implementoval tuto vlastnost – při přidání,
resp. upravení textu se veškerá URI, která jdou na některý z Presenterů
aplikace nahradí za nějakou pseudo-syntax (klidně podobnou
CurlyBrackets
), např. URI http://www.web.cz/ahoj/edit
se nahradí za {link Pages:edit 'uri' => 'ahoj'}
, či něco
podobného, poté při zobrazování tuto pseudo-syntax pouze převedu na
aktuální URI. Jakou to má výhodu? Může se změnit schéma URI webu
(myšleno definice rout) a není třeba v žádném textu upravovat
jediný odkaz.
A teď k dotazu:
Už jsem se pustil do implementace, regulárem najdu všechna URI v odkazech
(resp. v src|href|action|on[a-z]+
), a potom bych na tyto
jednotlivá URI chtěl aplikovat podobný princip zpracování jako probíhá
u RoutingDebuggeru. A pokud dojde k schodě, tj. nalezení
Presenteru a action k danému URI, pak jej nahradit za pseudo-syntax odkazu,
pokud ke shodě nedojde, pak nechat normální URI – to které tam bylo (tj.
URI pravděpodobně vede mimo web, resp. vede např. na obrázek, či styl) –
proto jej nebudu nahrazovat.
Ale! Princip zjišťování
v RoutingDebuggeru zda URI odpovídá nějaké routě (resp.
jejímu presenteru
a action
) je založen na
HttpRequest
, a tu nelze vytvořit jinou než s URI právě
položeného požadavku. Chci se tedy zeptat, zda je možné nějak
HttpRequest
objekt nějak simulovat pro konkrétní URI (tj. jinou
adresu, než která je pro právě položený request – tedy pro jinou
adresu, než která je zobrazena v adres-baru), nebo je nutné kompletně pro
tento požadavek přepsat metodu match
v Routě
(tak,
aby pokud to potřebuji nebrala informace z HttpRequest
, ale třeba
z objektu Uri
, který jí nějak předám).
Díky za rady. :)
- Jan Tvrdík
- Nette guru | 2595
Nešlo by podědit a upravit HttpRequest
nebo vyrobit vlastní
třídu implementující IHttpRequest
?
PS: Nechápu, co myslíš tím simulováním RoutingDebuggeru. Mělo by
stačit zavolat
Environment::getApplication()->router->match($httpRequest)
.
EDIT: Vypadá to, že stačí, když si třídu HttpRequest
podědíš a napíšeš si metodu __construct
, která naplní
atributy hodnotami, takže k volání detectUri
a
initialize
vůbec nedojde.
Editoval Jan Tvrdík (8. 5. 2009 18:03)
- Tomik
- Nette Evangelist | 485
kravco napsal(a):
Vzhľadom na to, ako je napísaný HttpRequest, cezeň to asi nepôjde. Vďaka otvorenosti však Router vyžaduje interface
IHttpRequest
, čiže ti nič nebráni spraviť veľmi jednoduchýMockHttpRequest
, ktorému v konštruktore alebo pomocou setterov nastavíš všetko čo treba…
O tomhle jsem taky uvažoval. Asi to bude nejjednodušší. Díky.
- Tomik
- Nette Evangelist | 485
Jan Tvrdík napsal(a):
PS: Nechápu, co myslíš tím simulováním RoutingDebuggeru. Mělo by stačit zavolat
Environment::getApplication()->router->match($httpRequest)
.
Máš pravdu, tohle mě fakt nenapadlo. :) Já zbytečně procházel každou subroutu Multirouteru. Nějak mě nedoclaklo, že zjistit Routu, která odpovídá nějakému requestu jde mnohem snáze. ;)
Díky vám oboum za spolupráci. ;)
- xificurk
- Člen | 121
Doufám, že jsem vykopíroval ze svých Helperů vše podstatné…
Použití:
- Před uložením textu do databáze zavolat
Helpers::url2PresenterLink($text)
- Vytažený text z databáze v šabloně můžeme prohnat helperem, příp.
Texy pomocí
{!$text|PL2U|texy}
Editoval xificurk (15. 5. 2009 13:04)
- xificurk
- Člen | 121
Ještě jsem si vzpomněl na jednu poznámku: Zatím jsem nevymyslel, jak to vyřešit lépe, ale…
Je nutné mít routy včetně domény, protože jinak to suveréně naparsuje
http://example.com/
na {plink //DefaultPresenter:}
.
Jiným řešením by bylo upravit regulár v helperu pro použití na
konkrétních doménách, ale ty routy mi přišly jako menší zlo.