Využití frameworku a mikroformátů při tvorbě webové prezentace

a <span>, nebo je využito, dejme tomu, značky pro odstavec

. Funkcionalitu mikroformátu to nikterak neovlivní. HTML struktura je tedy plně v režii kodéra, který se na mikroformáty nemusí při stavbě stránky takřka vůbec ohlížet. Nicméně, pokud již dopředu ví, že na stránce budou mikroformáty použity, proč s tím alespoň trochu nepočítat a mírně si neulehčit jejich pozdější implementaci do struktury stránky?

3.3.4 Pravidla pro psaní mikroformátů Jak bylo uvedeno, mikroformáty jsou sice nezávislé na použitém značkování, ale přece jen se řídí několika málo pravidly, které je dobré při tvorbě struktury dokumentu brát v potaz: •

hlavní vlastnosti je zakázáno kombinovat s tzv. podvlastnostmi

•

značkování je druhořadé, je ovšem silně doporučeno držet se pravidel POSH

•

názvy vlastností jsou jasně dané a jsou case-sensitive

.: 12 :.

•

třídy pro mikroformáty lze využít pro kaskádové styly, není třeba zavádět nové [2]

3.3.5 Vlastnosti a podvlastnosti mikroformátů Právě tato dvojice je základním stavebním kamenem mikroformátů. Jeden bez druhého se téměř neobejdou, přesto je nelze spojovat a kombinovat na stejné úrovni. Vlastnost (property) ze své podstaty buď přímo identifikuje část daného mikroformátu nebo jeho popis rozšiřuje, či doplňuje. Vlastnosti je také nutné rozdělit na povinné a nepovinné, což odvisí od specifikace konkrétního mikroformátu. Podvlastnost (sub-property) pak analogicky rozděluje vlastnost na více specifických částí a má spíše upřesňující charakter a slouží k „poskytnutí co nejlepšího kontextu“. [23] Typickým příkladem je pak identifikace celého jména v mikroformátu hcard:

Jak je vidět z příkladu, mikroformát hcard (značen jako vcard) obsahuje právě jednu vlastnost friendly name, ve zkratce označenou jako fn, která identifikuje údaj o jméně. Má však ještě doplňující vlastnost n, jež je právě onou doplňující vlastností, která v tomto případě udává, že obsah tohoto elementu bude obsahovat ještě podvlastnosti upřesňující údaje o jméně (např. křestní jméno, druhé jméno, tituly, příjmení, ...)2. Nadřazená vlastnost fn pak obsahuje tři elementy tvořící její podvlastnosti, a to jak z hlediska kódu, tak samotné sémantiky. Uvedené podvlastnosti given-name (křestní jméno), additional-name (prostřední jméno) a family-name (příjmení) lze doplnit ještě údaji o titulech (honorific-prefix a honorific suffix). Zde je možné namítnout, že se nejedná o vyčerpávající výčet všech možných subvlastností a například u nás nemálo využívaný přídomek zde chybí. Tento zdánlivý nedostatek však specifikace vynahrazuje povolením použití subvlastnosti additional-name vícekrát za sebou. To stejné potom platí pro obě označení titulu. Ne však pro podvlastnosti given-name a family-name, které je dovoleno použít pouze jednou. [23]

2

Ze specifikace lze vyčíst, že doplňující vlastnost n je možné vynechat, v případě že vlastnost bude obsahovat právě dvě slova.

.: 13 :.

3.3.6 Mikroformáty vs RDF V historii mikroformátů bylo zmíněno, že společnost W3C dala před šesti lety od mikroformátů ruce pryč a poslala Tanteka Çelika do jakéhosi tvůrčího „vyhnanství“. Zatímco si Çelik stál za svým objevem a následoval a uváděl v praxi vizi mikroformátů, W3C se vydala vlastní cestou. Vytvořila svoji alternativu k odvrženým mikroformátům, tzv. RDF (Resource Description Framework) neboli systém popisu zdrojů, kterým mírně opožděně – v roce 2008 – reagovala na rychle expandující technologii mikroformátů. Základní myšlenkou RDF, respektive rozšíření RDFa je, stejně jako u mikroformátů, obohatit webová data o širší sémantiku. Co se liší, je provedení zápisu. W3C se rozhodla využít silný nástroj technologie XML – jmenné prostory (namespaces). Díky nim pak může zápis RDF do HTML entit dostat konkrétní podobu:

Je možné si všimnout jisté podobnosti se zápisem mikroformátů. A jsou to právě názvy vlastností a podvlastností – zde ADR a Street, Locality a Postal-code. Ovšem zápis samotných hodnot vlastností a podvlastností je zcela odlišný. RDF využívá již zmíněných jmenných prostorů k identifikaci daných údajů. Navíc zavádí nové klíčové atributy HTML entit – property, role a about: •

property – v podstatě zastává roli podvlastnosti u mikroformátů

•

role – analogicky koresponduje s mikroformátovou vlastností

•

about – určuje URL adresu, ke které daný RDF směřuje (má význam zejména při více výskytech vstupů či událostí, např. seznam adres, či knih) Obě ztvárnění zápisů metadat mají své výhody a samozřejmě svá úskalí. Místo jejich výčtu lze zmínit pouze jednu, a to velmi podstatnou nevýhodu RDF – využití pouze ve vyšších verzích standardů. Konkrétně v XHTML2, které se nyní ještě nepoužívá. [24][25][13]

.: 14 :.

3.4 Typy mikroformátů Jednotlivé typy mikroformátů lze hromadně rozdělit do dvou základních skupin: dokončené a rozpracované. Dokončené, tzv. stabilní mikroformáty jsou takové, které mají již kompletní specifikace a lze je plně implementovat. Patří mezi ně hCard, hCalendar nebo XFN. Dále také některé z REL-mikroformátů: license, nofollow a tag. Rozpracované, tzv. drafty naopak stále ještě prochází vývojem a jejich stabilita není garantována. Vzhledem k mladosti technologie mají drafty rozhodně početnější zastoupení. Z těch zásadních lze jmenovat: hAtom, adr, hReview, rel-home nebo hNews. [26]

3.4.1 Stabilní mikroformáty •

hCard – slouží k zobrazení kontaktních údajů, zápis je shodný s formátem vCard

•

hCalendar – strojově čitelný popis různých událostí, které jsou vymezeny časem a místem, založen na standardu iCalendar

•

Geo – zápis zeměpisných souřadnic

•

XFN – pomocí znaků pomáhá určit sociální vztah mezi autorem a dalšími osobami (přátelé, spolupracovníci, rodinný příslušník)

3.4.2 Zástupci draftů •

hAtom – derivát obecného formátu Atom, označuje obsah, který má být publikován, je typický pro blogy, články nebo novinky

•

hRewiew – určeno pro označení různých druhů recenzí

•

adr – označuje informace o místech určení a adresách

•

hMedia – souvisí s publikací médií (obrázky, audio, video) [3]

3.4.3 Mikroformáty typu REL Zvláštním typem mikroformátů jsou formáty typu REL. Nezapisují se jako hodnota atributu class, nýbrž jako hodnota parametru rel. Mezi nejznámější patří: tag, home, licence, directory, enclosure nebo payment, jejichž využití je patrné z názvů. [3]

3.4.4 Čtení mikroformátů Číst mikroformáty už dnes umí celá řada aplikací. A to jak webové, tak desktopové. U webových je třeba zmínit hlavně Google Apps (Gmail, Google Calendar nebo Google

.: 15 :.

Maps). Dále desktopoví poštovní klienti, jako jsou Microsoft Outlook nebo Mozilla Thunderbird (zde je třeba doinstalovat zásuvný modul LookOut). Různé druhy mikroformátů najednou pak umí přímo na webových stránkách přečíst doplňky pro internetové prohlížeče. Pro Firefox je to modul Operator, pro Internet Explorer potom Oomph. [27]

3.4.5 Návrhové vzory pro mikroformáty Stejně jako u programování, tak i u mikroformátů existují tzv. návrhové vzory. Tedy určitá forma doporučení, jak daný mikroformát či jeho parametr zapsat. Patří mezi ně například Datetime Design Pattern, který naznačuje zápis data a času do titulku elementu tak, aby byl strojově čitelný. Mezi další návrhové vzory pro mikroformáty patří Value Class Pattern, který pojednává obecně o zásadách psaní hodnot pro mikroformáty, nebo Abbr Design Pattern pro používání HTML tagu abbr. [26]

3.4.6 Nanoformáty Vedle mikroformátů lze na internetu narazit na sémantické pomocníky s ještě kratší syntaxí. Jedná se o tzv. nanoformáty. Jejich rozšíření je však ještě velmi malé. Jejich potenciál je však velmi silný a předpokládá se jejich postupné rozšiřování. Příkladem může být použití v interaktivních diskuzích na sociální síti Twitter, kde se nanoformát používá při odpovědi na příspěvek, a to ve tvaru: @jméno_uživatele zpráva. [28]

3.4.7 Greasemonkey a Monkeyformáty Při výkladu o mikroformátech je nutné neopomenout rozvíjející se oblast vylepšení zobrazování stránky na straně klienta, tzv. Greasemonkey. Pod tímto názvem je skryta technologie, která zpříjemňuje uživatelům prohlížení webových stránek za pomoci nejrůznějších javascriptových utilit, a která se pomalu dere na výsluní internetu. „Samotná rozšíření fungují na jednoduchém principu. Na zobrazenou internetovou stránku aplikují JavaScript, který upraví zobrazení příp. funkčnost webu, aniž by musela probíhat jakákoliv komunikace se serverem, na němž je skript umístěn (samozřejmě pokud tento skript další komunikaci se serverem nevyžaduje),“ tvrdí ve svém článku Greasemonkey: naučte cizí weby nové funkce autor Ivo Mareček. [29] A je tomu skutečně tak. V současné době již existuje několik desítek takovýchto doplňků. Různé příklady jsou uvedeny přímo v článku, na který později navazuje Jakub Čížek a přidává pár dalších, např. vytvoření galerie typu „Lightbox“ (poznámka pod čarou) tam, kde byla její implementace autorem opomenuta, např. prohlížení výsledků hledání obrázků na Googlu. Nebo na stejném principu postavený doplněk pro rychlé přehrání videa na stránce, kde je umístěn odkaz na toto video.

.: 16 :.

Greasemonkey bylo dříve povětšinou přehlíženo díky své údajné nízké použitelnosti, která se vázala pouze na prohlížeč Mozilla Firefox. Dnes už to ovšem není pravda a podporou se pyšní i další běžné prohlížeče, jakými jsou Opera, Safari nebo IE7 s vlastním řešením zpracování těchto speciálních skriptů. [30] Greasemonkey dává mikroformátům nový rozměr. Díky technologii přidání určité nadstandardní funkčnosti na stránku dodatečně lze takto zacházet i s některými mikroformáty. V tomto ohledu se dočkaly konkrétně mikroformáty hCard a hCalendar, což logicky vyplývá ze skutečnosti, že právě tyto mikroformáty jsou obecně velice často využívané. Některé z monkeyformátů nejen že byly lokalizovány, ale dokonce přímo vytvořeny u nás. Aktivním českým autorem je Martin Hassman, který se podepsal pod nasazení monkeyformátu prostřednictvím mikroformátu hCard do telefonního seznamu komerční společnosti 1188 nebo hCalendar do aplikace IDOS spravující jízdní řády ČR. Dále stojí za zmínku použití hCard u amerických Yellow Pages (u nás Zlaté stránky) a také aplikování hCalendar pro servery Ticketmaster, které se zaměřují na online prodej vstupenek. Autorem těchto doplňků je holandský nadšenec Albert de Klein. Bohužel, monkeyformátů je v současné době stále jen malá hrstka, jejich úplný seznam lze nalézt na URL: http://userscripts.org/tags/monkeyformats. [31]

.: 17 :.

3.5 Závěr k mikroformátům Mikroformáty jsou i přes svoji výraznou jednoduchost a adaptabilitu velmi silným nástrojem pro popis vybraných informací, jež se díky nim stávají strojově čitelnými. Za poslední roky se staly na poli moderního sémantického webu opravdovým fenoménem a jejich rozšíření exponenciálně roste. Jednotlivé mikroformáty lze poměrně dobře kombinovat (běžně např. hCard + hCalendar nebo XFN + hCard), čímž jejich využití dále roste. Autorka Emily Lewisová ve své přednášce o mikroformátech uvádí čísla využití mikroformátů na světových webech. Po sumarizaci uvádí pro konec roku 2009 číslo, které přesahuje 6 mld. výskytů mikroformátů v internetu. [14] Z tohoto počtu má největší zastoupení mikroformát rel-tag, který z celku zaujímá přes 30%. Bez podivu je na tom podobně hcard, následují hatom a adr. Možným nečekaným faktem je slabý podíl mikroformátů hcalendar a geo, jejichž potenciál je značný.

Obrázek 1: Výskyt mikroformátů v internetu 12/2009

Lze předpokládat, že za další rok expanze mikroformátů do internetu můžeme již nyní čítat minimálně dvojnásobek tohoto čísla.

.: 18 :.

4 Webové frameworky 4.1 Co je webový framework? Webový framework je komplexní balík kódu a knihoven poskytující běžnou funkcionalitu pro aplikace zaměřené na webové prostředí. Poskytuje širší sadu funkcionalit pro určený typ aplikace a tím, že obstarává běžnou logiku aplikace a často i rozšířenou nadstavbu, dává programátorovi prostor zaměřit se na specifické části svého díla. Což téměř vždy znamená nemalou úsporu drahocenného času webového vývojáře. [4][5] Framework poskytuje programátorovi balíky pro práci s jádrem aplikace, interakce s databází, šablonovací systém a obsluhu tzv. „layoutu“ aplikace, zachycování a obstarávání výjimek nebo např. základ pro vyhledávání, práce s navigací a obsluhu sezení (SESSIONS). V lepším případě potom pro příklad caching, zpracování autentizace a statické či dynamické autorizace nebo částečnou či kompletní obsluhu formulářů, včetně jejich validace a zpracování. Jednotlivé frameworky se od sebe mohou lišit jednak samotným zpracováním a vnitřní logikou, ale také zejména právě poskytovanými funkcionalitami pro využití v samotné aplikaci. Právě tady musí programátor citlivě vybírat. Ze své pozice musí pečlivě zvážit, zda je opravdu nutné vybírat některého z „mastodontů“ mezi web-frameworky a nechat se omámit jeho nekonečnou řadou nadstandardního vybavení, když z povahy aplikace vyplývá, že většinu z nich nemá šanci využít.

.: 19 :.

4.2 Rozdělení webových frameworků Základním rozdělením frameworků je odlišení webových od desktopových. Separaci frameworků do oněch dvou základních skupin v tomto případě nestačí. Webové frameworky je nezbytné dál rozdělit podle platformy nebo jazyka, pro které jsou určeny: •

Java o o o o

JSF (Java Server Faces) Struts Spring Web MVC Jt Design Pattern Framework

•

Python o Django o Zope o Twisted o Pyjamas

•

Ruby o Ruby on Rails o Ramaze

•

PHP o o o o o

Zend Framework Kohana Symfony CakePHP Nette

•

ostatní o .NET [32] Dále lze frameworky dělit například podle využití či nevyužití MVC modelu nebo např. zda je vyvíjen komunitou programátorů, nebo některou korporací. To, že je framework spravován některou z komerčních firem ještě neznamená, že samotný framework musí být komerčním produktem. Z toho vyplývá další možné rozdělení frameworků – tedy na komerční a open-source. Tato práce se bude zaobírat implementací frameworků ve webovém jazyce číslo jedna – PHP.

.: 20 :.

4.3 Historie Samotné PHP započalo svou cestu sice již v polovině devadesátých let, kdy přišlo se svou první verzí jako odnož programovacího jazyka Perl, ovšem na první opravdový objektový PHP framework se muselo čekat skoro ještě další dekádu. S prvním náznakem frameworku přišla Zope Corporation v roce 1995 se svým produktem Zope, který byl napsán pro deroucí se na výsluní jazyk Python. Na přelomu tisíciletí se začaly objevovat frameworky také pro jazyk Java – se svou první verzí přišel například Struts, Tapestry, WebWork, v roce 2004 potom dnes velmi rozšířený JSF. Na začátku roku 2002 vyšla také první verze .NET frameworku od Microsoftu, o tři roky později Ruby on Rails na jazyce Ruby. Matt Raible ve svém grafu vývoje webových frameworků na časové ose poměrně zajímavě zasadil jednotlivé produkty a jejich následné verze do kontrastu s vydáním nejběžnějších prohlížečů za poslední dekádu. Bohužel, opomněl zde zmínit většinu zásadních webových frameworků postavených na PHP. [33]

Obrázek 2: Časová osa s framewoky

PHP frameworky odstartovaly vydáním frameworku Drupal v roce 2001. A v době, kdy světlo světa spatřila první verze Zend Framework, Drupal už vyvíjel svou verzi 5. To se psal rok 2005 a další dnes nejznámější PHP frameworky ho bleskurychle následovaly: •

2004: Prado

•

2005: Zend

•

2006: CakePHP

•

2007: Symfony, Kohana, Jelix

•

2008: Nette [34][35][36]

.: 21 :.

4.4 Výhody a nevýhody využití frameworku Při rozpravách a diskuzích o využití frameworku jako piedestalu pro webovou aplikaci hovoří vývojáři povětšinou spíše o výhodách toho kterého frameworku. Často se ale zapomíná na fakt, že využití frameworku s sebou nese i nějaká ta úskalí. A to jak konkrétně pro každý framework zvlášť, tak také obecně. Rozhodně je dobré vědět i o globálních výhodách.

4.4.1 Výhody •

využití mnoha užitečných knihoven a pomocných tříd

•

znovupoužitelnost kódu

•

s tím spojená mnohdy enormní úspora času

•

práce s efektivně navrženými a otestovanými komponentami

•

snazší ladění problémů díky jednotné dokumentaci a mnohdy rozsáhlou komunitou

•

často za programátora řeší standardizované návrhové vzory

•

využití zpravidla kvalitní bezpečnostní vrstvy

•

snadná aktualizace frameworku bez nutnosti zásahu koncového programátora

•

poskytován běžně jako volná licence

4.4.2 Nevýhody •

hrozba někdy i výrazného zpomalení aplikace při načítání redundantních tříd a knihoven

•

u robustnějších frameworků složité vyznání se v adresářové struktuře

•

zdlouhavé osvojování a učení práce s frameworkem

•

zdlouhavá příprava použití frameworku a ladění počáteční konfigurace

•

zkreslený názor programátora (často používající jeden framework), který díky zvyku a čím dál dokonalejšímu osvojení konkrétního frameworku vidí výhody tam, kde nejsou

•

obejití určité funkčnosti či složitější přizpůsobení některých tříd a metod je někdy zdlouhavější, než případné vlastní řešení – tím trpí obvykle hůře strukturované frameworky

•

neodhalené chyby v jádru frameworku mohou působit potíže v na něm postavených aplikacích

•

navíc, případná oprava této chyby může také negativně ovlivnit běh již nasazených aplikací [37]

.: 22 :.

4.5 Návrhové vzory v PHP Pokud je řeč o soudobých webových frameworcích, nelze nezmínit pojem protkaný skrz naskrz každým z nich. Řeč je o návrhových vzorech – design patterns. „Návrhové vzory jsou šablony pro organizaci kódu aplikace“. [6] Takhle zní zřejmě nejkratší a nejsnáze pochopitelná definice. Samotný původ tohoto názvosloví sahá až do konce sedmdesátých let minulého století, kdy byl poprvé použit v oblasti architektury autorem Christopherem Alexanderem. Tato myšlenka později plynule přešla na pole softwarového inženýrství a mezi vývojáři se úspěšně ujala. Návrhové vzory je doporučeno používat při kombinaci framework + OOP. Za léta praxe programování v objektovém prostředí a stavby aplikace s pomocí frameworku bylo sestaveno několik desítek návrhových vzorů, které mají různá využití a každý nějakým svým specifickým způsobem zefektivňuje práci s objekty. Existují různé druhy sloužící například k efektnímu přístupu k instancím objektů, připojením k databázi, operacím nad daty nebo vykreslování šablon. Frameworky, potažmo aplikace v rámci této práce jich využívají hned několik.

4.5.1 Singleton Pattern Singleton je patrně nejznámější a také snad nejdiskutovanější návrhový vzor. Jeho podstatou je vytvoření pouze jedné instance objektu – tzv. „jedináčka“. Toho lze docílit skrze hlídání vytvoření instance prostřednictvím jejího vložení do statického atributu třídy. Objekt se vytvoří pouze tehdy, pokud je daný statický atribut třídy prázdný (null) nebo v případě dvoustavového určení false. Naprosto typickým využitím Singleton Patternu je připojení k databázi, kde se jeho použití doslova vybízí, poněvadž v rámci chodu aplikace není žádoucí připojení k databázi znovu vytvářet. V praxi to potom vypadá takto (PHP5): class DbConn { static $instance = false; private function __construct() {} public function getInstance() { if (!self::$instance) { self::$instance = new self; } } }

.: 23 :.

Je patrné, že implicitní instanční metoda __construct() zde není využita a její prefix private zabraňuje vytvoření instance skrze něj. Proto jediná metoda, která vytváří objekt je veřejná metoda getInstance(), která jediná právě zajišťuje vytvoření Singletonu. Pro usnadnění zápisu kódu je použitá vnitřní konstanta self pro identifikaci stávající třídy. Jinými alternativami zápisu by mohlo být přímé použití jména DbConn, případně vypsání skrze proměnnou, nebo využití jedné z tzv. magických konstant __CLASS__. Nette Framework využívá Singleton Pattern mimo jiné také pro ukládání do proměnných SESSION.

4.5.2 Factory Pattern Dalším hojně využívaným návrhovým vzorem je dozajista Factory Pattern. Ten zajišťuje správná vytváření nových objektů, což spočívá v zapouzdření vytvoření instance objektu. Tento princip má z podstaty neomezený počet využití ve frameworcích i v koncových aplikacích. Tzv. „továrničku“ lze využít například při vytváření instance managera, který pracuje s daty v modelu MVC. Rozdíl je vidět poměrně jasně v následujícím příkladu. •

vytvoření instance přímo: $manager = new UserManager;

•

vytvoření instance skrze Factory Pattern $manager = $this->getManager();

Zde je vidět, že vytvoření instance třídy s managerem obstarává metoda getManager(), uvnitř které lze provést několik dalších operací k upřesnění inicializace konkrétního objektu, samozřejmě také vytvoření samotné instance. Navíc může být poděděná nebo může přijímat různé rozšiřující parametry. [6]

4.5.3 MVC Mezi nejrozšířenější a nejzásadnější návrhové vzory patří pattern MVC (ModelView-Controller). Nejedná se o žádnou novinku na poli softwarového inženýrství. Jeho formulace poprvé zazněla z úst norského autora Trygve Reenskauga už v roce 1979, kdy jeho původní označení znělo TMWE (Thing-Model-View-Editor). Postupně z něj vykrystalizovala podoba skutečného MVC návrhu, který ovšem ještě zdaleka neodpovídal své dnešní podobě. Ze studia různé literatury lze naznat, že mnoho autorů zabývajících se MVC modelem chápalo a stále ještě chápe jeho podstatu někdy i výrazně odlišně. Nicméně, kompromis všech chápání tohoto modelu spočívá ve vysvětlení, že „model MVC rozděluje aplikaci do tří různých vrstev. První vrstvou je tzv. Model, který představuje logiku aplikace (business logic). Další vrstva, Pohled (View), představuje uživatel-

.: 24 :.

ské rozhraní a zajišťuje interakci s uživatelem. Řadič (Controller) pak spojuje vrstvy Model a View.“ [12]

Obrázek 3: Původní MVC model

Tato definice a schéma na Obrázek 3 skutečně odpovídá staršímu pojetí MVC modelu. Ovšem moderní pojetí modelu MVC, potažmo MVP (Model-View-Presenter) tuto původní myšlenku převrací a vysvětluje MVC sice opět jako třívrstvou architekturu složenou ze stejných komponent, přesto jsou role jednotlivých komponent výrazně jiné. Řízení chodu aplikace, které měla původně na starosti vrstva Model, převzal Conroller (Presenter), který obstarává onen zmíněný business logic a komunikuje, potažmo zprostředkovává, komunikaci mezi oběma zbylými vrstvami. Role vrstvy View zůstává vesměs stejná, tedy představuje uživatelské rozhraní a Modelu je vyhrazena práce s daty. V jazyce PHP frameworku to potom znamená, že Model je výhradně určen pro komunikaci s databází např. skrze některé z ORM3. View zajišťuje správné zobrazení zpravidla skrze šablonovací systém a Controller připravuje data pro zobrazení (Model -> View) nebo naopak pro ukládání (View -> Model).

Obrázek 4: Současný MVC model

3

ORM (Object Relational Mapping) – oboustranná transformace databázových dat na objekty

.: 25 :.

4.5.4 Active Record Pattern Ve vrstvě Modelu vzoru MVC je velice vhodné použít Active Record Pattern. Tento návrhový vzor spočívá v rozdělení Modelu na dvě části. Jednou z nich je tzv. Manager, který zastává roli právě Modelu, komunikuje s databází a obstarává funkce CRUD4 nad daty, která dostane z přiřazeného Presenteru. Druhou částí je dle názvu právě tzv. aktivní záznam, což je v podstatě nový objekt, jehož prostřednictvím Manager předává vybraná data zpátky Presenteru popř. View pro zobrazení. Takový objekt s aktivním záznamem představuje právě jeden záznam vybraný z databáze – jeden řádek tabulky. Takto postavený návrhový vzor skýtá hned několik významných výhod. Vedle snadnějšího přístupu k datům a ohebnějšího výpisu obsahu ve Views je tou nejpodstatnější dodatečná úprava dat v objektu, která poskytuje nekonečné možnosti v rozšiřování a modifikaci objektu a jeho přizpůsobování potřebám Presenteru nebo View. Pokud je, dejme tomu, některé položky v záznamu složité nebo dokonce nemožné vydolovat z databáze pomocí sebesofistikovanějšího dotazu, je Active Record Pattern nezbytným řešením. Příkladem může být tvorba "cool URL adresy"5 pro detail uživatele, která by měla mít tvar např. „uzivatele/detail/13-trojan-josef“. Dalšími užitečnými návrhovými vzory by mohly být např. Value Object Pattern pro práci s jednoduchými objekty, Adapter Pattern ke zprostředkování cizích objektů a jejich snadnou aktualizaci bez zásahu do vlastního kódu nebo další z řady návrhových vzorů pro práci s tabulkami databáze – Table Data Gateway Pattern a Data Mapper Pattern, které jsou propracovanějšími příbuznými zmiňovaného Active Record Patternu. Samozřejmě lze namítnout, že jak v aplikaci, tak v jednotlivých frameworcích šlo ze zásady použít návrhových vzorů víc – např. hojně využívaný Iterator Pattern pro snadné procházení dat. Nicméně použití toho kterého návrhového vzoru je plně v režii vývojáře. Nejsou sepsána žádná pravidla, kdy ten a ten vzor nutno použít. Jak bylo řečeno, návrhové vzory by v každém jazyce či odvětví měly v první řadě usnadňovat práci a rozhodnutí, zda je využít či ne, by mělo zůstat zcela volitelné.

4

CRUD (Create, Read, Update, Delete): vkládá, selektuje, aktualizuje a vymazává data v databázi Cool URL / SEO URL: srozumitelné a lépe zapamatovatelné URL adresy, které obsahují klíčová slova a dosahují tak lepší pozice ve vyhledávačích. Tvoří se zejména ve tvaru klíčových slov oddělených lomítky.

5

.: 26 :.

4.6 Objektově orientovaný přístup Do kompletní základní „tripartity“ vývoje moderních webových aplikací postavených na PHP chybí ještě jeden neméně důležitý článek – je jím revoluční technika pojetí programování skrze objekty – tzv. OOP (Object-oriented programming). Kořeny myšlenky OOP sahají hluboko do šedesátých let minulého století, kdy programátoři řešili problém uspořádání rozsáhlého kódu programu zpracovávaného počítačem. Už tehdy vyvstala idea rozdělit kód do logicky uspořádaných sad a zabránit tak jeho případné nečitelnosti a s tím spojenému složitému odhalování a ladění chyb. [7] Prvním programovacím jazykem postaveným na paradigmatu OOP byla Simula67 právě už v šedesátých letech dvacátého století. Většina dobře známých jazyků (Pascal, Ada, Basic, atp.) se jeho použití, ať už dříve či později, neubránila a OOP se stalo opravdovým fenoménem. Do jazyka PHP se naproti tomu dostala až velmi pozdě. A to až v polovině roku 2004 společně s PHP verzí 5. V předchozí verzi sice nějaké náznaky práce s objekty byly, ale opravdu objektově programovat se v PHP dalo až právě v páté verzi. Základní a jedinečné vlastnosti objektového přístupu v obecném kontextu tvoří triáda zapouzdření (encapsulation), dědičnost (inheritance) a polymorfismus (polymorphism).

4.6.1 Zapouzdření Přestavuje zabalení operací (metod) a atributů (proměnných) do jednoho objektu (třídy). Stav objektu je pak přístupný právě pouze přes zapouzdřené rozhraní. Jde tedy o oddělení vnitřní funkčnosti objektu od vnějšího okolí a od samotného uživatele. Ten musí být pouze schopen pracovat s rozhraními tvořenými jednotlivými objekty. To přináší nemalé výhody. Uživatel neví o dění uvnitř objektu a programátor má volnou ruku v případných změnách kódu bez vlivu na uživatele. Dále zapouzdření „redukuje počet potenciálních uživatelských chyb, protože má programátor interakci uživatele s aplikací pod kontrolou.“ [8]

4.6.2 Dědičnost Na dědění klade OOP velký důraz. Spočívá v tom, že od objektu s nejvyšší úrovni abstrakce dědí jeho potomci veškeré atributy a chování. Mohou je rozšiřovat nebo upřesňovat. Nejlépe lze podstatu dědění vidět na různých praktických příkladech. Nejběžněji se uvádí příklad hierarchie v běžném podniku. Na potenciálně nejvyšší úrovní abstrakce stojí Zaměstnanec, jeho atributy a vlastnosti pak přebírá Dělník, který už má specifičtější zaměření a rozšiřuje vlastnosti původního objektu. Dále může hierarchie pokračovat např. Obráběčem, který opět přebírá všechny atributy Dělníka. Lze samozřejmě dědičnost rozšířit

.: 27 :.

i na opačném konci. Vyšším stupněm abstrakce by konkrétně na tomto příkladě byla entita Člověk, od které by Zaměstnanec dědil a spolu s ním i všechny jeho podtřídy.

4.6.3 Polymorfismus Polymorfismus (mnohotvárnost) „definuje schopnost OOP předefinovat, neboli přeměnit charakteristiku či chování nějaké třídy v závislosti na kontextu, ve kterém se používá.“ [8] Tedy, jedná se o jedinečnou vlastnost OOP, která dovoluje vlastní implementaci konkrétních metod objektu. V praxi to pak znamená, že např. ve výše uvedeném příkladu hierarchie podniku podtřídy Obráběč a Uklízečka, jakožto potomci třídy Dělník, obsahují zděděnou metodu zobrazPlanPrace(), jejíž implementace bude, z logiky věci, mírně odlišná. Právě v tom tkví podstata a síla polymorfismu v OOP, jenž s těmito případy počítá a dovoluje je implementovat. Všechny tyto základní atributy OOP přispívají a hlavně umožňují tzv. znovupoužitelnost (reuse) kódu.

.: 28 :.

5 Porovnání frameworků Je pryč doba, kdy programátoři tvořili strukturovaný kód skrze čisté PHP, v lepším případě, pro vlastní usnadnění zkoušeli psát svoje vlastní, mnohdy rádoby frameworky, které byly jen v ojedinělých případech později nějakým způsobem zveřejněny. Až s příchodem orientace na objekty a s inspirací z jiných jazyků se začalo objevovat větší množství více čí méně zdařilých řešení. Tyto pokusy končily různě. Některé úplně v koši, jiné se staly pro své autory nedoceněným celoživotním dílem, kterého se odmítají vzdát a staví na něm své aplikace dodnes, ale jen málo z nich vstoupilo do podvědomí širší programátorské obci. Některé se staly komerčními produkty, což ovšem opět znamená jejich slabší rozšíření. Jak bylo řečeno, prvním open-source PHP frameworkem se stal už na přelomu tisíciletí belgický Drupal, další následovaly. Přibližně za dekádu jejich vývoje jich lze čítat desítky. Ne všechny se však úspěšně ujaly.

5.1 Vyhovující kritéria Co všechno bude framework umět? Co z toho je nezbytné pro tvorbu zadané aplikace? Nebude až příliš zdlouhavé jazyku frameworku porozumět? Bude zvolený framework podporovat zvolené technologie? Podporuje vybraný typ a značku databázového stroje? Není moc hardwarově náročný? Jak rychlá je odezva dotazů na databázi? Tyto a podobné dotazy si kladou nejen frameworkoví začátečníci, když se rozhodují, který framework pro své řešení vybrat. Nejinak tomu bylo i v případě aplikace v rámci této diplomové práce. Na výběr bylo z více než dvaceti možností.

5.1.1 Databáze Základním předpokladem byla podpora databáze MySQL, což výběr nikterak nezúžilo, poněvadž drtivá většina frameworků se může jeho podporou pochlubit – a to ze zjevných důvodů. Za vše mluví čísla z roku 2008. Přes 5 000 000 aktivních instalací ve 22 zemích světa. Navíc, každým dnem se počet stažení rozrůstá o dalších 40 000 instalací. MySQL využívají i internetoví giganti Google, Yahoo!, Novell, Hewlett Packard nebo např. vládní vojenská organizace NASA. [8]

5.1.2 PHP5 Samozřejmostí je jistě podpora pro PHP verze 5 a vyšší. Naštěstí se to zdá být samozřejmostí i pro vývojáře snad všech současných PHP frameworků, kteří jdou s dobou.

.: 29 :.

Nechávají však často prostor i pro starší verze a frameworky jsou z hlediska PHP zpětně kompatibilní.

5.1.3 MVC Výběr zúžilo až další kritérium, kterým byla podpora MVC modelu. Zde už některé frameworky neobstály, jako např. CodeIgniter, který ve většině dalších hledisek obstál na výbornou a dosahoval i slušných rychlostí. [38]

5.1.4 Dokumentace Dalším z hlavních kritérií byla dostatečná dokumentace v anglickém popř. českém jazyce. Zde bylo upuštěno od některých frameworků ve vývoji (Jelix), a dalších s nekompletní dokumentací (Prado, Fuse). [38]

5.1.5 Licence Webové frameworky se běžně objevují pod tzv. „copyleftovými“ licencemi6. Tedy jsou volně šiřitelné a modifikovatelné. Nejpodstatnější část je šířena pod licencí BSD7, ostatní vesměs spadají pod licence GPL8 a MIT9.

5.1.6 Rychlost operací a nároky na operační paměť Velmi důležitým kritériem je bezesporu rychlost a paměťová náročnost jednotlivých frameworků. Z Velkého testu frameworků na serveru root.cz vzešlo několik zajímavých výsledků. Autoři článku na jednoduchých programových operacích a základních SQL dotazech testovali mimo jiné rychlost odezvy a nároky na operační paměť u deseti vybraných PHP frameworků. Vyšlo najevo, že v řádu milisekund jsou v rychlosti odezvy mezi jednotlivými frameworky někdy až propastné rozdíly. Dobře si vedly produkty Kohana, CakePHP a český Nette. Naopak i renomovanější z vybraných, zejména Zend, Prado nebo Fuse dosáhly výsledků řádově horších.

6

Copyleft – označení licencí pro volný software, v podstatě opak copyrightu BSD (Berkeley Software Distribution) – licence pro svobodný software, vyžaduje pouze informaci o licenci a uvedení autora; je jednou z nejvolnějších 8 GPL (General Public License) – nejpopulárnější z licencí pro svobodný software; vyžaduje šíření odvozených děl pod stejnou licencí 9 MIT (Massachusetts Institute of Technology) – volná licence buď v kombinaci s GPL nebo proprietárním (komerčním) software 7

.: 30 :.

Obrázek 5: Porovnání rychlostí jednotlivých frameworků

Obdobně je tomu při testování nároků na paměť, kde např. Zend opět daleko zaostává za CakePHP nebo Kohanou.

Obrázek 6: Využití paměti u jednotlivých frameworků

Rozdíly u obou testovaných vlastností se pak smazávají při zapnutí eAcceleratoru10. Zajímavostí u obou dvou kritérií je porovnání s čistým PHP, tedy bez použití frameworku. [38]

5.1.7 PHP Depend Zajímavé porovnání nabízí utilita pDepend (odvozená od jDepend pro jazyk Java), která zjišťuje kvalitu aplikace (frameworku) z hlediska návrhu. Pracuje na principu rozparsování kódu a vygenerování tzv. AST11, kde pak testuje jednotlivé stavy a elementy aplikace (frameworku). Výsledkem je graf závislosti stability aplikace na úrovni abstrakce, a to také s ohledem na počet obsažených tříd, metod, knihoven nebo počet řádků. [39]

10 11

eAccelerator – urychluje provedení kódu za pomoci cachování skriptů AST (Abstract Syntax Tree) – stromová struktura, která reprezentuje úroveň abstrakce zdrojového kódu

.: 31 :.

Obrázek 7: Statistiky PHP Depend pro frameworky Nette a Zend

5.1.8 Hodnocení programátorů V posledních týdnech probíhala na serveru root.cz uživatelská anketa ohledně využití webových technologií. Podle očekávání v souboji technologií zvítězilo na plné čáře PHP, které porazilo Javu, Python, Perl nebo Ruby o více než polovinu. Anketa nabídla plno zajímavých statistik. V prezentační části jasně dominovalo aktuální XHTML s volnějším HTML4.01, dopředu se nesměle dere HTML5. V rámci frameworků pro JavaScript jen hrstka programátorů používá jiné řešení než kouzelné jQuery a databázím jasně vévodí MySQL. Jeden oddíl otázek byl věnován právě webovým PHP frameworkům. Málokdo by pochyboval, že se například Zend umístí v popředí žebříčku, což se také potvrdilo, přesto výsledky poskytly několik zajímavých faktů. Zastoupení méně známých frameworků se snad dalo očekávat, ovšem dle výsledků ankety stále ještě přetrvává poněkud konzervativní trend využití vlastního řešení (34%). Nejzajímavějším faktem je jednoznačně stavba aplikací na českém frameworku Nette. Takřka 500 zúčastněných čtenářů serveru root.cz propadlo tomuto fenoménu posledních měsíců, což v relativním vyjádření znamená 49% hlasujících PHP vývojářů. [40] Obrázek 8: Oblíbenost jednotlivých frameworků programátory

.: 32 :.

5.2 Volba frameworků Možnost výběru se aplikováním kritérií tedy mírně zúžila, stále však lze vybírat z několika srovnatelných frameworků. Silnými aspiranty se jevily frameworky: Kohana, Nette, CakePHP a také Zend Framework.

5.2.1 Kohana Vlastní komunitou vyvíjený framework Kohana si vedl v testech výborně. Při velmi malých nárocích na paměť dosahoval obstojných rychlostí, a to jak s použitím, tak bez použití eAcceleratoru. Zdál by se tedy vážným kandidátem pro zvolení. Patří mezi ty tzv. „odlehčené“ frameworky, přesto patří k těm silnějším. Disponuje několika nadstandardními knihovnami, např. podpora platby přes internet. Leč, visí zde velký otazník nad kompatibilitou dvou odlišných verzí, což by mohlo v rámci vývoje a údržby aplikace působit nemalé problémy. [38]

5.2.2 CakePHP Tento framework se řadí mezi ty nejrozšířenější. Nemalou měrou se na tom podílí kvalitní dokumentace (dokonce lokalizovaná do češtiny) a rozsáhlá komunita vývojářů po celém světě. Nechybí ani podpora pro starší verze PHP. Rychlostně a nároky na paměť je vyrovnaným soupeřem např. pro české Nette. Ovšem opět, podobně jako u Kohany, se potýká s nejasnostmi okolo kompatibility dvou různých větví vývoje. Problémem může být také to, že CakePHP implicitně nepodporuje javascriptový framework jQuery, orientuje se na konkurenční a méně známý Prototype. Fakt, který hraje také v neprospěch tohoto frameworku, je zařazení mezi tzv. „full-stack frameworks“, kde je třeba striktně se držet zavedených konvencí a postupů, což znamená neoblíbené svázání programátorových rukou. [38]

5.2.3 Zend Framework Zend odstartoval svou dráhu v polovině roku 2005 pod křídly společnosti Zend Technologies, ale přelomovou verzí byla až verze 1.5 z roku 2008, která obsahovala několik stěžejních vylepšení, jako např. ZendForm pro obsluhu formulářů nebo podporu tvorby layoutu a views. Zend framework je spíše robustního charakteru. V PHP Depends testech hovoří čísla jasně. V počtu výskytu knihoven, tříd a metod dosahuje omračujícího čísla, ve srovnání s některými frameworky, přesahujícího desetinásobek počtu u konkurenta. Podobně je tomu u statistiky počtu řádků kódu, kde např. ve srovnání s frameworkem Kohana dosahuje opět až o řád větších hodnot.

.: 33 :.

Konkrétně potom: •

Nette: 14 tis.

•

Kohana: 23 tis.

•

CakePHP: 87 tis.

•

Symfony: 137 tis.

•

Zend: 273 tis. Rychlostní testy a paměťové nároky také nedopadly příliš dobře a bez použití eAcceleratoru Zend nemůže v tomto ohledu konkurenci stačit. Ve prospěch Zendu hrají ovšem další velmi důležitá kritéria. Disponuje jednou z nejkvalitnějších a nejrozsáhlejších dokumentací. Komunita vývojářů je také velmi rozsáhlá – na přímém vývoji se podílí přes 500 vývojářů. Nespočet aplikací je právě na Zendu postaveno – údaje na oficiálním portálu uvádějí přes 10 mil. stažení instalace. Přehledná architektura aplikace postavená na MVC modelu, návrhové vzory a standardní a výstižná názvosloví jsou samozřejmostí. Velmi silně podporuje vývoj řízený testy (přes 3600 testů v základní distribuci). Mezi výhody lze také počítat jeho zařazení mezi tzv. frameworky typu „glue“, což znamená, že zavedené programovací konvence jsou pouze doporučené a programátor má v mnohém prostor pro realizaci a využití vlastností frameworku tak říkajíc po svém. [41]

5.2.4 Nette Nápad s vytvořením vlastního frameworku vzešel z hlavy českého programátora a publicisty Davida Grudla, který se od roku 1999 zabývá programováním v PHP. Původní idea vznikla už v roce 2004 (tehdy pro PHP4) v malém domku na okraji Troubska u Brna, ale sám autor vydání pozdržel, a udělal tak ze svého díla jeden z nejočekávanějších projektů u nás. Jak je patrné z historického přehledu této práce, v té době byly projekty webových frameworků pro PHP ještě v plenkách, proto se tehdy rozhodl pro vlastní řešení. Na první verzi se muselo čekat dlouhé čtyři roky, ale výsledek stál podle všeho za to. [42] Po nultých verzích měla letos přijít dlouho připravovaná verze 1. Autor a jeho kolektiv však letos v září na konferenci WebExpo 2010 z nezveřejněných důvodů představili Nette v2.0, která ovšem programově odpovídala v1.0, která tak nikdy nespatřila světlo vývojářského světa. Nicméně, s novou verzí přišlo nespočet vylepšení jak z hlediska podpory PHP (PHP 5.3), tak bezpečnosti (XSS, CSRF, SESSION hijacking, ..., atp.), dependency injection, vylepšení ladicích nástrojů (debug bar), plugin pro vývojové prostředí NetBeans, podpora HTML5 (hlavně v rovině formulářů), podpora ORM Doctrine2, zefektivněná podpora anotací, aj.

.: 34 :.

Nette se, stejně jako Zend, řadí mezi „glue“ frameworky a snaží se dávat programátorovi co největší volnost pro své řešení. Jeho autor se v mnoha věcech v Zendu inspiroval, s čímž souvisí i několik výše zmíněných zděděných výhod. Nette se navíc pyšní skvělými výsledky při srovnání s ostatními frameworky, autorem deklarovanou absolutní nezávislostí na JavaSriptu a také vyspělým routovacím systémem. V různých článcích o Nette lze vyčíst, že odborná veřejnost vidí Achillovu patu frameworku v nedokončené dokumentaci. Oba posledně zmiňované frameworky byly na základě výše popsaných vlastností zvoleny pro stavbu aplikace, která je předmětem této práce. Ke společným výhodám obou frameworků patří volná licence, vyzrálý objektový návrh, poměrně snadná modularizace, rozsáhlá komunita vývojářů, logická a snadno pochopitelná stavba adresářové struktury, reakce na moderní trendy a v neposlední řadě velké množství nadstandardních knihoven a doplňků.

5.2.5 Komerční framework Netwings Dosud byly probírány a srovnávány frameworky z první velké skupiny tzv. opensource frameworků. Tato práce si mimo jiné klade za cíl pokusit se vybrané frameworky srovnat s jedním z komerčních řešení. Za tímto účelem byl vybrán systém Netwings. Netwings byl vyvinut pro interní účely brněnskou firmou INSPIRE CZ, s. r. o., specializující se na tvorbu webového softwaru. V původní verzi šlo pouze o aplikaci ve flash prostředí se správou aktualit. Na počátku první databázové verze, postavené na PHP, stála autorka spoluzakladatelka firmy Ing. RNDr. Barbora Bühnová, Ph. D., roz. Zimmerová, která v roce 2004 své dílo úspěšně obhájila jako diplomovou práci na téma Analýza a návrh internetových aplikací s použitím vzorů na Fakultě informatiky Masarykovy Univerzity v Brně. V té době se v rámci verze 2 však stále jednalo pouze o CMS12. S postupem času a zvyšujícími se nároky na komplexní řešení začal Netwings směřovat ke konceptu CMS + framework. V té době přišla řada zásadních inovací. Přechod z databázového systému MySQL na PostgreSQL, objektový přístup, autorizace skrze ACL, využití moderních technologií pro snadné ovládání (AJAX, Javascript), aj. Dnes INSPIRE staví aplikace již na šesté verzi systému Netwings, který se již nyní dá klasifikovat jako komplexní CM systém v kombinaci s frameworkem. Na Netwings 6 dnes funguje přes 50 špičkových webových portálů. Od těch nejjednodušších dynamických webů až po rozsáhlé složité projekty renomovaných firem. 12

CMS (Content Management System) – neboli systém pro správu obsahu, jinak také redakční systém, tvoří rozhraní pro snadnou práci s webovým obsahem

.: 35 :.

6 Aplikace Fotbalový portál 6.1 Fotbalový portál Po zběžném a později i důkladnějším prozkoumání současného stavu internetových prezentací fotbalových (ale i hokejových či basketbalových) klubů lze naznat, že jejich úroveň je sice rozmanitá, je však nutno dodat, že většinou dosti slabá, někdy až katastrofální. Většinou sice platí pravidlo, že v čím vyšší soutěži je klub nasazen, tím roste kvalita jeho webu, leč někdy je klubová prezentace na internetu povrchní a její možnosti velmi podceněné. Některé ligové celky, tedy kluby naší nejvyšší soutěže, mají prezentace zpracované detailně, ale není to bohužel pravidlem. U celků nižších soutěží už je situace hodně rozlišná. Málokterý z nich disponuje dynamickým aktualizovaným webem, leckdy pak jde o statickou prezentaci, často slabě aktualizovanou. Proto vznikla idea přijít s ojedinělým projektem, který by zprostředkovával aktuální dění v klubu právě skrze dynamickou webovou prezentaci postavenou na moderních technologiích.

6.1.1 Základní funkcionalita Webový portál s jakýmkoliv zaměřením by měl být především živý. [9] O dění v klubu není nouze především v období sezón, kdy minimálně jednou za týden probíhá výsledková aktualizace. Primárním předpokladem je tedy základní správa výsledků, ke které je potřeba zavedení backendu aplikace, kde pak mohou správci redakčním způsobem výsledky zadávat a upravovat. Problém pak někdy nastává v období mimo sezónu, kdy obzvláště u nižších soutěží probíhá aktualizační „temno“. Je tedy třeba stránky oživit pomocí článků nebo aktualit. Někdy však ani toto řešení nestačí, především kvůli neaktivitě správců, či nedostatku informací. To přichází na řadu přenechání aktivity na webu přímo uživatelům, nebo návštěvníkům stránek prostřednictvím vybraných interaktivních komponent. Tou nejběžnější formou je fórum, diskuze či tzv. návštěvní kniha.

6.1.2 Rozšířené možnosti Dalšími interaktivními prvky mohou být anketa, hlasování, dotaz na správce přes formulář nebo např. hodnocení článků. Nadstavbovou částí tohoto druhu webu je detailní rozbor utkání. Ten může probíhat v několika stupních. Rozborem utkání může být myšleno jeho slovní hodnocení a průběh.

.: 36 :.

Je tedy třeba spojit stávající obecné články s konkrétním zápasem – tedy přidat článku možnost přiřadit jej, běžně skrze identifikační číslo, k vybranému zápasu. Dalším stupněm jsou pak statisticky zpracovatelné údaje ze zápasu, čímž zde může být např. počet diváků.

6.1.3 Entitně relační diagram Nejvyšším stupněm detailního rozboru utkání je zaznamenání stěžejních momentů zápasu. V případě fotbalového portálu jsou to vstřelené branky, žluté a červené karty, střídání, obsazení rozhodčími, atp. Právě tato část tvoří základní relace v návrhu aplikace.

Obrázek 9: Základní ERD aplikace

Ústřední entitou se stává seznam uživatelů (users). Jednotlivým uživatelům připadnou určité role (appointments) v týmu nebo mimo něj, kterých může být 0 až n. Tyto role může uživatel zastávat buď pro všechna mužstva (squads) v rámci týmu (teams), nebo libovolně pro každé mužstvo zvlášť. Dalším rozměrem těchto vztahů je závislost na jednotlivých sezónách (seasons), v rámci kterých se mohou role uživatelů samozřejmě měnit. V případě hráčů pak existuje relace s posty na hřišti (pitch_posts). Doplňující informace k zápasům jsou odděleny do zvláštní tabulky (match_details) ve vztahu 1:1, ne ke každému zápasu totiž existují detailní informace a logika aplikace později dovoluje zadávat detaily pouze k zápasům vybraného klubu.

.: 37 :.

Záznamy o vstřelených gólech, udělených kartách a proběhlých střídáních spravuje, díky podobné struktuře záznamů, pouze jedna tabulka (goals_cards_substs), kde je druh záznamu odlišen příznakem.

6.1.4 Grafická úprava aplikace Rozložení stránky a grafická úprava aplikace není stěžejní částí této práce, byl tedy zvolen jednoduchý design ve fotbalově zelené barvě, s šedobílým podkladem pro obsahovou část a kontrastující tmavou barvou pro texty. Vrchní lištu tvoří barevný banner ve formátů PNG, který je zároveň nejrozměrnějším a největším obrázkem v aplikaci. Záměrně byl zvolen jednodušší design s malým množstvím grafických prvků a obrázků, jelikož se počítá s orientací webu na obsahovou část, která bude v některých případech poměrně rozsáhlá (úvodní strana, statistiky, ...), a z prováděných výzkumů vzešel závěr, že „existuje psychologická hranice 20s, po jejímž překročení většina uživatelů ztrácí zájem o dokreslení objemově velké stránky a přechází jinam.“ [9] Rozložení stránky respektuje principy přístupnosti webu. Pod vrchním bannerem se web rozděluje na levou navigační a pravou obsahovou část. Informace o přihlášení je přehledně umístěna do navigační části pod hlavní menu. Drobečková navigace je pak umístěna klasicky do levého horního rohu obsahové části. [10] Na druhé straně v pravém rohu je na dobře viditelném místě umístěno přepínání sezón, které se vykresluje na každé stránce prezentační části aplikace a lze tak pohodlně přecházet mezi sezónami prakticky odkudkoliv. Administrační část webu je pro zachování konzistence, co se týče rozložení stránky, naprosto stejná. Barevně je laděná do odstínů šedé barvy.

Obrázek 10: Náhled prezentační a administrační části aplikace

.: 38 :.

6.1.5 Programové prostředky Jak bylo zmíněno, webová aplikace v rámci této diplomové práce bude postavena na nejběžnějších a dle výsledků nezávislé ankety na serveru root.cz také nejoblíbenějších webových technologiích. Z prezentačního hlediska bude použita norma XHTML 1.0 a web bude podle této normy také plně validní. Neodmyslitelně připojeno je použití moderních kaskádovacích stylů CSS 2. Z hlediska aplikační logiky bude aplikace stát na ostřílené dvojici PHP 5.2 a databázovém kompletu MySQL 5.1 s webovým správcem PHPMyAdmin 3.1. Vývoj bude probíhat na lokálním serveru Apache ve verzi 2.2. Grafický návrh vznikne v profesionálním grafickém editoru Adobe Photoshop CS2 a pro práci se zdrojovými kódy bude použit pokročilý textový editor – český PSPad 4.5. Přestože v dnešní době už existují poměrně kvalitní a ohebná vývojová prostředí, v tomto ohledu je programátor spíše konzervativní a málokdy je ochoten opustit své návyky a „přesedlat“ na jiný editor, ne-li vývojové prostředí. Je otázkou, zda to není spíše ke škodě, avšak většinou vítězí zaběhlé postupy a neochota se přizpůsobit a investovat drahocenný čas. Aplikace bude testována v nejběžnějších webových prohlížečích – Mozilla Firefox, Internet Explorer, Opera, Google Chrome nebo Safari. Nejkrušnější chvíle zažívá programátor, potažmo kodér, při ladění vzhledu aplikace v produktech Microsoft Internet Explorer, a to zejména kvůli nekompatibilitě jednotlivých verzí, které odlišně renderují různé kombinace HTML tagů s CSS styly. Ve své bakalářské práci z roku 2008 zmiňuji možné zlepšení s příchodem IE 8, které se však z kodérského hlediska stalo spíše zklamáním. Ve stejném duchu a se stejným přáním se dnes vyhlíží verze 9, jejíž beta verze už nějaký týden běží internetem.

.: 39 :.

6.2 Porovnání stěžejních částí 6.2.1 Počáteční konfigurace Nezbytnou nutností před spuštěním projektu na kterémkoliv frameworku je správně nastavit konfigurační direktivy v inicializačních souborech. Leckdy to nebývá snadná záležitost a programátoři mnohdy tráví nejvíce času hledáním správných nastavení v dokumentacích a různých průvodcích a tutoriálech. Přestože základní nástin počáteční konfigurace v kostrách projektu dodávaných v distribuci s frameworkem je, prakticky nikdy se nepodaří bez nutného zásahu napoprvé projekt bezchybně spustit, přestože zpočátku jde třeba jen o jednoduchý výpis proměnné. Počáteční konfigurace u obou frameworků je dle očekávání komplikovaná a hůře zdokumentovaná.

6.2.2 Připojení databáze V základní konfiguraci také běžně bývají sepsána pravidla pro přístup k databázi a některá její hlavní nastavení. U některých frameworků pak lze navíc nastavit tuto konfiguraci separátně pro vývojovou a prezentační verzi aplikace v rámci jednoho souboru. Framework pak podle určitého algoritmu sám detekuje, o jakou verzi se jedná a přístupové údaje a základní nastavení pro databázi správně použije. Tato nadstandardní funkčnost pak šetří čas při vývoji a ladění za běhu, kdy odpadá věčné přepisování konfigurací, či její separace do zvláštních souborů. Jak Nette, tak Zend tímto rozšířením disponují.

6.2.3 Komunikace a práce s databází Práce s databází a zasílání dotazů je odděleno frameworkem díky použití MVC vzoru, kdy práci s databází z principu zajišťuje a zprostředkovává výhradně vrstva Modelu. Tato skutečnost samotná efektně zpřehledňuje jak strukturu aplikace, tak samotnou práci s databází. Pro ještě přehlednější a hlavně uniformovanější přístup k databázi slouží tzv. „databázový layer“, tedy vrstva pro práci s databází. Ta bývá většinou nezávislá na zvoleném frameworku, přesto některé spolupracují lépe, jiné hůře. Vyskytuje se zpravidla ve formě rozšíření pro daný framework a v dokumentaci bývá některý z nich přímo doporučen. 6.2.3.1 Nette: Dibi Pro Nette byl vybrán databázový layer Dibi, jehož autorem je rovněž David Grudl, zakladatel samotného frameworku. Už jen tato skutečnost svědčí o zamýšlené maximální

.: 40 :.

možné kompatibilitě obou celků. Navíc, testy ukázaly, že Dibi se v rychlosti může směle rovnat s některými ORM řešeními, např. Doctrine2. Dibi je vyvíjeno paralelně právě s Nette. Jeho vývoj dodržuje implementační zákon KISS (Keep-it-simple), tedy především si zachovat maximální jednoduchost. Ta tkví v „přehledném zápisu SQL dotazů, snadný přístup ke svým metodám, nadstandardní funkce pro jednoduché opakované úkony, automatická podpora konvencí a formátování speciálních typů (datum, řetězec), sjednocení základních funkcí“. [43] Všechny autorem zmíněné výhody byly v pozdější implementaci aplikace potvrzeny a zúročeny. Velice jednoduchá je práce se statickou metodou Dibi::query() s rozmanitými parametry a možnostmi použití. Pravdou je, že zápisy některých složitějších dotazů bylo pracnější do dibi syntaxe zapsat, důsledkem toho však byla zachována maximální přehlednost zápisu dotazu. Chyby v dotazech lze velice snadno ladit skrze další statickou metodu Dibi::test(), která má totožnou parametrickou část jako Dibi::query() a vrací konečný SQL řetězec zaslaný databázi. Návratovou hodnotu metody Dibi::query() lze dodatečnými metodami zformátovat podle libosti. Nejefektněji z nich se jeví metody fetchAll() a fetchPairs() pro práci s asociativními poli, popř. fetchSingle() pro jedinou návratovou hodnotu. 6.2.3.2 Zend: Zend_Db_Table Jelikož je rozšíření Dibi platformově nezávislé, nejvíce se nabízelo jeho použití i v Zend Frameworku. Nakonec bylo kvůli rozmanitosti srovnání zvolen nejběžnější způsob komunikace s databází pro Zend Framework – a to skrze Zend_Db_Table. Zend_Db_Table je jedna ze základních částí Zendu a dnes je již považována za část jeho jádra. Pracuje s návrhovým vzorem TableDataGateway a jedná se o abstraktní třídu, jejímž potomkem, který ji implementuje, se stává konkrétní třída v aplikaci, která má již nějaký specifický účel. Příkladem může být třída Zapasy, která od Zend_Db_Table dědí a nastavuje její parametry. Vytvořením instance této třídy lze pak s tímto objektem pracovat jako s tabulkou. Obsahuje metody, které implementují očekávatelné operace nad tabulkou. Data lze dolovat podobným způsobem jako u Dibi, přes metody nad objektem, jako např. fetchAll() nebo fetchPairs(), kde se bohužel objevují problémy s rychlostí kvůli neoptimální implementaci. Zásadním krokem při ukládání dat po vytvoření instance je vytvoření nového záznamu skrze metodu createRow(), s jehož instancí lze pak jednoduše pracovat. Ukládání dat přes veřejné proměnné třídy např. $row->id_team = 1 a následné operaci $row->save() pro uložení záznamu jsou samozřejmostí. Díky uložené proměnné s asocia-

tivním polem sloupců tabulky lze ukládat jednotlivé položky iterativně a další výhody, které z toho plynou.

.: 41 :.

6.2.4 Autentizace S rozdělením aplikace na dva nezávislé moduly – prezentační a administrační – vzniká potřeba odstínit běžného uživatele od správce, který má povolen vstup do administrační části aplikace a může se tak aktivně podílet na tvorbě jejího obsahu, což běžný uživatel z logických důvodů dovoleno nemá. Zde právě nastává chvíle pro zavedení autentizace do systému. Běžně se tak děje přes jednoduchý formulář, skrze který dochází ke kontrole údajů uživatelského účtu a následné autentizaci. Ověřování probíhá zpravidla dynamicky pomocí údajů z databáze. Autentizace v tomto projektu byla umístěna na frontend, tedy do prezentační části, a to z důvodu, že mimo umožnění vstupu do administrační části bude autentizace ovlivňovat také prezentační modul aplikace – a to zejména v zobrazování profilu uživatelů. 6.2.4.1 Nette: Authenticator V Nette je autentizace předpřipravena v podobě rozhraní IAuthenticator, která obsahuje jedinou metodu authenticate(), kterou je nutné v potomkovi implementovat. Framework sice nabízí jednoduchého potomka SimpleAuthenticator, účelům aplikace však jeho struktura nevyhovovala a bylo nutné naimplementovat vlastní řešení. Kód autentizace je protkán naskrz celou aplikací. Potomek třídy IAuthenticator tedy obstarává samotnou autentizaci. Komunikuje s modelem entity Users, skrze který zjistí v databázi shodu s údaji z formuláře, které jsou předávány parametrem. Heslo je zakryptováno pomocí algoritmu sha113, jehož implementace je součástí vnitřních funkcí PHP. V případě úspěšné autentizace vrací instanci objektu NIdentity s personálními údaji uživatele, v opačném případě vyhazuje výjimku. Správu celé autentizace pak obstarává zvláštní presenter, který zajišťuje vykreslení stránky autentizace. Tedy buď přihlašovací formulář, či přesměrování na úvodní stranu při úspěšné autentizaci. V neposlední řadě je třeba obstarat zákaz vstupu na stránky (presentery), které autentizaci podléhají. Rychlým, avšak nesystémovým řešením je přidání zvláštního kódu na začátek každé takové stránky, který obstarává zákaz vykreslení dalšího obsahu nepřihlášeným návštěvníkům. Mnohem lepším řešením je vytvoření předka všech chráněných tříd, kde se vyřeší v rámci speciálních děděných metod, které se provedou ještě před renderováním stránky. V případě Nette jsou to metody startup() nebo beforeRender().

13

SHA1 (Secure Hash Algorithm) – kryptografický hashovací algoritmus s konstantní délkou otisku; v PHP aplikacích nahradil překonané MD5, o jeho prolomení se v současnosti vedou diskuze

.: 42 :.

6.2.4.2 Zend: Auth_plugin Zde se řešení poněkud liší. Kvůli nezaintegrování autentizace přímo do jádra frameworku je sice také nutné zaregistrovat a použít externí plugin, samotná autentizace však probíhá mírně odlišně. A to skrze jeden z předpřipravených autentizačních adapterů. Kvůli srovnání byl vybrán adapter, který pracuje s tabulkou databáze – Zend_Auth_Adapter_DbTable(), jehož konstruktor v parametru přijímá jednak defaultní adapter pro používanou databázi (nastavenou v konfiguraci aplikace), poté název tabulky s uživateli, a následně takzvané credentials, které v tomto kontextu znamenají přihlašovací údaje. Využito je i dalšího parametru pro kryptování, kde je opět použit algoritmus sha1. V řeči jazyka PHP, pak zápis vypadá takto: $dbtable_adapter = new Zend_Auth_Adapter_DbTable( Zend_Db_Table_Abstract::getDefaultAdapter(), 'users', 'login', 'password', 'SHA1(?)' );

Poté se do adapteru předají hodnoty z formuláře a může dojít k samotné autentizaci přes singleton instanci třídy Zend_Auth a její metodu authenticate(), které se parametrem předá právě vytvořený adapter. Návratovou hodnotou je výsledek autentizace, který lze uložit přímo do objektu Zend_Auth, potažmo do jeho skladovacího prostoru (storage), pomocí metody write() nad jeho instancí. Takto uložené hodnoty lze pak kdekoliv (nejlépe ve vrstvě View) opět staticky přes singleton snadno vyvolat. Stejně jako v případě řešení v Nette nelze opomenout hlídání vstupu na chráněné stránky. Lze to vyřešit buď stejně jako u Nette nadřazeným presenterem (v Zendu controllerem), nebo použít elegantnější řešení skrze nový controller plugin, kde pak dochází k potřebným ošetřením, či přesměrováním.

6.2.5 Autorizace Nejen kvůli hláskové podobnosti se slovem autentizace se jejich význam často zaměňuje. Autorizace je však, hned po autentizaci, dalším logickým krokem k identifikaci uživatele. Jedná se o přidělování práv různého charakteru již autentizovaným uživatelům. Zpravidla bývá doprovázeno vytvořením skupin s hierarchicky přidělenými právy a přidělením uživatelů do těchto skupin. I autorizaci lze opět řešit buď statickou, nebo dynamickou cestou. Byl zvolen jednodušší statický způsob, který plně dostačuje potřebám ukázkové aplikace v rámci této práce i pozdějšímu rozšíření.

.: 43 :.

6.2.5.1 Nette: NPermission U Nette šlo opět o nejjednodušší možné řešení. Předpřipravená třída NPermission, implementující rozhraní IAuthorizator, je implementovaná tak, že její potomek se stará opravdu pouze o nastavení práv, ostatní logiku obstarává třída sama. Je tedy opět dobré jít cestou tvorby zásuvného modulu, tedy objektu, který z třídy NPermittion dědí a staticky nastaví práva jednotlivým skupinám, potažmo uživatelům. Je využit princip ACL (Acceess Control List), který obstarává přidělení práv skrze 3 základní součásti: role, zdroje, práva. Ukázka jednoduché práce s ACL je patrná z následujícího příkladu. public function __construct() { /* ROLE */ $this->addRole('guest'); $this->addRole('user', 'guest'); $this->addRole('admin'); /* ZDROJE / PRESENTERY */ $this->addResource('Front_DefaultPresenter'); $this->addResource('Admin_HomePresenter'); /* PRÁVA */ $this->allow('user', 'Front_DefaultPresenter', array('index')); $this->allow('admin', NPermission::ALL, NPermission::ALL); }

Jak vypovídá zdrojový kód, v konstruktoru potomka tedy se nejprve nadefinují role (skupiny), které budou použity. Druhý parametr funkce addRole() je určený k uvedení předka, od kterého daná role zdědí všechna jeho práva. Následně je třeba zaregistrovat chráněné zdroje (presentery), které budou autentizaci a autorizaci podléhat. Naposled určíme samotná práva pro jednotlivé skupiny, kde lze opět využít výhody pokročilého routování v Nette. Práva se totiž vážou jak na jednotlivé presentery, tak na akce v presenterech obsažené (zde seřazené v poli). Z prvního pravidla lze vyčíst, že uživatel ze skupiny user má právo prohlížet pouze stránku, obstarávanou presenterem Front_DefalutPresenter, kde navíc může zobrazit pouze pohled v rámci akce index. Druhé pravidlo pak dovoluje uživateli ze skupiny admin prohlížet všechny chráněné stránky a všechny jejich akce, což je zapsáno pomocí konstant třídy NPermition. 6.2.5.2 Zend: Zend_Acl I autorizace v Zendu je vystavěna na ACL, stejně tak routování stránek. V jádru se tedy zápis práv příliš lišit nebude. Rozdíl je ve formě předávání parametrů funkcí, které je zde řešeno poněkud komplikovaněji předáváním hodnoty skrze novou instanci

.: 44 :.

Zend_Acl_Resource či Zend_Acl_Role objektu. Ovšem logika registrací zdrojů, rolí a rozdělování práv naprosto odpovídá řešení v Nette, které od Zendu v mnohém čerpá. Nutno podotknout, že zde je to rozhodně ku prospěchu věci. Totožné je i řešení kontroly práv v aplikaci, a to velmi jednoduše. Děje se tak zavoláním metody isAllowed(), kde se předávají parametry ve stejném pořadí: role, zdroj, akce. Funkce vrací booleovskou hodnotu, tedy přímo se nabízí pro použití v podmíněných příkazech. V Nette se u volání této funkce upouští od parametru role, poněvadž samotné volání funkce probíhá v rámci objektu User, kde je role přihlášeného uživatele přímo uložena, není tedy nutné ji explicitně zadávat.

6.2.6 Formuláře a jejich správa Jednou z velmi důležitých částí každého frameworku jsou formuláře. Web, který nemá působit staticky, se bez formulářů neobejde. Zajišťují interakci s návštěvníkem stránek v prezentační části webu, a jsou pak hlavně nezbytnou součástí administrace, kde jako jediná skupina prvků v rámci HTML dokáže aktivně pracovat s obsahem stránek a podílet se na tvorbě změn. Ne každý framework však disponuje implicitní implementací jejich správy. 6.2.6.1 Nette: NAppForm Nette nebere zpracování formulářů na lehkou váhu, ba dokonce na nich zakládá svou pověst. Autor frameworku si při jeho stavbě uvědomoval nemalá bezpečnostní rizika, spojená s odesíláním formulářů a věnoval značné úsilí k jejich, jak sám nazývá, „neprůstřelnosti“. Navíc se snažil stále držet pravidla KISS a udělat celou správu formuláře co nejvíce transparentní. [44] Doporučené řešení pro vykreslení formuláře v Nette je skrze komponenty, které slouží pro obalení a identifikaci nějakého celistvého kódu v rámci aplikace. Jsou pak např. snáze použitelné v rámci vykreslování pohledů atp. Použití je opět maximálně snadné. Stačí vytvořit instanci třídy NAppForm a v rámci ní pak jednoduchými připravenými metodami přidávat formulářové prvky. Na konci je pak třeba nastavit funkci, která se bude volat po odeslání formuláře, tzv. callback a celou instanci vrátit jako návratovou hodnotu celé komponenty. $form = new NAppForm(); // ID $form->addText('id', 'ID') ->setDisabled();

.: 45 :.

// NÁZEV $form->addText('title', 'Název') ->addRule(NForm::FILLED, MyAppForm::FILLED_TEXT); $form->addSubmit('save', 'Uložit'); $form->onSubmit[] = callback($this, 'processForm'); return $form;

Takto lze napsat jednoduchý formulář o dvou textových políčkách a jednom tlačítku. Nette propaguje názor mít pro každou formulářovou komponentu vlastní jednoduchou metodu, která daný prvek a jeho chování do komponenty přidá. Existují tedy i další předpřipravené metody jako addSelect(), addPassword(), atp. K prvkům formuláře se dá později přistupovat jako k prvkům pole, tedy přes hranaté závorky, např. $form['title']. Takže lze jednoduše dodatečně přidat třeba další validátor. Validátory formulářových prvků v Nette jsou další velkou kapitolou, o které je třeba se zmínit. Jednoduchá validace je nezbytná hlavně u formulářových prvků pro vstup z klávesnice, tedy text a textarea. Pokročilejší validaci je pak nutné nasadit tam, kde je třeba ošetřit závislosti nebo návaznosti jednotlivých prvků mezi sebou. [11] Validátory v Nette se tvoří za pomoci dodatečných metod addCondition() a addRule(). Jejich správnou kombinací lze ošetřit prakticky všechny nestandardní události nad prvkem. Lze použít nejběžnější vestavěné validátory pro kontrolu délky řetězce nebo ověření, zda se jedná o korektní URL nebo e-mailovou adresu. Mocný a hojně využívaný je vestavěný validátor pro kontrolu řetězce naproti regulárnímu výrazu. Velkou výhodou je možnost napsat vlastní validátory v podobě funkcí, kterým se předá jakýkoliv parametr k booleovskému vyhodnocení. Příklad použití vestavěného validátoru pro URL adresu: $form->addText('www', 'WWW') ->addCondition(NForm::FILLED) ->addRule(NForm::URL, 'Zadaná URL nemá správný tvar!');

6.2.6.2 Zend: Zend_Form Zend začlenil implicitní správu formulářů až do své verze 1.5, do té doby bylo na programátorovi, aby vyvinul vlastní zásuvný modul pro jejich správu, nebo, v tom horším případě, psal jejich HTML kód ručně. Tvorba formulářů v Zendu je od Nette mírně odlišná. Každý formulář je potomkem třídy Zend_Form, v jehož přetíženém konstruktoru probíhá nastavení a tvorba formuláře. V Zendu se jednotlivé formulářové prvky generují skrze instance příslušných tříd. Tedy každý formulářový prvek tvoří jeden objekt, který jej reprezentuje. Po bližším pro-

.: 46 :.

zkoumání je tomu u Nette v podstatě stejně, tam je však vytvoření instance daného objektu zapouzdřeno do „továrny“, tedy metody, která vytvoření správné instance zajišťuje, což vede k lepší použitelnosti a zpřehlednění kódu. I Zend disponuje validací formulářů. Jejich navázání na formulářovou komponentu probíhá podobně jako u Nette, skrze funkci addValidator(), které se předá instance některého z mnoha zabudovaných validátorů v Zendu. Díky pokročilému načítacímu robotovi Zend_Loaderu, lze, stejně jako u Nette, předávat validátoru pouze řetězec s patřičným jménem. Není tedy nutné vytvářet instanci implicitního validátoru, je možné mu předat pouze daný název v řetězci. Rozdíl mezi oběma zápisy: skrze instanci: $length_validator = new Zend_Validate_StringLength; $length_validator->setMin(8); $form_item->addValidator($length_validator);

a skrze řetězec $form_item->addValidator('StringLength', false, array(8));

Taktéž lze vytvořit validátor podle vlastních potřeb. Bohužel, jeho tvorba a nasazení nejsou tak jednoduché a transparentní jako u Nette. Formou pluginu je třeba vytvořit novou třídu, která dědí z abstraktní třídy pro validátor – Zend_Validate_Abstract. Musí následovat nastavení proměnných třídy a konstant a přepsání důležité metody isValid(), která pak vrací onu chtěnou booleovskou hodnotu. Navíc se situace komplikuje v případě, že formulář je rozsáhlý a komplikovaný a validátorů (tzn. i tříd a souborů) přibývá.

6.2.7 Ostatní srovnání Několik srovnání některých částí implementace zde nebylo rozebráno, přesto si zaslouží alespoň menší zmínku. Jsou jimi zejména routování, vrstva pohledů, tvorba odkazů nebo souborová struktura aplikace. 6.2.7.1 Routování Routování zajišťuje správné směrování požadavku zvenčí (tedy od uživatele) k odpovídajícímu zpracování a předání k výstupu. U webových aplikací se tak děje skrze URL. Nette disponuje pokročilým routovacím systémem, což bylo jedním z hlavních podnětů pro realizaci aplikace jeho prostřednictvím. Především snadný zápis rout a podpora „cool url“ z něj dělá mocný nástroj. Routování spolu s MVC architekturou pak umožňují efektivně parsovat URL adresu a jednotlivé části pak mapovat na samotné presentery

.: 47 :.

a dílčí akce. Díky tomu je pak vyřízení požadavku pro programátora přehlednější a transparentnější. Zend framework ve svém základu používá pouze jednoduchý router. Dává sice prostor pro vytvoření vlastního routeru, ale řešení není příliš optimální ani jednoduché. 6.2.7.2 Vrstva pohledů View vrstva v architektuře MVC tvoří uživatelské rozhraní a generuje a formátuje výstup v HTML. Úzce spolupracuje s presenterem (controllerem), či přímo s Modelem, od kterých přijímá data, která formátuje pro výstup. Jedná se o jednu z hlavních výhod modelu MVC, tedy o oddělení aplikační logiky od té zobrazovací. Oba frameworky mají systém šablon (templatů) zpracován velmi podobně. V presenteru či controlleru, spíše tedy v rámci jejich akcí, lze view vrstvě předat hodnoty skrze proměnné $this->template (Nette) nebo $this->view (Zend), kde jednoduchým začleněním nové proměnné umožní šabloně přistupovat k ní, jako ke své lokální proměnné. Následující příklad ukazuje, jak lze jednoduše předat hodnotu k vypsání v šabloně. Nette presenter: $this->template->user_name = $this->model->getUserName($id);

Nette view:

{$user_name}

V příkladu je nastíněna komunikace mezi všemi třemi vrstvami MVC. V presenteru se do nové proměnné pro šablonu uloží výsledek metody modelu, která dle id vrací jméno uživatele. V šabloně (tedy ve view vrstvě) se pak snadno k proměnné přistoupí a vypíše se. Nette navíc v šablonách používá vlastní filtr (Latte14) pro usnadnění zápisu kódu, které mimo jednoduchého výpisu proměnných umožňuje používat základní podmínky, cykly a nepřeberné množství maker, což ještě víc zpřehledňuje a zefektivňuje zápis šablon. Oba dva frameworky pak podporují tzv. „dvoufázové renderování šablon“, které spočívá v rozdělení šablon na statickou část (layout), která se takřka nemění (možnost změny tu samozřejmě je), a dynamickou část, kterou tvoří šablony napojené na jednotlivé akce presenterů, či controllerů. 6.2.7.3 Tvorba odkazů Jak bylo zmíněno u routování, URL adresa je parsována a její části přiděleny odpovídajícím presenterům a akcím, které si zpracování požadavku rozdělí. S tím úzce souvisí i tvorba odkazů v obou frameworcích.

14

Latte filtr, dříve CurlyBrakets, založený na syntaxi zápisu pomocí složených závorek

.: 48 :.

Nejjednodušší vytvoření URL adresy je samozřejmě její jednoduché vypsání, či spojení skrze některou řetězovací funkci. Není to ovšem zdaleka tak efektivní, jako poskládat ji z logických celků, které tvoří logiku aplikace. Právě to Zend i Nette umí. Zápis takto složené URL adresy pak v Zend Frameworku vypadá následovně: $this->url(array("controller" => "Index", "action" => "default", "order" => "ascending“));

Nette posunulo tento zápis blíže k dokonalosti: $this->link(Index:default, array("order" => "ascending"));

Presenter lze dokonce vynechat, pokud se jedná o odkaz na akci v rámci stejného presenteru. Takto nejenže efektně zapíšeme požadavek na konkrétní akci a předáme jakýkoliv parametr, ale dochází zároveň i ke kontrole existence cílového odkazu a vyhnutí se problémům např. při přejmenování některé sekce. Všechnu tuto činnost obstarává router. 6.2.7.4 Souborová struktura aplikace Oba frameworky v základním balíku obsahují základní kostru aplikace, zvanou „skeleton“, na níž se pak aplikace staví. Její struktura v Nette do značné míry vychází z řešení v Zend Frameworku. Striktně odděluje část, která je publikovatelná, od části aplikační, obstarávající logiku aplikace. Přístup k jednotlivým částem je rozdělen a spravován .htaccess soubory na jednotlivých úrovních aplikace. Publikovatelná část schraňuje soubory, které se týkají operací na straně klienta. Jde tedy o kaskádové styly, obrázky, flash, javascriptové knihovny a také případné složky pro cache soubory. V případě obou frameworků je silně doporučeno dodržovat danou adresářovou strukturu, kvůli předejití problémům s načítáním a zabezpečením. Není to však striktně vyžadováno a oba frameworky jsou strukturálně nezávislé.

.: 49 :.

6.3 Srovnání s CMS Netwings Komerční framework Netwings spadá v současné době již spíše do kategorie CM systémů, tzn. mezi komplexní redakční či publikační systémy. Jedná se tedy nejen o framework, ale o kompletní řešení publikačního systému v backendu a základní kostru pro frontend. S oběma vybranými frameworky jej tedy nelze přímo srovnat, jelikož značná část implementace je již hotová, což nutí programátora k dodržování početných konvencí a využití stávajícího řešení. Nicméně, srovnání řešení vybraných částí možné je.

6.3.1 Počáteční konfigurace Projekty postavené na Netwings jsou po dobu vývoje separované od vlastního frameworku, který je všemi projekty globálně načítán z jednoho umístění, aby tak mohlo docházet k efektivnímu vývoji a správě frameworku samostatně. Teprve v momentě vystavení na ostrý web se Netwings stane součástí projektu. Počáteční konfigurace se tedy skládá z inicializace databáze, připojení k frameworku a založení repozitáře pro nový projekt, který je v základu velmi strohý. Nicméně, vnitropodnikové konvence poměrně jasně určují logickou a adresářovou strukturu budoucí aplikace.

6.3.2 Připojení a práce s databází Netwings je primárně určeno pro práci s databází PostgreSQL, podpora pro MySQL či jiné databázové systémy vymizela postupně se staršími verzemi, což je zapříčiněno novými triggery a speciálními databázovými funkcemi. Verzi 6 lze tedy nainstalovat pouze s PostgreSQL. Netwings disponují vlastním databázovým layerem, který prošel dlouhým vývojem, a jeho použitelnost se za tu dobu značně zvýšila. Příčinou je také přechod na moderní MVC model, který v předchozích verzích chyběl. V počátcích verze 6 šlo tedy spíše o „MC model“, poněvadž chyběla práce se šablonami a výpis HTML obstarávaly jednotlivé třídy pro práci s logikou aplikace – tedy jakési controllery. S vývojem verze 6 tedy přešly Netwings ke skutečné MVC architektuře. Práci s daty a komunikaci s databází tedy řeší vrstva Model, kterou není potřeba implementovat. Jednotlivé modely je nutné pouze nakonfigurovat, což Netwings řeší efektivně přes konfigurační XML soubor, a později v redakční sekci nainstalovat. Tento systém umí v základu řešit všechny potřebné způsoby komunikace s databází a lze nakonfigurovat všechny typy vazeb, dokonce i složitější vazby typu m:n.

.: 50 :.

Každý model samozřejmě reprezentuje zvláštní třída, což znamená, že případné nadstavby lze ručně do modelu doprogramovat.

6.3.3 Autentizace a autorizace Autentizace je zde řešena až při vstupu do redakční části aplikace. Při inicializaci projektu dojde k vytvoření uživatele typu správce, který pak při příchodu do backendu aplikace může vytvářet další uživatele a přidělovat je do skupin s určitými právy. Autorizace je řešena dynamickým ACL a správce může vytvářet nejen nové uživatele, ale i nové skupiny a dynamicky jim přidělovat a upírat práva, a to buď na celé sekce nebo pro jednotlivé operace.

6.3.4 Formuláře Formuláře v Netwings také prošly delším vývojem. Ve starších verzích a zpočátku i ve verzi 6 obstarávala správu formulářů pouze jedna třída Form, která obsahovala metody pro různé operace s formulářem. Od inicializace, přes otevření a uzavření formuláře, po vykreslení jednotlivých komponent, které generovala zpočátku pouze jedna metoda nepříliš efektivní cestou – rozsáhlým podmínkovacím systémem. Později v raném stádiu verze 6 byla třída upravena a rozšířena o samostatné metody reprezentující jednotlivé formulářové entity. Nedávno Netwings přešly na zcela nové generování formulářů, které je srovnatelné s implementací v soudobých moderních frameworcích, kde každou formulářovou komponentu reprezentuje vlastní třída, která je součástí rozsáhlého návrhu formulářové hierarchie. Co nové generaci formulářů v Netwings chybí, je rozsáhlejší validování prvků. V současné době prakticky nelze připojit ke komponentě jakýkoliv validátor, což je mimo jiné způsobeno prozatímní slabou podporou customizace jednotlivých komponent.

6.3.5 Ostatní srovnání Routovací systém v Netwings je pouze základní. Využívá se jednoduchého routeru, který je svázán poměrně jasnými pravidly. Na první pozici je vždy označení jazykové mutace, druhá pozice je pak vyhrazena pro název sekce. Další pozice jsou routovány podmíněně a je třeba je ošetřovat logikou aplikace. Navíc jsou implicitně zakázány a v případě dalšího zanořování je třeba v konfiguraci sekce povolit. Šablony (templaty) jsou také výhradně záležitostí poslední verze Netwings. Nutno dodat, že jako u kteréhokoliv jiného frameworku došlo k výraznému zpřehlednění a zefektivnění výpisu stránek. K předávání proměnných s obsahem k výpisu nedochází skrze view proměnnou, ale za pomoci metody s názvem šablony a polem proměnných v parametrech.

.: 51 :.

Dále je třeba zmínit, že šablony nejsou úzce svázány s jednotlivými akcemi, jako je tomu u Nette i Zend Frameworku, a lze je pomocí dané metody vypsat i opakovaně kdekoliv v rámci kódu třídy sekce. S tím se pojí i tvorba odkazů, která není nijak propojená s routerem a URL pro odkazy se skládá manuálně za sebe pouze skrze spojovací funkci. Na druhou stranu, Netwings tyto nedostatky vyvažuje propracovanou administrací, v základu vybavenou podporou pro jazykové mutace a přehlednou dynamickou správou sekcí.

.: 52 :.

6.4 Implementace mikroformátů Mikroformáty jdou napříč všemi spektry technologií i všemi frameworky. Jejich implementace je vzhledem k jejich přínosu nepoměrně snadná. Jde zejména o osvojení si syntaxe a účelné, opodstatněné a citlivé umístění. Alokace samotného kódu z hlediska MVC návrhu je jasná. Vrstva View je jediná, kde má zápis mikroformátů smysl. Právě i při implementaci mikroformátů programátor ocení aplikaci třívrstvé architektury MVC, díky níž je zápis mikroformátů maximálně přehledný. V ukázkové aplikaci v rámci této práce byly implementovány tři zásadní mikroformáty. Dva z nich lze řadit do stabilních mikroformátů – hCard a hCalendar, a byl přidán i jeden z draftů (s rozpracovanou specifikací) – hAtom.

6.4.1 hCard Mikroformát hCard je z použitých tří nejrozšířenější a nejpoužívanější. Jak bylo zmíněno, jedná se o označení určité osoby a jejích vlastností a kontaktních údajů. Jeho použití se v rámci aplikace váže k jednotlivým uživatelům v systému, bez výjimky. Jelikož veškeré zobrazení uživatelů v prezentační části webu obstarává jeden presenter, lze vložit a případně měnit kód hCard mikroformátu v detailu uživatele na jednom místě, což je především zásluhou objektového návrhu, potažmo možnosti dědění. Následující příklad ukazuje, jak je implementace hCard, ale obecně všech mikroformátů, snadná v kombinaci s objektovým PHP, MVC návrhem a Nette Latte filtrem.

Pole s personálními údaji obsahuje dodatečné personální údaje, na které lze napojit další atributy hCard, jako např. date_of_birth, addreess nebo phone.

.: 53 :.

Pomocí programů, či doplňků, které umí s mikroformáty pracovat lze pohodlně vygenerovat vizitku typu vCard, která je čitelná v mnoha aplikacích pracujících s kontakty. Na Obrázek 11: Export hCard a výsledné zobrazení v adresáři poštovního klienta Mozilla Thunderbird lze vidět jednoduchý export do vCard za pomoci doplňku Operator v prohlížeči Mozilla Firefox, dále pak zobrazení vygenerované vizitky poštovním klientem Mozilla Thunderbird, které ovšem nedisponuje implicitní podporou vCard, je třeba doinstalovat doplněk LookOut.

Obrázek 11: Export hCard a výsledné zobrazení v adresáři poštovního klienta Mozilla Thunderbird

6.4.2 hCalendar hCalendar lze spojit s jakoukoliv kalendářní událostí. V aplikaci pak znamená nasazení na seznam zápasů a jejich případných detailů. Následující příklad reprezentuje nasazení hCalendar v detailu zápasu.