Tak jsem se po delší době dal do úprav stávajícího kódu pro blog a je to dost záhul. Už si z toho Zend Frameworku moc nepamatuji. Ještě, že je k dispozici tak solidní dokumentace. Upravuji to k běhu na verzi 1.7.x, mezi tím mě to trochu nabouralo oznámení připravované verze 1.8, takže budu asi ještě dlouho mít o zábavu postaráno. Jedna z věcí, kterou jsem chtěl udělat, je přechod od svého řešení generování url na to, které je součástí frameworku.
Od začátku jsem používal vlastní řešení. Vadilo mi zejména to, že nešlo generovat url z routeru v aplikaci. V šablonách byl od začátku k dispozici Zend_View_Helper_Url
. Helper na generování url v controllerech už je nějakou dobu součástí frameworku a moje řešení má jednu zásadní nevýhodu, není ovlivněno routerem. Musím tedy udržovat pro url v aplikaci dvě věci, router a databázi url. Zbavím se tedy svého "generátoru" url a všechno nechám na routeru ve frameworku a helperech.
Základem všeho je to, že objekt routeru ve frameworku má metodu assemble
. Která vám umožní zpětně složit url z parametrů routy a jejího jména. Pokud nepoužijete jméno routy, vezme se ta aktuální, která je použita pro aktuální url.
Pro generování url v šablonách je tedy k dispozici Zend_View_Helper_Url
v šabloně ho jednoduše zavoláte jako url
metodu a předáte jí parametry pro výše zmíněnou assemble
metodu routeru. Helper assemble
metodu routeru zavolá a vrátí vám výsledek. Např. v šabloně zobrazení článku mám odkaz na další článek nějak takto:
<a href="<?php echo $this->url(array("entry" => $this->previousArticle->getTitleUrl()),"blogArticle")?>">Další</a>
Název routy - blogArticle
, je možné vynechat, jsme na url s detailem článku. V parametrech není třeba předávat parametry, které jsou v definici routy uvedeny jako implicitní. Routa blogArticle
je v routeru definována nějak takto.
$router->addRoute('blogArticle', new Zend_Controller_Router_Route('blog/:entry', array('module' =>'blog','controller'=>'index','action'=>'index')) );
Pro získání url v metodách controlleru je tu action url helper Zend_Controller_Action_Helper_Url
. Ten je zajímavý v tom, že má implicitní generování url definováno mimo router. Předpokládá implicitní tvar url modul/controller/action/param1/value1/param2/value2...
. To zajišťuje metoda simple
. Pak tu máme i standardní metodu url
, která bere v úvahu router a dělá přesně to, co jsem popisoval výše pro url view helper.
Použití je tedy následující, metoda simple
je, jak jsem uvedl, je implicitní metodou generování, takže někde v controlleru vám volání
$this->_helper->url("mainModule","mainController","mainAction", array("param1"=>"val1") );
Vrátí /mainModule/mainController/mainAction/param1/val1
. Pro url dalšího článku bychom v controlleru museli napsat toto.
$this->_helper->url->url( array("entry" => $previousArticle->getTitleUrl()), "blogArticle" );
To dvojité url
je takové podivné, osobně používám generování url výhradně přes router, proto bych spíše přivítal variantu, kdyby implicitní možnost pro tento helper je generování přes router. Asi to vzniklo postupem vývoje, třeba se to ve verzi 2.0 změní. Ještě jsem zapoměl na jednu věc, která mě také překvapila, v dokumentaci k built-in action helperům tenhle helper není vůbec popsán, což je docela zarážející.
Komentáře (5)
Mensi offtopic: Jak to ze si z toho Zend frameworku moc nepamatujes? Co teda delas?
V práci Zend Framework nepoužíváme, takže se mu můžu věnovat jen ve volnu a toho moc není a po 8 hodinách čumění do kompu se mi do toho moc často ani nechce. Když na to pak třeba měsíc nekouknu, tak už se mi toho dost z hlavy vykouří, asi tak.
Jejda, koukám, že jak jsem přešel na Linode, tak mám špatně čas u komentářů.
Tak verze 1.8.x te na par hodin uzemni.
Kompletne novy bootstrap cez Zend_Application, ked pouzijes staru metodu, tak to pri refreshi vypisuje notice deprecaded.
Ted jsem tym zabil asi 4hodky nez jsem predelal jednu aplikaci, ale na ZF je dobre, ze vse staci delat jen jednou, udelany kod pak uz jen staci kopcit a pripadne trochu doladovat.
Nastesti Zend_Application neni co se tyce dokumentace az taky kolos jak napr. Zend_Controller, ale kdyz si to oddebugujes, tak zevnitrl je to jina, je to fakt ozruta, kdyz jsem to prvy krat debugoval, tak jsem nechapal jak nekdo muze neco takoveho vymyslet ;)
Nastesti staci znat 1/20 nebo 1/30 a vnitrku trid v ZF se da udelat vse.
Ted jsem zvedavy jak se vyrysuje Zend_Db, tak nejak tusim, ze ve verzi 2.0 bude vydany Zend_Db_Mapper coz konecne vyresi model v ZF, jinak proposal je pecka http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Mapper+-+Benjamin+Eberlei a uz se tento koncept paternu DataMaper natlacil i do quickstartu
Mno uz se tesim jak tyto veci budu doresene (bootstrap, model a par malickosti) a ZF bude na stabilne nemene urovni
Jinak dik za clanek
[4] - díky za podněty, na Zend_Application se pomalu chystám, na mapper je myslím ještě docela čas, ale určitě se na to podívám i když na tom svém řešení oddělené bussines a dao vrstvy bych toho asi moc měnit nechtěl, maximálně místo dao založené aktuálně na Zend_Db_Table mít mapper, ale rozhodně bych zůstal u bussines vrstvy nezávislé na jakémkoli mapperu, table/row gateway apod.
Komentáře jsou uzavřeny.