V Zendu se jede podle klasiky MVC s front controllerem, view helpery a spoustou nachystaných pluginů a bohaté plugin architektury. Pluginy mohou být jak pro action (v Zendu se tomu říká action helpery, základem je Zend_Controller_Action_Helper), tak pro celý proces, kterým odbavení požadavku prochází - Zend_Controller_Plugin_Abstract. Současně framework už v základu poskytuje velké množství helperů, které zajišťují redirectování, inicializaci view, context switching a další. Je to velmi propracovaný a přitom poměrně volně vázaný systém.

Nette je založeno na MVP, P není tedy Controller, ale Presenter, který může obsluhovat více stránek. Proces dispatchnutí požadavku je jednodušší než v Zendu, ale co je horší, není zajištěna dobrá separace jednotlivých částí procesu odbavení požadavku a velmi špatná možnost pluginování. Nette obsahuje podivnou třídu Application, která umožňuje pověsit se na nějaké události, ale o přehlednosti plugin architektury jako je v ZF se nedá vůbec hovořit. Ono by se na první pohled mohlo zdát, že koncept Presenteru a Controlleru je v podstatě stejný, zejména proto, že presentery v Nette mohou být multiaction, ale opak je pravdou. Existuje zásadní rozdíl v práci s Controllery v Zendu a Presentery v Nette. Presenter je totiž od toho aby se dědil - viz. doporučení od autora frameworku, ale Controller, se naopak dědit nemá (může, ale nedoporučuje se to), společné prvky controllerů v aplikaci se zajišťují přes pluginy. Taková architektura je mnohem flexibilnější, na dědičnosti závislém presenteru se tak rozsáhlý systém v podstatě nedá postavit.

Presenter architektura v Nette naopak poskytuje jednu velmi pěknou vlastnost, kterou zřejmě nikde jinde nenajdete - komponenty. Funguje to velice pěkně, navíc s built-in podporou ajaxu a factory metod na komponenty. U Zendu se komponenty dají nahradit částečně view helpery, ale tak efektní to není, "widgetizovaný" web se tak dá s podporou presenterů postavit mnohem lépe. S odstupem času mi ta "ajaxovost" komponent už tak pěkná nepřijde, myslím si, že éra posílání a substituce kousků html je překonaná záležitost, i když pro oživení klasické webové presentace je to pořád asi nejčastější způsob.

Nette také obsahuje poměrně bohatý šablonovací systém, který je v podstatě nutné používat zejména kvůli komponentám a snippetům, bez nich by to nebylo ono. Naopak v Zendu jsou šablony klasické PHP soubory, kde velkou roli hrají view helpery, které umožňují tvořit znovupoužitelné části pro view a zjednodušit tvorbu šablon. Opět je poskytováno obrovské množství view helperů na všechno možné. Klasické PHP v šablonách velmi pěkně zapadá do MVC architektury a potřeba nějakého složitějšího šablonování tak v Zendu není.

Routing je Nette a v ZF dost podobný, v Nette je možná malinko propracovanější, ale na 90% věcí vám vyhoví oba zhruba stejně. ZF má podporu RESTu, Nette zatím ne.

Nezmínil jsem třeba takové věci jako formuláře, které jsou např. v Nette díky komponentové podpoře pěkně řešené a používají se lépe než v Zendu, ale jak jsem napsal, soustředil jsem se hlavně na MVC.

Tady už je to v podstatě nesrovnatelné i když autor se to snaží vyvracet. Je pravda, že Zend Framework je tažen především třemi full time vývojáři (spíše dvěma, že by Alex kromě Zend_Pdf nějak zásadně do frameworku přispíval …), ale pořád je o 100% více než Nette, kde ač se po různu vynořují magická spojení jako Nette Foundation, je to celé v podstatě na D. Grudlovi. No, spíše o 200% až 300% více, protože Zend vývojáři se opravdu věnují programování frameworku a nepatlají se tolik s věcmi okolo (design, wiki, bugtracker, školení, webcasty, manuál …), v tom jim firma poskytuje zázemí.

Na ZF je krásně vidět, jak do projektu zatáhl komunitu. Od začátku jasná pravidla pro komunitní vývoj komponent a jejich pravidelné zařazování do frameworku. Pak se přidaly pravidelné bug hunt days - to je naprostá bomba a klasická ukázka komunitního vývoje, dále delegování odpovědností za vývoj jednotlivých komponent a výbor expertů z řad komunity, která posuzuje framework jako celek je další nová věc. Nic takového v Nette není, všechno jede pod diktátem autora a bez něj v podstatě všechno stojí. Minimálně bug hunts by potřebovalo Nette jako koza drbání, ale je tu problém s testy, viz. dále.

Další velké koncepční problémy byly učiněny hned na začátku vývoje Nette. První byla neexistence testovaní a druhá nesmyslná "cool" podpora php 5.3 v době, kdy ani php 5.3 nebylo reálně použitelné. To vedlo k tomu, že Nette mělo naprosto strašné zdrojové kódy nutné pro generování 5.3 verze a doteď se tam vyskytují třídy pro kompatibilitu s 5.2. Navíc od začátku se poskytovala a preferovala neprefixovaná verze frameworku pro 5.2, což je z pohledu pojmenování a kolizí naprostá hrůza.

Zend od začátku zvolil klasiku PHPUnit a s 5.3 si hlavu nelámal. Prefixoval třídy klasicky ve stylu PEARu. Když nastala doba, učinil se stávající framework v pohodě kompatibilní s 5.3 a začalo se pracovat na nové major verzi. Naprostá pohoda, bez konfliktů a hromady ušetřené práce.

Ohledně testování v Nette se snad ledy hnuly a konečně i Nette bude mít testy pro PHPUnit, což by snad nakonec mohlo dospět i k tomu, že by mohlo dojít na ty bug hunt days . Sice se autor pokoušel o nějaký svůj koncept testů, ale jedině dobře, že mu to nakonec snad zametli pod stůl.

Přitom komunita je to, co by z Nette mohlo udělat přednost, je totiž pravda, že se kolem něj nabalila velká skupina především mladých a velmi schopných PHPčkařů a zapojit je více do vývoje frameworku by do frameworku přineslo naprosto novou kvalitu, spolu se standardním testováním by to neměl být problém. Jako příklad můžeme vzít šablonovací systém. Jak jsem již uvedl, Nette má svůj, je poměrně propracovaný a docela dobře se používá. Nicméně pod povrchem je to makroprocesor okolo reg. výrazů. Jakub Kulhan, jeden z těch, kteří se okolo Nette motají, má velmi dobré znalosti ohledně kompilátorů, lexerů, parserů, … a chuť něco takového udělat i pro Nette šablony. To by byl naprosto revoluční počin a posunul Nette šablony na naprosto jinou dimenzi. Minimálně za pokus by to stálo a takových lidí se motá okolo Nette více.

Další věc je verzování. U Zendu máte jistotu že pokud nepřijde major verze, tak se BC breaky nedělají a všechno jede jak má. Má to jasnou koncepci, která je možná trochu rigidní, ale pro udržování rozsáhlejších projektů nutná.

Naproti tomu Nette si klidně i do údajně stabilní větvě 0.9 švihá i zpětně nekompatibilní změny v API a to dost často velmi zásadní. Sice se to autor snaží vylepšovat tím, že do fóra napíše BC break, ale i tak se to s pojetím ZF nedá srovnat a pro reálné nasazení je tak každá taková "stabilní" verze dost velká komplikace.

Další věc je magičnost a WTF faktor. Ten je u Nette kupodivu mnohem větší než u Zendu a není to jen šablonami. Troufnu si tvrdit, že tenhle rozdíl se bude s příchodem ZF 2.0 a Nette 1.0 zvětšovat. Nette si dost zakládá na magických konstrukcích a různých nápravách a vylepšeních PHP jako jazyka, Zend se o nic takového nesnaží a naopak se magičnosti bude snažit zbavit. S tím souvisí i poněkud zavádějící slogan "Nette Framework is designed with simplicity in mind". Nenechte si mýlit rozsahem ZF, podle mých zkušeností je zvládnutí základu Zend Frameworku pro začátečníka jednodušší než Nette.

Ačkoli už tu Nette nějaký ten pátek je, pořád bych se při rozhodování, co zvolit jako zásadní firemní framework, pro něj nerozhodl. Naopak jako framework pro nějakého člověka, který dělá zakázkové weby, se Nette hodí velmi dobře. Počkejme si, co přinese verze 1.0 a jestli se Nette opravdu otevře více komunitě. Uvidíme také, jak se frameworky vypořádají s integrací nějakého ORM řešení, které by přidalo alespoň nějakou podporu modelů.

Již někdy v prvním čtvrtletí se hlavní vývojáři Zend Frameworku po vlně různých dotazníků a průzkumů dohodli, že verze 2.0 Zend Frameworku, která dle dohody jako první verze po dlouhých letech může porušit zpětnou kompatibilitu, pojede jen na PHP 5.3 a bude tak moci naplno využívat všech nových možností, které PHP 5.3 nabízí - jmenné prostory, anonymní funkce, goto …. Začalo se na tom dělat ve stávajícím svn, ale za nějaký čas se dohodl přechod na dnes tak populární git. Takže ZF 2.0 už bude vyvíjen v gitu s hlavním repositářem na serverech Zendu (http://git.zendframework.com), mirrorovaným na githubu. Na wiki už se vyklubalo trochu dokumentace a Matthew napsal i nějaký ten článek a zprávu do mailing listu, jak to pokračuje a co se chystá.

Je pravda že změna to bude dost masívní, ale pořád se asi přesně neví jaká. Určitě lze čekat velké změny ve věcech MVC, databází a PDF, to jsou hlavní věci, které mají full time Zend Framework vývojáři na starosti. Mimochodem jsou tři - Matthew Weier O'Phinney, Ralph Schindler a Alexander Veremyev. Právě Matthew jako vedoucí projektu nakonec nastínil roadmapu spíš ve smyslu koncepce, nikoli už konkrétních změn. Důraz bude kladen na tyto věci:

1. větší důraz na interface - umožnit vývojářům co největší volnost v pluginování, umožnit dobrou dependency injection všude, kde to dává smysl.
2. zbavit se magie - ve frameworku se na pár místech intenzivně využívá magických metod __get(), __set() … To by mělo být zrušeno a nahrazeno explicitními zápisy, bude to mnohem přívětivější pro IDE a rychlejší, magic methods jsou v PHP dost velká brzda.
3. pravděpodobně se zredukuje počet komponent - framework je dost nabotnalý a jsou komponenty, o které se nikdo moc nestará. Byl už ustaven nějaký "výbor", který by na to měl dohlídnout a sledovat to i nadále.

Už teď je toho spousta hotová, celý framework už se převeden do namespaces včetně hromady testů, průběžně se importují bugfixy ze stávající verze, lidé už rozjeli práci na komponentách, které mají na starosti pro verzi 2.0. Až mě to překvapuje, jak to sviští dopředu, no podívejte na ten github, budete koukat. Jen to převedení na namespaces bylo asi dost maso, myslím že většinu toho zmáknul Ralph s pomocí nějakého poloautomatizovaného nástroje, který také udělal.

Zatím mám z toho dost dobrý pocit, samozřejmě mezitím vychází dál bugfix verze pro 1.10 a připravuje se 1.11, která se dál jede v svn. Uvidíme, jak jim to půjde dál.

Mimochodem, trochu jsem upravil zdrojáky blogu a krásně to jede i na poslední verzi ZF - pro zájemce opět na stránce s informacemi. Moc dobrou práci odvádějí lidé okolo ZF, maximální spokojenost.

Docela mě překvapilo, že moc lidí neprotestovalo ohledně konce aktivní podpory řešení chyb pro řadu 5.2. Není to sice úplný konec podpory 5.2, security patch asi nějaký bude, ale v reálu je lepší se soustředit na uprade na 5.3. Uvidíme, jak to bude dál, ale zatím nic nenasvědčuje tomu, že by se toho mělo moc změnit. V našich luzích a hájích v podstatě ticho po pěšině.

Jinak trunk PHP už toho poměrně dost spolkl, nějaké performance patche, dost z traitů a hlavně byl dost humbuk okolo kontroly primitivních typů v parametrech funkcí, jakmile Derick docela starý Iljův patch commitnul, tak se rozpoutala masivní diskuse. Zatím to tam pořád je, včetně testů, takže teoreticky se to může v nějaké z příštích verzí PHP objevit, mezitím vznikly na wiki další návrhy co s tím, tak uvidíme co se z toho nakonec vyklube.

Celkově se mi zdá, že už pomalu začíná být problém vyznat se v tom, co je v trunku, co v 5.3 a hlídat bugfixy, to byl asi také jeden z důvodů konce aktivní podpory 5.2.

A ještě jedna velmi příjemná změna v trunku, patch na podporu syntaxe referencování polí při volání funkce je už také commitnutý. Takže možná brzy už bude možné psát

function fruit () {
  return array('a' => 'apple', 'b' => 'banana');
}
 
echo fruit()['a']; // apple

Jde o podstatné rozšíření a vylepšení stávajícího SAPI pro CGI/FastCGI. Jednak dojde k oddělení kódu, který byl zatím pro CGI i FastCGI společný a hlavně process management FastCGI bude mít mnohem více možností, vylepšené logování atd. Souvisí to zejména s tím, jak se PHP začalo masivněji používat s lightweight servery jako LightHTTPd, ngingx a asi i IIS na Win.

• Přijaty byly implementace dvou nových hashovacích funkcí (prý Jenkins's one-at-a-time hash a FNV-1 - netuším moc o co jde).
• default_charset bude nyní utf-8
• Lepší podpora pro detekci zend rozšíření v reflections.
• Podpora key-value databáze Tokyo Cabinet via ext/dba.
• Odstranění fallback construktoru.

Odstranění fallback construktoru je poměrně zajímavá věc. Jeden ze tří full time Zend Framework vývojářů (zkuste si tipnout, kteří to jsou ) se zmínil o problémech při přechodu Zend frameworku na namespaces. Problém se týká kódu

namespace Foo\Bar;
 class Filter {
  public function __construct() { /* construct stuff */ }
  public function filter($value) { /* return filtered */ }
 }

Ono totiž pokud konstruktor není v PHP 5 definován přes __construct, tak se PHP shání po funkci, která se shoduje s názvem třídy. O téhle PHP 4 BC jsem tedy vůbec netušil. Bylo to uděláno zejména z důvodu hromady PEAR kódu. PHP dokonce vyhodí u výše uvedeného kódu notice. Další sranda přijde na řadu pokud si uvědomíte, že PHP je case insensitive u názvů funkcí. Nově by se tedy v namespaces neměl uplatňovat tenhle fallback pro konstruktor.

Hodně se rozjela diskuse o těchto tématech

• podpora vláken - konečně by se z PHP mohl stát univerzálnější prostředek, zatím ale není jasné, jakým směrem se vydat. Zda se odrazit od stávajícího TSRM nebo se začít hrabat v semaforech, lockování atd. Moriyoshi (oniguruma san, mbstring master ) má fork php, který přináší podporu threadů do userspace.
• podpora pojmenovaných parametrů pro funkce
• horizontální kompozice - traits/grafts

Zatím se nic konkrétního nerýsuje, vetšinou to jako první dost smete Rasmus, ale naštěstí jsou tam i ostatní.

Je ale poměrně reálné, že ještě letos bychom se mohli dočkat nového php 5.x, kde by se mohlo pár nových užitečných věcí objevit.

Jako první krok by bylo vhodné stáhnout si zdrojové kódy aktuální verze PHP a přeložit si je klasickou kombinací

$ ./configure
$ make
$ make install

./configure --help vám sdělí množství voleb pro různé moduly, co zvolíte je na Vás. Samozřejmě můžete používat různé php-dev balíčky vaší distribuce a nainstalovat si tak pohodlně jen hlavičkové a .lib knihovny, ale doporučuji raději si PHP zkompilovat ručně někam do /usr/local apod.

Po make install budete mít nainstalovánu i podporu pro tvorbu a instalaci rozšíření pomocí skriptů phpize a pecl. Navíc zdrojáky PHP budete potřebovat stejně, protože v nich budete hledat jak o život, jak se co vlastně dělá.

Takže máme nainstalováno. Teď něco k tomu, z čeho se extenze skládá. Většinou jde o 3 a více souborů. Typicky je to

1. extname.c - vlastní zdrojový kód pro naše rozšíření
2. php_extname.h - hlavičkový soubor pro naše rozšíření
3. config.m4 - trochu shellu a m4 vám zajistí, že si vaší extension všichni zkompilují pomocí staré známé výše popsané trojkombinace.

Extenze můžete psát jak v C, tak v C++. C drtivě převažuje. Exteze v C++ byste spočítali na prstech jedné ruky, většinou jde o wrappery nad C++ knihovnami. Jak extenze vlastně fungují a co v PHP představují? PHP core se skládá v podstatě ze tří částí:

• Zend Engine
• SAPI vrstva
• Core rozšíření

Zend Engine obsahuje takové ty všemožné kompilátory našich skriptů do bytecode, a virtuální stroj, který ho interpretuje. Dále pak poskytuje základní API pro extenze, takže manipulaci s pamětí, manipulace s proměnnými, funkcemi, třídami, základními typy. Tuhle část budete v rozšíření velmi často používat.

SAPI vrstva zprostředkovává komunikaci s prostředím, ve kterém PHP běží. Může to být Apache Modul, IIS modul na Windows, CGI, nebo commnad line (CLI) SAPI. Poskytuje také stream přístup k I/O, stará se o save_mode, open_basedir.

Core rozšíření tvoří velkou část PHP. Když si stáhnete zdrojové kódy PHP, tak všechno co je v adresáří ext je rozšíření. Takže funkce na práce s poli, řetězci, datumy, matematické funkce, databáze, atd. To vše je v PHP jako rozšíření.

Rozšíření se dá charakterizovat zjednodušeně jako seznam funkcí, kterým Zend Engine předá řízení, když při vykonávání skriptu narazí na volání, které spadá do nějaké extenze. Až tahle zkompilovaná funkce v extenzi doběhne, tak vrátí hodnotu zpět Zend Engine a ten už s ní naloží dále tak, jak mu velí uživatelův skript. Většinou si jí uloží do proměnné a za chvíli zavolá další funkci z nějaké extenze atd.

Proč vlastně psát nějaké nativní extenze a co k tomu lidi vede?

• Wrapper nad nějakou C/C++ knihovnou. Tady je to asi jasné. Máme nějakou pěknou céčkovou knihovnu a přihlásí se nám pár lidí, že by jí rádi využili i z PHP, tak holt budeme muset napsat rozšíření. Spousta příkladů se válí v PECLu, další tisíce různě po internetu.
• Potřebujeme mít nějakou část naší aplikace opravdu rychlou. PHP je jak známou dost velký šnek co se týče rychlosti vykonávání kódu skriptů. Hůř už na tom bývalo jen Ruby a to se z příchodem Ruby 1.9 také změnilo. Tohle byl určíte důvode pro vznik spousty rozšíření u Yahoo a Facebooku.
• Jen tak, když už vám to PHP leze vším možným a trochu céčka by nezaškodilo .

Proč se vlastně extenze píšou více v C a nikoli v C++ když C++ toho nabízí mnohem více? Důvod bude asi ten, že takové ty základní věci, se kterými se v C pracuje ne úplně dobře (řetězce, pole) jsou součástí Zend Engine. Dále pak každá extension nemusí pouze rozšiřovat PHP směrem do user space, ale také směrem k extension api, takže její funkcionalitu můžete využít přímo i ve své extension bez volání oklikou přes Zend Engine. Když si tedy vezmete Zend Engine jako základ pro práci s poli a řetězci a extensions v core, tak pak není moc důvodů používat C++.

Jinak samotné extension api je velmi konzervativní a od PHP 4 se příliš nezměnilo, jen se rozšířilo o objekty. Něco většího přijde až s PHP 6, ale to je ještě někde za horami. Jinak samozřejmě i PHP třídy a objekty se v extension píší v C, jen je tam trochu více maker. Obecně je psaní extension zejména ve stylu "všude nějaké makro", ale tak to bude asi ve všech jazycích, které mají API do C.

Příště možná něco k základu modulu a konfiguraci.

V prvním dni se probíralo hlavně unicode. Spousta věcí na Unicode ještě není hotova. Velký kus práce je třeba udělat na PDO, některé api access knihovny mají přímo zabudovanou podporu pro unicode, jiné ne. Databáze (resp. jejich dřívější verze), jejichž access API nemají podporu konverze znakových sad asi nebudou vůbec do PDO zahrnuty. PDO na unicode obecně není připraveno.

Další věci související s unicode:

1. PHP parser sám o sobě nerozumí UTF-16 kódování
2. Problémy jsou zatím s podporou unicode u globálního pole $_SERVER, cookies, sessions, filter extenze.
3. Není uspokojivě vyřešena normalizace názvů tříd a identifikátorů.
4. String konverze uvnitř Zend Engine nejsou optimální, týká se i operátoru []

Další věci už s unicode nesouvisí. Stačí shrnutí v bodech.

1. PDO bude preferovaným DB interfacem pro PHP. Z ostatních by měly zůstat mysql, mysqli, pgsql, sqlite3, oci8.
2. Extenze mbstring nebude umožňovat přímou integraci s enginem (zástupce strlen apod.), ale bude dále součástí core PHP.
3. Je potřeba fixnout spoustu valgrind hlášek (memory leaks) a nefunkční testy.
4. Testovací aplikace pro PHP 6 budou Wordpress, Drupal, Wikimedia a frameworky ezComponents, Zend Framework.
5. Short tags definitivně zůstává.
6. Více tlačit na používaní filter extenze, lidi to moc neznají a nepoužívají.
7. Rezervovat si namespace "PHP" .

A teď zajímavější věci:

1. Začíná se uvažovat o case sensitive pro identifikátory - názvy tříd, proměnné atd.
2. Traits (kompozice tříd nahrazující vícenásobnou dědičnost), pokud bude reálně použitelný patch.
3. Podpora vynucení návratového typu funkcí a s tím související podpora skalárních typu (int, string, bool) u vynucování parametrů funkcí. Opět je třeba funkční patch od komunity.
4. Řešit callback podobně jako jsou teď closures (internal třídou), vylepšit fungováni closures s třídami.
5. Možnost automatického volání konstuktoru předka.
6. Vyhazovat exception pro nevalidní parametry při volání funkcí.
7. Magic metoda __cast() pro přetypování.
8. Read only pro členské proměnné tříd a možná normální proměnné, urychlilo by to zejména věci ohledně DB.
9. Objekty třídy ArrayObject, resp. ArrayAccess by měly být akceptovány všude, kde je akceptováno klasické pole.
10. Něco na způsob safe_mode, ale lepší
11. Function call chaining, když už je funkce plnohodnotným typem/objektem - f()() - pokud f() vrací funkci.
12. Array dereferencing, pokud funkce vrací pole - f()[0].
13. Property ve stylu C#, syntaxe asi ve stylu:

  class Foo {
     public $bar
         getter { return $this->bar; }
         setter { $this->bar = strtolower($value); }
     ;
   }
 

Je RFC, ale patch zatím žádný.

1. Podpora vnořování ini souborů.
2. Statické třídy - pokud bude nějaký rozumný use case a patch.
3. Striktní třídy - zakázat vytváření dynamických členských proměnných (nepovolí $this→foo = bar;), patch zatím žádný.
4. Odstranění final z členských proměnných Exception tříd.

Některé věci z tohoto by se možná mohly objevit ještě v PHP 5.

Na php wiki jsou i některé další věci, ale to výše zmíněné je asi nejzajímavější. Co na to říci? Zní to zajímavě, ale bůh ví, kdy se alespoň zlomku toho v PHP dočkáme a jak to ovlivní "pomalost" PHP, a hlavně jak bude zajištěna zpětná kompatibilita .