Najjednoduchší MVC framework v PHP (part #1)

V tomto článku vám ukážem, ako si naprogramovať naozaj veľmi jednoduchý framework pre webové aplikácie v jazyku PHP. Medzi výhody frameworku patrí okrem iného, naozaj tiny veľkosť (samotné jadro je v šiestich malých .php súboroch), jednoduchá rozšíriteľnosť (pomocou vlastných tried), OOP a MVC prístup a jeho črevám porozumie aj úplný programátorský analfabet.

Prečo zase ďalší framework?
Pre nájdenie odpovede si musíme položiť otázku: „na čo je tento framework vhodný“. Predstavte si situáciu, že budete známym požiadaný o napísanie jednoduchej ankety alebo jednoduchej jednoúčelovej galérie. Mnoho začínajúcich PHP-čkarov siahne po metóde index.php ==> include($_GET), niektorí sa možno odvážia použiť aj nejaký šablónový systém. Stále však treba vymyslieť kód, ktorý bude generovať stránky podľa požiadaviek od klienta. Tie sú zväčša deklarované ako parametre v URL. Ak budete chcieť implementovať coolURI, pribudne ďalší kód. A čo takto podpora multi-language?

Áno - toto všetko framework rieši elegantným, krátkym kódom. Spolu s objektovým a MVC prístupom je rýchlosť dokončenia a manažovateľnosť aplikácie ďaleko vpredu pred hore spomenutou include() metódou. Jediné čo budete potrebovať naprogramovať, sú Controllery a Modely, čo sú .php súbory s typicky jednou triedou, určené na ovládanie aplikácie a dolovanie údajov.

Aké sú teda hlavné vlastnosti frameworku, ktorý som nazval príznačne sMVCfw (simplest MVC framework):
1. MVC prístup (vzhľad aplikácie je možné nechať na pleciach HTML kódera)
2. plne objektový kód
3. podpora coolURI
4. podora multijazyčnosti pomocou URL v tvare http://www.example.com/[jazyk]/ (+samodetekcia jazyka podľa UA)
5. vstavaný šablónovací systém (knižnica bTemplate - podporuje napr. loopy nad poliami alebo podmienky IF)
6. jednoduchá rozšíriteľnosť a modularita
7. jednoduchý je aj DEBUG, nakoľko je všetko pekne oddelené v samostatných súboroch.
8. je použiteľný aj na väčšie veci ako je blog alebo webový časopis.

K bodom 4 a 6 by som chcel niečo napísať.
- Na jednom známom web dizajnérskom fóre často vidím borcov, čo si informáciu o jazyku ukladajú do SESSION alebo COOKIE. Už som aj pár krát dohováral, že to nie je vhodné z hľadiska SEO. Môže sa totiž stať, že sa pod jednou URL bude skrývať niekoľko verzií stránky. Vďaka tomu je vyhľadávačmi indexovaná vždy iba jedna jazyková mutácia. Okrem toho sa duplicitný obsah na jednej URL u vyhľadávačov penalizuje. Informáciu o jazyku zásadne prenášajte v URL!

- Rozšíriteľnosť a modularita - nakoľko je kód umiestnený v súboroch s triedami, nie je problém jednoducho pridávať nové funkcie (aj cudzie, viď portál PHPclasses.) alebo napr. komplet vymeniť databázový layer za iný. Neskôr si ukážeme ako s pomocou tohto frameworku zostaviť jednoduché CMS-ko.

Na začiatku je vhodné upozorniť na licenčné podmienky. Zdrojové kódy, ktoré uverejním k stiahnutiu v druhej časti seriálu budú pod licenciou MIT. Táto licencia vám umožňuje využiť framework aj pre komerčné účely bez nutnosti otvoriť váš vlastný kód. Pod rovnakou licenciou je aj knižnica bTemplate.

Framework v akcii
Pred začiatkom práce je vhodné napísať, že celá aplikácia má jeden vstupný bod: súbor index.php. To je veľmi výhodné - predtým ako predáte kontrolu nad behom aplikácie do controllera, môžete vykonať rôzne iné operácie, napr. zalogovať si návštevu do databázy, alebo sledovať pohyb návštevníka po webe. Nech už si zobrazí akúkoľvek stránku, vždy pôjde jeho požiadavka najprv cez index.php.

Pripravme si pracovné prostredie. Odporúčam vytvoriť si nový virtuálny server, celú aplikáciu však môžete umiestniť aj do podadresára na webserveri. Ja som pre tutoriál vybral prvú možnosť - aplikácia priamo v koreni www_root.
Spustite teda virtuálny server, napr. s adresou http://smvcfw/. V adresári www_root si vytvorte adresáre (dodržujte veľkosť písmen!):

Vďaka tejto schéme je možné framework nasadiť na každom hostingu. Existujú totiž frameworky, ktoré vyžadujú umiestniť svoje libky a ostatný kód mimo www_root. Našťastie to nie je tento prípad. Keďže sú adresáre s programovým kódom vo verejne prístupnej zložke, je treba adresáre ochrániť pred nepovoleným prístupom. Vytvorte súbory .htaccess s dole uvedeným kódom a umiestnite ich do adresárov controllers, lib a templates.

Do adresára public zase umiestnite súbor .htaccess s obsahom:

Umožníte tak svojím návštevníkom sťahovať si verejne dostupné súbory (CSS štýlopisy, obrázky layoutu stránky). Akékoľvek súbory v adresári public budú priamo dostupné pomocou URL http://smvcfw/public/cesta/k/suboru

Posledný .htaccess fajl príde do koreňa www_root. Jeho obsah:

V tomto súbore trocha dotiahneme konfiguráciu PHP (vypneme nebezpečné a nepohodlné veci), zakážeme prechádzanie adresárov vo www_root (prechádzanie je ale povolené v adresári public, viď kód vyššie) a nastavíme konfiguráciu mod_rewrite.

mod_rewrite je nastavené tak, že najskôr hľadá súbor alebo adresár v menom podľa príchodzej URL. Ak napr. príde požiadavka s URL http://smvcfw/admin/ začne sa hľadať adresár alebo súbor s menom admin v koreni www_root, aby mu bola požiadavka predaná k spracovaniu.

Ak sa takáto položka nenájde, je všetko za TLD (najpravešia časť doménového mena) priradené ako hodnota premennej $_GET['route']. V našom malom príklade sa teda spracovanie predá do index.php a do $_GET['route'] sa zapíše string "admin/". Z toho vyplýva, že framework je možné prevádzkovať aj bez mod_rewrite, stačí aby aplikácia dodržiavala určitú schému pri generovaní <a href> linkov (konkrétne teda, linky musia mať formu index.php?route="CONTROLLER/ACTION/PARAMETER0/PARAMETER1/...").

V poslednej vete som naznačil ako framework spracuje požiadavku v závislosti od URL. Opäť použime modelovú situáciu s požiadavkou na stránku http://smvcfw/admin/.

Webový server najskôr hľadá súbor alebo adresár s menom admin, tak ako som to spomínal vyššie. V prípade neúspechu, je spracovanie predané súboru index.php. Ten sa spolu s ostatným kódom bude snažiť nájsť súbor s presne špecifikovaným menom, v tomto prípade AdminController.php. Ako je zrejmé, súbor sa bude hľadať v adresári controllers. V prípade úspechu sa súbor "natiahne" a riadiaci kód sa pokúsi v súbore nájsť triedu AdminController(). Ak sa kód triedy v súbore nachádza, zavolá sa metóda index(). Vo všetkých prípadoch, keď riadiaci kód nenájde požadované položky, vygeneruje sa jednoduchá ERROR404 stránka (riadenie sa predá na ErrorConroller).

Do celého procesu ešte vstupuje detekcia jazyka. Majme napr. takúto URL:
http://smvcfw/en/news/archive/

Riadiaci kód deteguje požiadavku, ktorú by mala obslúžiť trieda NewsController(). Nebude sa však volať metóda index() ako v predchádzajúcom prípade, ale na základe URL adresy sa zavolá metóda archive(). Zároveň si aplikácia uloží na globálne dostupné miesto požadovaný jazyk (uloží sa string hodnota "en"). Povolené sú len dvojznakové identifikátory jazyka (takže žiadne eng alebo ger ale pekne en resp. de).

Rozšírme predchádzajúci príklad takto:
http://smvcfw/en/news/archive/2008/june

Už vieme, že požiadavku bude obsluhovať trieda NewsController() a jej metóda archive(). Vieme, že sa niekde uloží hodnota s identifikátorom jazyka. Zvyšné dve položky z URL (2008/june) sa uložia na to isté globálne miesto, kde leží identifikátor jazyka ako hodnota array ([0] => '2008' [1] => 'june').

A keď sa dobre zamyslíme, zistíme, že máme všetky potrebné údaje a premenné, potrebné na vygenerovanie stránky. Zapojíme do práce naše triedy MODEL, vydolujeme z databázy potrebné údaje a pomocou VIEW ich vyrenderujeme do prehliadača návštevníka. Ideálna spolupráca jednotlivých komponentov MVC.

Píšeme kód
Poďme sa pustiť do písania kódu, ktorý toto všetko zabezpečuje. Začneme súborom index.php v koreni www_root. Zapíšte tento kód

index.php

Všimnite si, že v súbore nie je ukončený blok PHP kódu. Takto budeme postupovať vo všetkých .php súboroch, ukončite ich iba novým riadkom (new-line) za posledným neprázdnym riadkom (tak to je zvykom v UNIXe a Linuxe - každý súbor so zdrojákom má na konci jeden prázdny riadok). Dôvod prečo nebudeme ukončovať blok PHP kódu, je ten, aby sa na výstup nedostali žiadne (biele) znaky ešte predtým ako budeme renderovať stránku. V prípade, že by ste napr. posielali nejaké cookies (session), objavila by sa známa chyba
Warning: Cannot modify header information - headers already sent.
Však to isto poznáte. Dodržiavaním tohto postupu, týmto nepríjemnostiam zabránite.

Malý popis zapísaného kódu:
Prvé dva riadky riadia úroveň chybových hlásení aplikácie. Horeuvedený zápis je vhodný pre vývoj. V prípade ostrej prevádzky nezabudnite chybové hlásenia úplne vypnúť (nastavením error_reporting na E_NONE a ini_set('display_errors') na "off")!

Okrem toho nastavujeme časovú zónu, aby aplikácia vedela, v akej časovej zóne beží - PHPčko to potrebuje vedieť, aby správne pracovali niektoré jeho funkcie.

Nasleduje vytvorenie dvoch užitočných konštánt. DS je skratkou pre pôvodne dlhý, neprakticky názov oddeľovača adresárov. APPROOT drží cestu k súboru index.php vo filesystéme servera. Cestu potrebujeme vedieť preto, aby sme vedeli dynamicky "naťahovať" súbory z adresára lib a aby aplikácia mohla bežať aj v podadresári. Cesta sa získava z magickej konštanty __FILE__, ktorá vždy obsahuje cestu k aktuálnemu súboru. Z tejto konštanty odstránime meno súboru (index.php) a expandujeme prípadné symbolické linky.

Hneď na následujúcom riadku novú konštantu APPROOT zužitkujeme a adresár lib vložíme do čela cesty, kde PHP vyhľadáva knižnice. Posledný príkaz bude preto súbor Loader.php hľadať práve tam. To je zatiaľ k súboru index.php všetko, poďme sa pozrieť na súbor Loader.php, ktorý je zodpovedný za "autoloading" knižníc.

lib/Loader.php

Tento súbor obsahuje definíciu ďalšej mágie v PHP - magickej funkcie __autoload(). Táto funkcia sa stará o automatické naťahovanie súborov, vždy keď PHP potrebuje definíciu novej triedy. Takže už žiadne include("lib/smarty/smarty.php"), preč s tým. Kód funkcie __autoload() pri požiadavke na triedu, ktorá ešte nebola natiahnutá, vyhľadá súbor s jej zdrojákom a "inkludne" ho do aplikácie.

Loader.php najskôr prevedie všetky podtržítka na oddeľovače adresárov. Následne zostaví cestu k súboru a opäť s pomocou APPROOT overí či je súbor dostupný. Ak teda niekde v aplikácii napíšeme:
$db = new Zend_Db_Table();

__autoload() bude hľadať súbor lib/Zend/Db/Table.php. Súbor Table.php musí obsahovať definíciu classy v tvare:

Loader.php nám tak umožňuje prehľadné organizovanie knižníc v rámci nášho lib adresára. A áno hlavnú časť jeho kódu som odkukal z aktuálneho Zend Frameworku :) . Loader.php je týmto hotový, vráťme sa teraz k súboru index.php. Doplňte do neho kód:

Ešte som nenapísal, že súbor index.php predstavuje tzv. bootstrapper - súbor, ktorý vykonáva všetky dôležité činnosti, pretým než sa začne s vlastým spracovávaním požiadavky od klienta. Bootstrapper má za úlohu vytvoriť všetky dôležité objekty a pripraviť pracovné prostredie pre Controllery (často sa do neho zapisuje aj kód na pripojenie k databáze). Ako môžete vidieť vyššie, v index.php sa vytvára niekoľko nových objektov. Tým prvým je objekt $registry, ktorý slúži ako storage place pre globálne údaje. Používanie globálnych premenných ako majú vo zvyku PHP noobs je dnes (v dobe OOP) zastaralé a zaostalé. Objekt $registry nám slúži ako obálka pre naše globálne údaje. Veľkou výhodou je, že k nemu môžeme pristupovať ako ku poľu. Musíme však mať min. PHP v5.1! Definíciu tohto súboru tu nebudem uvádzať, prezrite si ho na službe pastebin a jeho obsah uložte do súboru lib/Registry.php.

Ďalším objektom, ktorý bootstrapper vytvorí je objekt $view. Jedná sa o inštanciu šablónového stroja bTemplate. Tento šablónový stroj je oproti mamutovi Smarty mimoriadne malý (len jeden súbor s definíciou triedy) a je pomerne rýchly. Nevyznačuje sa síce featurami ako kompilovanie šablón alebo cachovanie, pre požiadavky tutoriálu je však dostatočný. Zdroják som oproti originálu mierne upravil, stiahnite si ho teda z tohto miesta, nie z domovskej stranky projektu! Stiahnutý archív rozbalte a súbory vložte do adresára lib. V bootstrapperi pri vytváraní objektu $view, nastavíme cestu ku šablónam. Cesta musí byť ukončená oddeľovačom adresárov! Hneď na to je objekt $view uložený do $registry.

Posledným a snáď naj dôležitejším objektom, ktorý v index.php vytvoríme je objekt $router. To on je zodpovedný za obsluhu URL, tak ako bola popísaná hore. Keďže definícia jeho triedy má viac ako 360 riadkov, opäť odkážem iba na jeho zdroják na pastebin. "Pastnite" jeho obsah do súboru lib/Router.php. Jeho kód si bližšie popíšeme neskôr, najskôr dokončím popis index.php. Všimnite si, že do konštruktora routra je priradený objekt $registry. Vďaka tomuto postupu je obsah registru dostupný v routri. Takto nejako je v OOP obsluhované nakladanie s globálnymi údajmi. Tento postup je možné ešte zjednodušiť, čo si ukážeme na pokusnom CMSku (zbavíme sa nepohodlného predávania objektu do konštruktorov).

Bootstraper predtým ako spustí aplikáciu, uloží do $registry ešte niekoľko elementov. Tým prvým je pole podporovaných jazykových mutácií aplikácie. Okrem toho vytvorime konštantu, ktorá obsahuje identifikátor primárnej jazykovej mutácie stránok. Táto mutácia bude servírovaná klientom, ktorý pri autodetekcii jazyka nebudú spadať do poľa podporovaných mutácií.

Do registru si uložíme aj URL, pod ktorou operuje index.php - link na indexovú stránku aplikácie. Tento link nájde primárne využitie pri odkazovaní na CSS a JS súbory v šablonách, pri generovaní navigácie a pod. Túto URL nám vráti router. Následne prebehne detekcia jazykovej mutácie. Tá je zisťovaná buď z URL (viď. vyššie), alebo ak identifikátor jazyka nie je v URL a klient vstúpil na indexovú stránku (IndexController/indexAction), prebehne autodetekcia z USER_AGENT. Obe získané informácie si uložíme do registra.

Nakoniec je na základe získanej jazykovej mutácie, nastavené pomenovanie aplikácie a toto je tiež uložené do registra. Následne je aplikácia spustená.

Spustenie aplikácie

v našom FW predstavuje započatie analýzy URL routrom pomocou jeho metody delegate(). Zatiaľ čo veľké FW routujú pomerne zložitým spôsobom, podporujú rôzne patterny a regulárne výrazy, náš router bude vykonávať iba jednoduché statické routovanie. Ako som už vyššie naznačil, schéma URL je takáto:
http://smvcfw/[jazyk]/[CONTROLLER]/[ACTION]/[parameter1]/[parameter2]...

Poďme sa pozrieť ako analýza URL prebieha. Otvorte si súbor so zdrojovým kódom routra (nebudem relevantný kód vypisovať na tejto stránke, nakoľko zvýrazňovanie syntaxe silno zaťažuje BH server). Na riadku 169. sa nachádza definícia metódy delegate(). Tá hneď volá ďalšiu metódu triedy Router - parseUrl(). Ako vidíte, metóda predáva 5 parametrov. Nakoľko sú tieto v hlavičke parseUrl() deklarované ako referencie, výsledky práce parseUrl() sa nebudú vracať pomocou štandardného príkazu return(), ale práve cez tieto premenné. Metóda delegate() zavolá parseUrl() s prázdnymi premennými a tá ich naplní požadovanými hodnotami. delegate() potom takto naplnené premenné použije k svojej práci. Prejdime teda k detailnému popisu metódy parseUrl() (jej kód začína na riadku 87.).

Na začiatku metóda parseUrl() získa údaje z URL, z premennej $_GET['route']. Meno tejto premennej musí súhlasiť so zápisom RewriteRule v hlavnom .htacces súbore. Údaje z premennej sú ďalej očistené o prebytočné lomítka vpredu aj vzadu funkciou trim(). Takto očistená premenná je "rozsekaná" do poľa pomocou funkcie explode(). Ako oddeľovače jednotlivých elementov poľa sa využijú lomítka z URL adresy.

Keď zoberieme náš predošlý príklad s adresou http://smvcfw/en/news/archive/2008/june, výsledné pole bude mať takúto schému:

Jednotlivé elementy poľa sú následne podrobené analýze. Najskôr prebehne analýza toho, či prvý prvok URL obsahuje identifikátor jazykovej mutácie. Testuje sa jednoduchým regulárnym výrazom. Ako vidno, identifikátor musí mať presnú formu - dva znaky z malej abecedy. Ak je toto splnené (v našom príklade je) je identifikátor hneď zapísaný do referencovanej premennej. Zároveň je pole skrátené a testovaný element je z poľa vyradený, aby už nevstupoval do nasledujúcej etapy analýzy.
Ak nie je zistená zhoda s regulárnym výrazom, je analyzovaný element vrátený späť do horeuvedeného poľa.

Nasleduje najzaujímavejšia časť routovania. Jednotlivé elementy poľa sú prechádzané v slučke a pri každom prechode sa testuje, či hodnota elementu odpovedá názvu nejakého existujúceho controllera, ktorý máme uložený v našom controller adresári. Tento kód však obsahuje zaujímavé rozšírenie. Najskôr sa totiž testuje, či hodnota elementu poľa neukazuje na nejaký podadresár v controllers adresári. Ak je toto splnené, je aktuálna iterácia ukončená a controller sa bude hľadať v tomto podadresári.

K čomu je to dobré? Umožňuje to hierarchicky usporiadať vaše controllery. Napr. môžete všetky contollery, ktoré súvisia s administráciou uložiť do podadresára controllers/admin a tieto budú volané zadaním URL http://smvcfw/admin/.... Toto opäť zvyšuje vašu produktivitu a manažovateľnosť aplikácie.

Držme sa však našej modelovej URL http://mvcdemo/en/news/archive/2008/june a plochej štruktúry adresára controllers.

Jazyk teda máme vyextrahovaný a žiadny podadresár news v štruktúre adresára controllers nie je. Z testovaného elementu poľa sa teda poskladá nový názov súboru - controllers/NewsController.php. Následne sa testuje prítomnosť tohto súboru. Predpokladajme, že tento súbor existuje. Hodnota elementu sa vloží do premennej pre identifikátor názvu controllera (priradí sa do príslušnej referencovanej premennej) a detekcia controllera sa ukončí (ukončí sa slučka analýzy).

Keďže pole je počas testu pri každej iterácii skrátené o aktuálny element a keďže už máme názov controlleru (iterácia bola ukončená príkazom break;), na konci cyklu má pole takúto štruktúru:

Hodnota nultého prvku je v ďalšom kroku uložená do premennej pre identifikátor názvu akcie (ACTION) a zvyšné prvky poľa sú exportované z metódy ako argumenty URL.

Toto všetko sa odohrá, ak router obdrží predpokladané parametre - na server príde požiadavka s predpokladanou URL. Zlí chlapci však môžu na server poslať URL so zámerne modifikovanými parametrami URL, alebo proste návštevník môže skúšať rôzne náhodne formy URL. Router sa s tým musí vysporiadať, preto sú do metódy parseUrl() implementované rozličné podvetvy kódu. Prejdime si ich.

Predpokladajme, že záškodník skúša modifikovať URL cca takto:
http://mvcdemo/asdasda/dasdas12313

Úvodná detekcia jazykovej mutácie neprejde, analýza teda postupuje ďalej. Testujeme prítomnosť adresára controllers/asdasda. Opať false výsledok, analýza vstupuje do finále, poskladá si názov súboru controllers/AsdasdaController.php a snaží sa overiť jeho prítomnosť. Ďalšie zlyhanie a router už vie, že na jeho vstup došla nezmyselná URL. Vykoná sa teda alternatívna vetva ktorá nastaví identifikátor názvu controllera na ErrorController(), identifikátor ACTION sa nastaví na index. Všetky nezmyselné výrazy URL sú uložené do premennej $args.

Inou situáciou je prípad URL bez parametrov:
http://smvcfw/

Slučka analýzy nemá nad čím iterovať (pole $parts je prázdne), preto ostáva premenná $controller prádzna. Tento stav je znakom, že kontrolu nad aplikáciou preberie IndexController() a jeho metóda index().

Posledným stavom, ktorý môže nastať je takáto URL:
http://mvcdemo/news/

Controller je nájdený, ale nemáme označenie akcie (pole malo jeden prvok, ktorý sme počas prvej iterácie analýzy skrátili na nulovú veľkosť). parseUrl() opäť situáciu odhalí a nastaví defaultnú ACTION index().

Za zmienku ešte stojí, že v názve akcie sú všetky pomlčky prevedené na podtržítka. Dôvodom je to, že v PHP nie je možné mať v názve metódy (funkcie) pomlčku. Ak teda router obdrží URL http://smvcfw/forum/post-delete, bude sa volať kód ForumController::post_delete().

----------------------------------

To by bolo z popisu na dnes všetko. Snažil som sa kód obkecať čo najpodrobnejšie a zároveň čo najstručnejšie (to druhé sa asi moc nevydarilo :o) ), verte kód nie je taký rozvlečený, ako vypadá v článku. Tú vatu okolo snáď niekto ocení. Nabudúce dokončíme popis kódu routra, vytvoríme si nejaké controllery, ukážeme si ako vyrenderovať prvé demo s využitím šablón. Sami uvidíte, že keď bude kostra frameworku hotová, následné písanie aplikácie už bude brnkačka (sľubované CMS-sko bude v tretej časti seriálu). Každopádne >> don't hesitate, feedback me :-)

Ešte malý súhrn toho ako by mal váš projekt po dnešnom diely vypadať:

pokračovanie nabudúce...