Minule tu byla praktická ukázka modulu User, dnes modul Shop. Tímto se pomalu blížíme konci seriálu….

Modul Shop

Elektronický obchod slouží k prodeji zboží. Za tímto účelem je z uživatelského hlediska třeba zboží kategorizovat a popsat. Tyto kategorie a přímo produkty je poté potřeba správně zobrazit. K výběru zboží slouží košík, do kterého můžeme zboží přidávat. Zboží, které je v košíku, si může uživatel objednat v závislosti na registraci. V případě že není registrován, je vyzván k zadání kontaktních údajů, v opačném případě jsou tyto údaje předvyplněny. V tomto modulu se poprvé v této aplikaci setkáváme s administrační částí.

Administrační rozhraní

Administrační rozhraní tohoto modulu je jistě nejsložitější částí celé aplikace. Požadavky na toto rozhraní plynou z Use Case diagramu ( Obr. 4).
Administrátor musí mít možnost data přidávat (produkty, kategorie, firmy (dodavatel, výrobce), recenze), upravovat a mazat. Důležitá je samozřejmě následná správa objednávek, kde je nutno zobrazit data zadaná uživatelem, změnit stav objednávky a o této změně upozornit uživatele a následně označit objednávku jako vyřízenou.
Specifické je pak přidávání recenzí k produktům. Toto je umožněno
i registrovaným uživatelům, takto přidané recenze však musí být před zobrazením schváleny z administrace. Pro registrovaného uživatele se tak zčásti jedná o jakousi “veřejnou administraci”.

Administrační rozhraní -  čisté PHP
Opět je nutné zabezpečit administraci proti nepovolaným uživatelům. Vlastní implementace tohoto rozhraní se skládá z velkého množství formulářových polí, kde se velmi často opakují data (např. vložení a upravování produktu).
Tato část je z pohledu čistého PHP na jednu stranu velmi složitá (klade nároky na přesnost a pečlivost), na druhou stranu jednoduše vytvořitelná (nejde přímo o řešení zvláštních problémů, vše je většinou jasné a zřejmé). Pravděpodobně ze zmíněných důvodů je velmi obtížné najít na internetu ukázku či návod na vytvoření administrace. Naopak návodů na vytvoření zbytku elektronického obchodu je velké množství.

Administrační rozhraní – framework
Přístup do administrace je již zajištěn, ke kompletní funkčnosti zbývá pouze naplnit databázi produkty. Kontrola vstupních dat z formulářů je obstarána knihovnou Zend_Form pomocí filtrů a validátorů, je třeba pouze data vložit na správná místa. Díky objektovému přístupu stačí vytvořit instanci konkrétní tabulky a pomocí metody insert vložit do databáze. Tato metoda se implicitně stará o vkládání dat do databáze, při stejném pojmenování sloupců v tabulce a formulářových polí ji lze použít přímo. Často je ale nutné ji v definici tabulky, která je odvozená od třídy Zend_Db_Table, přetížit
a přidat další logiku – zejména při propojování více tabulek.
Přidáním vlastní logiky je myšleno její přetížení a zpracování příchozích dat. Může se jednat téměř o cokoliv, v tomto případě (Obr. 10) jde však o propojení produktu s kategorií. Tento proces je zpracován atomicky, tedy bez možnosti provedení pouze jednoho kroku bez druhého.

Obrázek č. 10 – Přetížení funkce pro vložení dat do databáze


Uživatelské rozhraní

Z pohledu uživatelského rozhraní jde pouze o výpis již uložených dat v databázi. Jde o výpis produktů v kategoriích a následně výpis těchto produktů. V samostatné kapitole je rozebrána implementace nejsložitější části tohoto rozhraní, košíku.

Uživatelské rozhraní – čisté PHP
Právě na běžný výpis dat může být použití čistého PHP ideální. Z programátorského hlediska jde pouze o výběr dat z databáze a jejich kolekce, v případě eshopu seskupení dat o konkrétním produktu. Zdrojový kód potřebný pro tuto funkčnost by proto nebyl nijak rozsáhlý.  Výhodou by bylo zjednodušení kódu a jistě i zrychlení. Jako nevýhoda se pak jeví nesystémovost tohoto kroku a velké omezení v dalším rozvoji aplikace.  Přesto je právě uživatelské rozhraní velmi dobře implementovatelné pomocí čistého PHP.

Uživatelské rozhraní – framework
Opět je vytvořena instance jednotlivých tabulek, jednoduché výpisy lze realizovat přímo, u složitějších přidáme do definic konkrétních tabulek další funkce s požadovanou funkčností.  Při vytvoření instance třídy Products není dostupná žádná funkce, která je schopná vrátit kompletní informace o produktu, protože tyto informace se nacházejí v mnoha jiných tabulkách. Pomocí nové metody getProduct si však tuto funkčnost můžeme lehce dotvořit.

Obrázek č. 11 – Načítání dat z databáze

Košík

Vlastní implementace košíku je opět vypsání dat z tabulky, pouze je třeba rozlišit, jestli je uživatel přihlášen či nikoliv. Dle toho je výběrovým kriteriem session_id (identifikace dle prohlížeče) nebo user_id (identifikace dle registrace).  V dalším kroku, potvrzení nákupu, se dle stejných kriterií případně předvyplní formulář s adresou a ostatními daty registrovaného uživatele.
Košík musí samozřejmě umožňovat uživatelům položky přidávat či je mazat.

Obrázek č. 12 – Obsah košíku

Košík – čisté PHP
Veškerá data potřebná k operacím s košíkem jsou uložena v jedné tabulce. Jedna položka v tabulce představuje jednu položku zboží a tak jde o velmi jednoduchou funkčnost. Jednoduchý návod na řešení pomocí čistého PHP je dostupný na internetu. [7].

Košík  – Framework
Výběr dat z košíku je zobrazen na obrázku Obr. 11.  V controlleru jsou poté provedeny ještě matematické operace – výpočet daně a ceny s daní. Vše je přiřazeno do příslušných proměnných a o zobrazení ve view se nadále stará sám framework.
Přidávání zboží do košíku lze velmi dobře udělat pomocí AJAXu (V9). Při práci s ajaxovými funkcemi je třeba nejprve vypnout zobrazování pomocí layoutů. Uživateli je pak umožněno přidávat zboží bez nutnosti neustále načítat stránku s produktem. Postup je znázorněn na obrázku Obr. 12.

Obrázek č. 12 – Přidávání zboží do košíku

Základní funkce – plugin

Jak již uvedeno, každý modul může mít své vlastní pluginy, obstarávající základní funkce modulu. V modulu Shop se jedná zejména o funkci „přenosu“ uživatelů. Uživatel, který si naplní košík jako nepřihlášený se může následně přihlásit
a je nutné, aby mu zůstal naplněný košík. Naopak přihlášený uživatel se může odhlásit, v tomto kroku je však vhodné data z košíku nepřenášet.

Obrázek č. 13 – Plugin modulu Shop

Systémová část aplikace

Z ukázek kódu výše je patrno, jak jsou vytvořeny dva konkrétní moduly. Modul Shop může být nahrazen libovolným jiným a Modul User lze sice považovat za systémový, nicméně zcela nezbytný být nemusí. Chod celé aplikace je však zabezpečen systémovými částmi.

Pluginy

Jak bylo již naznačeno, základní servis pro všechny moduly plní plugin ModularPath, který načítá všechny potřebné knihovny dynamicky. (via obr 4.jpg).
V tomto pluginu je uloženo i nastavení cache pro všechny dostupné pluginy.
Dále je nutno ochránit vstup do administračních controllerů. Tuto funkcionalitu zajišťuje plugin Acl, který při každém požadavku porovnává požadovaný controller
s controllery označenými jako pouze pro administrátory. Tato funkčnost se mírně překrývá s modulem User, ten však slouží i k registraci uživatelů. Teoreticky může nastat situace, kdy nebude zapotřebí modul User, avšak bude zapotřebí ochránit vstup do administračních controllerů.
Dalším systémovým pluginem je ViewSetup. Tento plugin zajišťuje základní nastavení view a definuje cestu k helperům.
Posledním a velmi důležitým pluginem, je plugin Lang. Tento plugin má na starosti funkčnost jazykových verzí. Prostředkem je zpracování URL a nalezení použitého jazyka a v případě že se toto nezdaří, jazyk není v URL definován, nastavit výchozí jazyk.

Výchozí soubory, nastavení

Jednou z myšlenek objektového programování je i dědičnost. Dědičnosti je využito právě ve výchozích třídách pro všechny použité controllery a formuláře.
Ve výchozím controlleru jde zejména o funkci flash, která slouží k přenosu všech zpráv ze všech controllerů do všech view. Při vývoji dalších modulů tak stačí pouze zprávu uložit a bude dostupná ve všech view napříč celou aplikací

Obrázek č. 14 – Výchozí Controller

Výchozí formulář slouží k nahrazení formátování, jaké poskytuje framework. Přepíše se nastavení všech variant tagů, všechny formuláře budou díky tomuto nastavení v běžných html tabulkách.