Byl jsem zendařem. Už je tomu asi rok a půl zpátky. Hledal jsem vhodný PHP framework, který by mi ulehčil práci při psaní webových aplikací. Tenkrát jsem se rozhodl pro Zend Framework hlavně z toho důvodu, že ho vyvíjeli autoři PHP. Říkal jsem si, že asi bude psán kvalitně. Výběru napomohla také skutečnost, že frameworků tenkrát ještě moc nebylo, nebo o nich aspoň nebylo tolik slyšet. To až v poslední době se s nimi roztrhl pytel. Pamatuji si, byla to verze 1.5, kterou jsem začal studovat. Naivně jsem si vytiskl celou dokumentaci. To se ještě vešla na pouhých 670 stránek. K tomu jsem si koupil knihu, která se vázala k verzi 1.5, a začal jsem se vzdělávat.

Přechod na verzi 1.6 byl jediný přechod, který jsem stihl plně pochytit. S přechodem na verzi 1.7 mi toho hodně proklouzlo a další přechody už jsem sledovat nestíhal. Zend Framework byl hodně rozšířen do všech směrů a stalo se z něho obrovské neovladatelné monstrum. Kde zůstala ta základní kostra verze 1.5? S vytisknutou dokumentací a zakoupenou knihou si teď můžu tak akorát tak… Nezastavitelný bezmyšlenkovitý vývoj mě začal na frameworku vadit. To když začínáte s projektem na aktuální verzi frameworku, museli byste projekt před dokončením pořád upravovat na tu novou a novou verzi, abyste jeli pořád na té aktuální. Framework má přece práci ulehčovat, ne ztěžovat. Občas se najdou i celkem zásadní změny jako např. psaní bootstrapového souboru pomocí objektu třídy Zend_Application nebo třeba zavedení URL helperů. Podle mého názoru by takové věci měly být stanoveny před počátkem vývoje frameworku. Jsou to základní kameny, na kterých by se mělo začít stavět. Kromě toho mě odradila rychlost frameworku. Je samozřejmé, že se to nabalování nových vlastností muselo někde projevit. Jednoduše Zend Framework už nesplňuje moji ideologii frameworku. Netuším, proč se vývojáři snaží, aby uměl úplně všechno.

V tomto ohledu se mi zalíbil Nette Framework, který mi byl doporučen Tomášem Jukinem. Má totiž jasně vytyčenou myšlenku, se kterou ho David Grudl píše. Fascinující je, že je framework vyvíjen pouze jediným člověkem, který si dle vlastního uvážení řekne, ano, tohle tam dám nebo ne, tohle si tam dodej sám! Líbí se mi, že se framework nerozrůstá do maximálních rozměrů a zůstává jednoduchý, jasný a srozumitelný. Mimo to využívá rozhraní a kvalitního objektového přístupu. Další plus u mě získal tím, že nemá knihovnu pro práci s databázi a tak si v klídku můžu dodat mnou zvolený ORM nástroj a stavět na něm celý model. I když mám s tímto frameworkem zatím více méně nulové zkušenosti, tak splňuje moji ideologii frameworku a vypadá to, že budeme kamarádi!

Chtěl jsem vám jenom oznámit, že přecházím od něčeho velikého s malou myšlenkou k něčemu malému s velkou myšlenkou, od Zend Frameworku k Nette Frameworku.

K tomuto příspěvku mě dotlačilo toto téma na českém ZF fóru, ale především tři noci prosezené u psaní a konečné formulace bootstrap file pro projekt My Town Game, o kterém vám v blízké době povím něco více. Zakrývám si oči pravou rukou, otáčím se a ulehám do kouta. Harvejsi, měl jsem bootstrap tak veliký a nepřehledný, že jsem byl donucen ho přepsat do nekoncepční třídy s originálním názvem Application. Kromě tebou zmiňované přehlednosti má nekoncepční třída bootstrap filu ještě takovou výhodu, že se u každé metody dá napsat pěkný phpDoc komentář, který mi vždy připomene, co že se to teď vlastně louduje. Takže se ti předem omlouvám a nedivím se, proč je kolem vývoje třídy Zend_Application takové vzrůšo. Dovolil bych si tedy tvrdit, že pokud se jedná o větší ZF projekt, jehož bootstrap file by byl v základním znění nepřehledný, je výhodné, naházet to všechno do nekoncepční třídy. Musím tedy přihmouřit své OOoči…

Ehm, a co že to ta nekoncepční bootstrap třída vlastně je? Představte si, že váš bootstrap file index.php (www/index.php) bude vypadat následovně a že statická metoda s divokým názvem run() se postará o všechno, co je třeba:

Přesuneme se dále do třídy Application (application/Application.php), která implementuje návrhový vzor singleton, protože aplikaci přece nebudeme spouštět vícekrát najednou, a to i kdyby měla Sofie S. zůstat sama samotinká. Tato metoda potom ve zkratce zavolá po sobě seřazenou většinu loudovacích metod, které jsou ve třídě dostupné. To je kalibr!

Všechny takto volané metody jsou soukromé a vykonávají část bootstrap funkcionality, která se takto dá velmi jednoduše dokumentovat pomocí phpDoc u každé této metody a samozřejmě také rozšiřovat novými metodami. Třída pak může obsahovat ještě pomocné soukromé metody nebo veřejné metody pro přístup z pluginů nebo z controllerů. Na ukázku ještě detail metody pro připojení do databáze:

No a konečně disponuje nekoncepční bootstrap třída výhodou, že si může všechno zapamatovat ve svých členských proměnných a o použití Zend_Register si můžete nechat během teplých letních nocích jen zdát. Následující kód zobrazuje příklad deklarace členských proměnných.

Vše co je libo je prostě přístupné a tak si ještě nakonec shrneme výhody a nevýhody nekoncepční bootstrap třídy. Mezi výhody patří:

• přehlednost
• dokumentovatelnost
• rozšiřovatelnost
• přístupnost
• znovupoužitelnost

A mezi nevýhody patří:

• nekoncepčnost
• rychlost (zanedbatelná)

Stejně jako jsem v článku o kategorizaci přístupu k tvorbě PHP projektu neodsuzoval žádný z přístupů, tak ani v tomto případě netvrdím, že některý způsob tvorby bootstrap filu je obecně nejlepší. Proč si myslíte, že to Zend Framework nechává otevřené a předává tuto starost na samotné programátory?

Kdo by neznal čím dál více se rozšiřující serverový skriptovací jazyk s nedomyšlenou rekurzivní zkratkou PHP, který je známý nejen jako výukový trenažér pro amatérské webmastery. Statistiky ukazují, že dnešní hostingový program bez podpory PHP je buď ten nejlevnější nebo s chybou v metrixu. S příchodem páté verze se v PHP objevuje objektová syntaxe a PHP se mění z výukového trenažéru na kvalitní objektový serverový skriptovací nástroj, se kterým lze dělat velké věci. Protože PHP projekty z našeho světa jen tak nezmizí, rozhodl jsem se sepsat článek, který kategorizuje a odděluje od sebe jednotlivé přístupy tvorby PHP projektů.

A: Strukturální přístup

Každý, kdo zná PHP, se ve svém životě setkal s koncepcí PHP projektíku založeného na statických stránkách, jejichž obsah se přepíná pomocí jediného GET parametru a jazykového konstruktu include. V lepších případech je využita databáze nebo zápis do souborů. Takovýto projekt využívá pouze strukturálních funkcí, nejčastěji implementovaných přímo v PHP.

PHP projekt založený na strukturálním přístupu obvykle postrádá logiku a je nejčastěji založen na práci s textem. Vůbec nechci tento přístup odsuzovat, naopak, takový přístup disponuje největší perzistencí v porovnání s dalšími přístupy, ale hodí se jen na malé, velmi jednoduché projekty.

B: Objektově strukturální přístup

Ne nadarmo se řadí PHP mezi multiparadigmatické programovací jazyky. Hlavně několik posledních let se začíná rozrůstat síla PHP frameworků, které programátorům uzpůsobují a mnohdy ulehčují jejich programátorský styl. Z těch nejznámějších zmíním Zend Framework, CakePHP nebo český Nette Framework. PHP frameworky jsou nejčastěji psané v objektovém kódu a založené na MVC architektuře.

Při tvorbě PHP projektu, který využívá některý z objektově psaných frameworků, je kód projektu psaný samozřejmě také objektově. Důležité je, uvědomit si, že pokud je objektový kód, nemusí být objektová i logika. V objektově strukturálním přístupu aplikace logiku postrádá a z pohledu architektury je stále strukturální. Aplikace pouze plní za sebou seřazené a do tříd obalené metody. Takovýmto přístupem jsou koncipovány středně složité projekty, které vyžadují složitější komponenty (například z knihovny frameworku) a usnadňují práci programátorovi, mnohdy bohužel na úkor perzistence.

C: Pravý objektový přístup

Pokud chceme programovat náš PHP projekt opravdu objektově, musíme naučit systém přemýšlet. Proto v pravém objektovém přístupu využíváme nejen objektové syntaxe, ale i objektové logiky, na které je postavena systémová architektura. Nejen že systém využívá objektového kódu některého frameworku, ale pracuje i s našimi doménovými objekty, které tvoří problémovou doménu projektu. Tyto objekty tvoří model MVC architektury a jsou nejčastěji mapovány do databází pomocí některého ORM nástroje, který může být integrován přímo do frameworku.

Takový přístup bychom měli zvolit, pokud se jedná o složitější PHP projekt. Vzniklý systém nevyniká perzistencí, proto je nutno ho co možná nejlépe optimalizovat (databázové dotazy – kvalitní ORM, dobře navrhnutá architektura, cache…), ale vyniká správností objektového konceptu.

Musím ještě podotknout, že žádný z přístupů není nejhorší a žádný nejlepší, protože vždy záleží na konkrétním PHP projektu. I když osobně preferuji pravý objektový přístup, tak se mi zamlouvá i strukturální přístup pro jednoduché projekty. Nejmíň se mi ale zarývá pod nehty objektově strukturální přístup, protože nejsem schopný kloubit správný objektový koncept a logicky strukturální přístup. Je to jako duševní bariéra. Ale každému vyhovuje něco jiného.