Základní koncept aplikace
Pluginy

Kód, který je třeba pravidelně spouštět, je umístěn v pluginech. Tato funkčnost nám umožňuje vkládat kód na všechna požadovaná místa, bez toho, aby jsme tato místa upravili či o nich předem věděli. Názorně je tato funcionalita použita v pluginu Acl (spáva přístupovách práv) a ModularPath (načtení knihoven používaných v konkrétním modulu).

Plugin ModularPath (Obr. 5.) načítá celou modulární strukturu, nastaví include_path pro vložení dat jednotlivých modulů, nastaví layout a zapne ukládání cache. Plugin ViewSetup obstará nastavení view a sestavení výchozí hlavičky stránky odpovědi. Plugin Acl zabezpečuje přístup do administrace všech modulů – to je možné právě díky tomu, že je plugin zpracován pokaždé. Z instance Zend_Auth identifikuje uživatele a pomocí Zend_Acl zjistí jeho oprávnění vstoupit do administrace.
Každý modul má následně své vlastní pluginy, které se nahrávají opět dynamicky. Systém projde všechny adresáře dostupných modulů a zaregistruje jejich pluginy. Zaregistrovány jsou tedy všechny pluginy existujících modulů i systémové moduly zabezpečující chod aplikace.
Při použití návrhového vzoru MVC je využití pluginů ideální možností, jak ovlivnit průběh zpracování. Jde o velmi přehledné a čisté řešení.

Obrázek č. 5 – Plugin ModularPath

Konfigurace

Konfigurační soubor config.ini obsahuje krom dat použitých k připojení k databázi ještě další data, která budeme dále potřebovat. Knihovna Zend_Registry je aplikací návrhového vzoru Registry [29] pro uchovávání globálních proměnných
a všechna data, která jsou v aplikaci potřeba na více místech, se ukládají zde.
Uchovávání globálních dat je samozřejmě možné i v čistém php, Zend_Registry je však přínosná třída i při samostatném použití v libovolné aplikaci. Obstará veškerou práci s uchovávání dat pouze pomocí dvou jednoduchých metod set a get.

Zobrazení

Každá action je vykreslena do příslušeného view. Jmenná pravidla Zend frameworku určují jak umístění, tak pojmenování. Toto výchozí chování není třeba měnit. Každý modul má dva výchozí layouty, ve kterých se skládají jednotlivé view. Jeden pro běžné uživatele a jeden administrační.
Vývoj

Třída NDebug patří do frameworku Nette. Velmi ulehčuje vlastní programování a systémem zobrazování šetří programátorův čas. Při výjimce vrací PHP zcela nepřehledný text, ve kterém chybí mnoho dat, pro ladění dobře použitelných. Při používání NDebug třídy je naopak výjimka velmi dobře popsána všemi dostupnými prostředky jako klasický debugger, jak je znám z jiných programovacích jazyků. Implementace ve frameworku Zend je velmi jednoduchá a byť nabízí Zend vlastní třídu Zend_Debug, zdaleka nedosahuje takových kvalit jako NDebug. Ve finální aplikaci musí být funkčnost této třídy vypnuta, z bezpečnostního hlediska se jedná o velmi nebezpečnou záležitost.

Řešení vybrané problematiky

V následujícím textu je řešena vybraná problematika porovnáním vývoje
v čistém PHP a frameworku. Důraz je kladen na vývoj pomocí frameworku, protože vývoj pomocí čistého PHP je většinou intuitivní a řeší stejné věci jako framework. Na ukázkách zdrojového textu jsou dokumentovány specifické vlastnosti frameworku
a efektivita práce s ním. Proto je v textu týkajícího se frameworku předpokládáno použití stejných obecných postupů řešení, jako při použití čistého PHP.

Modul User

Tento modul má dvě základní funkce, registraci nových uživatelů a jejich přihlášení. Při registraci je třeba zadat údaje rozdělené do dvou kategorií, na povinné
a nepovinné. V následující fázi se uživatel může přihlásit – toto přihlášení je nutné uchovat pro všechny části aplikace a ošetřit, aby se nepřihlášený či nepovolaný uživatel nedostal na administrační stránky. Samozřejmě je nutné mít možnost se odhlásit.

Registrace

V aplikaci musí být umožněno registrovat se neregistrovaným uživatelům. Registrační formulář obsahuje následující pole:
• Uživatelské jméno
• Heslo
• Jméno
• Příjmení
• Email
• Ulice
• Město
• Směrovací číslo
• Telefon
• Stát

Uživatelské jméno a heslo jsou povinné položky, ostatní volitelné. Protože se jedná o jednoduchou aplikaci, je nutná validace pouze emailové adresy. V první části je nutno ověřit syntaktickou správnost, ve druhé pak na zadaný email můžeme odeslat kontrolní zprávu a zjistit tak, jestli uživatel tuto schránku skutečně používá.

Registrace – čisté PHP
Prvním problémem se ukáže nalezení vhodného řešení pro validaci emailové adresy, což může být velmi obtížné. Nejprve je nutné nastudovat dokumentaci a normy, nejdůležitější jsou [30][31][32][33]. Jedno z řešení nabízí Jakub Vrána na svém blogu [3], jehož implementace může vypadat tak, jak je znázorněno na obrázku Obr. 6.
Obrázek č. 6 – Kontrola platnosti emailové adresy

Po kontrole adresy je nutno zkontrolovat, jestli jsou povinné položky vyplněné. Všechny položky je také nutno ošetřit proti SQL Injection [26]. Dále je nutné toto vše zakomponovat do aplikace, ukládat a zobrazovat chybové stavy.
Obrázek č. 7 – Kontrola emailové adresy a její uložení

Registrace – framework
Registraci obstarávají dva controllery, první pro úvodní stránku tohoto modulu zobrazí stav přihlášení. Tento stav přihlášení budeme i nadále potřebovat proto je vhodné někde si tuto hodnotu a přiřazený text uchovat. Tuto funkčnost usnadňuje helper FlashMessenger a nový helper LoggedInUser, který využívá funkce uchování textů FlashMessengeru a můžeme ho použít kdekoliv v aplikaci. Ideální je tak umístění do postranního panelu, kde bude nepřihlášeným uživatelům nabízet možnost se registrovat či přihlásit.  V případě že je uživatel nepřihlášen, ve zmíněném textu je odkaz na další controller, který se postará o registraci či případné přihlášení a odhlášení.

O kompletní správu formulářových polí se stará Zend_Form, Zend_Validate
a Zend_Filter. Na autorech frameworku tak zcela necháváme logiku ověřování emailové adresy a kontrolu vyplnění vyžadovaných položek. Taktéž oznámení o špatně vyplněných polích.

Obrázek č. 8 – Definice formulářového pole

Po úspěšné registraci je uživatel automaticky přihlášen (viz dále). Při neúspěšné registraci jsou vypsány požadavky pod každým špatně vyplněným polem, v případě jiné chyby je toto oznámeno. V případě neúspěchu jsou také vypsány uživatelem zadaná data. Toto vše obstarává framework. Definice validátorů na obrázku Obr. 8.
Přihlášení

Přihlášení uživatelů je základním požadavkem cílové aplikace. Kromě vyvíjeného modulu pro elektronický obchod může být možnost přihlášení do budoucna potřebná pro jiné moduly (např. Fórum).
Přihlášení musí být umožněno přes zadání jména a hesla.  Přihlášený uživatel musí zůstat přihlášený pro všechny existující moduly napříč celou aplikací.

Přihlášení -  čisté PHP
Při přihlašování pomocí čistého PHP, narazí programátor na základní problematiku uchovávání informací o konkrétním uživateli. Protože jde o rutinní programování, pravděpodobnost výskytu chyb se zvětšuje.

Přihlášení – framework
Zobrazení přihlašovacího formuláře je opět v kompetenci frameworku. View soubor pouze zobrazí formulář, který je vytvořen v příslušné action. Po odeslání jsou data zpracována, heslo a jméno porovnáno s daty uloženými v databázi a uživatel přihlášen, případně nepřihlášen. Tuto skutečnost již dále eviduje Zend_Auth.
Druhou část, autorizaci, obstarává knihovna Zend_Acl. Její funkčnost jednoduše využijeme v pluginu s funkcí routeShutdown(), takže bude volán na konci procesu routování. Nejdříve je třeba zjistit uživatelskou úroveň, případně přiřadit návštěvnickou. Zend_Auth je konstruován jako singleton (V4) jehož instance uchovává právě požadovanou úroveň. Vlastní třídu Zend_Acl musíme nejdříve přetížit a přidat vlastní funkčnost. Touto funkčností je myšleno omezení vstupu do administračního controlleru uživatelům, kteří na to nemají právo. Tato pravidla je třeba načíst z konfiguračního souboru.

Obrázek č. 9 – Přihlášení uživatele

Pravidla přístupu omezují vstup do předem definovaných controllerů, zde pojmenovaných admin_index. Toto pojmenování dle jmenných konvencí frameworku znamená IndexController v adresáři admin. Vývojáři budoucích modulů stačí tedy umístit tento controller správně a o zabezpečený vstup se postará již samotná aplikace. Předpokladem je, že u takto jednoduché aplikace nebude zapotřebí více než jeden controller, avšak i toto lze jednoduše ošetřit.