mm-marek » Seriál vývoj webových aplikací pomocí php frameworků

Vývoj webových aplikací pomocí PHP frameworků IX – závěr

admin — Fri, 03 Jul 2009 21:53:50 +0000

Posledním dílem je závěr a seznam zdrojů – to se může hodit :) Jako seriál byla vložena moje bakalářská práce – její pracovní verze…
Závěrem práce je třeba zhodnotit použití vybraného frameworku na zhotovené aplikaci. Při výběru frameworku v kapitole třetí byl kladen důraz na obsažnost dokumentace, množství dostupných informací a návodů, výhled na vývoj v budoucnu
a velikost vývojového týmu či zázemí. Z tohoto kriteria vyšel nejlépe Zend Framework. Zejména velmi rozsáhlá dokumentace velmi ulehčila vývoj aplikace v tomto frameworku, je třeba ale říci, že byla možná až příliš obsáhlá na první kontakt
s podobnou softwarovou strukturou. Celý Zend Framework řeší, kromě běžné problematiky, i problematiku okrajovou, či lépe řečeno, méně používanou. Oproti programování v čistém PHP je programování v tomto frameworku zcela jiné. Je třeba se naučit mnoho dalších věcí a jen pochopení základních principů může trvat déle.
Z výše uvedeného plyne závěr, že byl pro takto jednoduchou aplikaci vybrán příliš rozsáhlý framework a že kriteria výběru měla mít větší váhu zejména na jednoduchost použití a s tím spojenou vyšší rychlost vývoje. Přesto je zde předpoklad, že díky vybranému frameworku má aplikace větší potenciál do budoucna. Přestože vlastní programování trvalo výrazně déle, než bylo původně očekáváno, při vývoji dalších aplikacích se toto zpomalení nebude opakovat a programátor využije plného potenciálu Zend Frameworku již od počátku.
Na otázku, zda využívat frameworky či ne, odpovídá však tato práce jasně. Jednoznačně ano. Po zaškolení a pochopení principů, které je závislé na složitosti frameworku, je vývoj nejen výrazně rychlejší, ale i spolehlivější.
Neméně důležitým kriteriem hodnocení je ekonomický přínos vyvinuté aplikace. Na trhu volně dostupných řešení je tato aplikace velmi ojedinělá. Stejně jako mnoho dalších má velmi jednoduché ovládání a neobsahuje velké množství funkcí, je tedy pro uživatele velmi jednoduchá. Oproti všem dalším podobným, jednoduchým, aplikacím je však založena na modulární struktuře. Tato struktura umožňuje spojit více jednoduchých aplikací do jedné. Podobná vícefunkční modulární aplikace je svým návrhem velmi vhodná pro malé webové projekty, začínající podnikatele a malé firemní portály, které jsou charakteristické větším počtem modulů, které jsou však velmi jednoduché. Přidanou hodnotou oproti jiným samostatným aplikacím je pak propojenost jednotlivých modulů. Právě pro zmíněné cílové skupiny je vyvinutá aplikace vhodným řešením webové prezentace.
Používání frameworků splňuje tedy všechny původní předpoklady, ulehčují programování a snižují dobu nutnou k vývoji aplikace. Cenou za tento komfort je jistá ztráta nad kontrolou celé aplikace, protože programátor přenechává část odpovědnosti na programátorech frameworku. Při výběru kvalitního frameworku a sledování jeho aktualizací však převažují klady používání frameworku nad rizikem plynoucím z použití cizího zdrojového kódu.

[1] eAccelerator [online][cit.2009-03-02] Dostupné z: < http://eaccelerator.net >.
[2] ALLEN, Rob, LO, Nick, BROWN, Steven: Zend Framework in Action. Greenwich: Manning Publications, 2008. ISBN 978-1933988320.
[3] VRÁNA, Jakub. Kontrola emailové adresy [online][cit.2009-02-09]
Dostupné z: .
[4] PECINOVSKÝ, Rudolf. Návrhové vzory. Praha: Computer Press. ISBN 978-80-251-1582-4.
[5] Model View Controller [online][cit.2009-01-07]
Dostupné z: .
[6] DANĚK, Petr: Velký test php frameworků. [online][cit.2008-11-20]
Dostupné z: .
[7] MAREK, Ondra: Jednoduchý internetový obchod v PHP 5 [online][cit.2009-03-01] Dostupné z: .
[8] Jelix forum [online][cit.2009-02-02]
Dostupné z: .
[9] Jelix [online][cit.2009-02-02] Dostupné z: .
[10] CodeIgniter [online][cit.2009-02-03] Dostupné z: .
[11] Akelos [online][cit.2009-02-03] Dostupné z: .
[12] Kohana [online][cit.2009-02-03] Dostupné z: .
[13] Prado [online][cit.2009-02-04] Dostupné z: .
[14] Zend Framework [online][cit.2009-02-04]
Dostupné z: .
[15] Nette [online][cit.2009-02-04] Dostupné z: .
[16] Slovník Symbio [online][cit.2009-02-04]
Dostupné z: .
[17] Symfony [online][cit.2009-02-04]
Dostupné z: .
[18] Zend Framework wiki [online][cit.2009-03-05] Dostupné z: .
[19] Front Controller [online][cit.2008-12-05] Dostupné z: .
[20] MROZEK, Jakub. Zend Framework přehled knihoven [online][cit.2008-11-04] Dostupné z: .
[21] FOWLER, Martin. Table Data Gateway [online][cit.2008-12-15]
Dostupné z: .
[22] FOWLER, Martin. [online][cit.2008-12-15]
Dostupné z: .
[23] FOWLER, Martin. [online][cit.2008-12-15]
Dostupné z: .
[24] Languages and territories [online][cit.2009-03-01] Dostupné z: .
[25] Zend Framework Manual [online][cit.2008-12-15]
Dostupné z: .
[26] SQL Injection [online][cit.2009-01-14]
Dostupné z: .
[28] Diagramy a grafy [online][cit.2009-01-05]
Dostupné z: .
[29] FOWLER, Martin. [online][cit.2008-12-15]
Dostupné z: .
[30] RFC 821 [online][cit.2009-02-09] Dostupné z: .
[31] RFC 5322 [online][cit.2009-02-09]
Dostupné z: .
[32] RFC 5321 [online][cit.2009-02-09]
Dostupné z: .
[33] RFC 2822 [online][cit.2009-02-09]
Dostupné z: .

Vývoj webových aplikací pomocí PHP frameworků VIII

admin — Sat, 27 Jun 2009 21:22:51 +0000

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.

Vývoj webových aplikací pomocí PHP frameworků VII

admin — Thu, 25 Jun 2009 21:53:48 +0000

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.

Vývoj webových aplikací pomocí PHP frameworků VI

admin — Wed, 24 Jun 2009 21:20:16 +0000

Dnes úvod do toho, co jsem psal jako bakalářku. K pochopení Zend Frameworku to asi nepomůže, ale bude se to hodit v dalších textech – budete vědět co jsem vlastně dělal.

Modularita

Požadavek modularity vyplývá z nutnosti budoucích změn a úprav. Jako demonstrativní aplikace je v této práci vytvořen elektronický obchod. Elektronických obchodů poskytovaných v různých volných licencích je mnoho, takže není problém mít obchod během několika málo hodin. Při následném požadavku na firemní blog či fotogalerii nastává však většinou problém. Opět můžeme použít volně dostupné řešení, ale každá z aplikací je vytvořena zvlášť a propojit je, je někdy problém s obtížností větší, než vytvoření aplikace, která bude zvládat zmíněné požadavky navíc. Stejně tak lze pokračovat s dalšími aplikacemi jako je například diskusní fórum. Modulární aplikace je tedy schopna pracovat s více samostatnými částmi. Tyto části mohou být pak použity společně při tvorbě rozsáhlého webu, či jako samostatné řešení.
Cílem je tedy vytvořit elektronický obchod, který bude však jen jedním modulem celé hypotetické aplikace. Požadavkem na další budoucí moduly je pouze zachování struktury a samozřejmě využívání společných zdrojových kódů.
V budoucnosti není tedy problém přidat libovolný z teoreticky existujících modulů, případně si svůj vytvořit. O kompletní propojení se pak postará již vlastní aplikace. Zde je třeba říci, že se v této práci se nejedná pouze o modul elektronický obchod, ale právě i o společnou aplikační část pro všechny budoucí moduly – konkrétně se jedná zejména
o modul pro správu uživatelů a základní rozvržení administrace. Administrací je myšleno zejména ošetření vstupu pouze autorizovaným uživatelům.
Při tvorbě libovolného modulu je třeba mít na paměti, aby ke společným datům měli přístup všechny (i teoretické, budoucí) moduly. Proto je nutné například v modulu obchod ukládat fotografie výrobků v takové podobě, aby bylo možno je využít bez návaznosti na jiná data. Příkladem může být použití těchto fotografií v modulu Fotogalerie.
Dalším požadavkem je dynamické nahrávání modulů. Složitá instalace
a odinstalace je často důvodem krachu celé aplikace pro koncového uživatele, proto musí být instalace obstarána pouhým nahráním modulu do struktury aplikace. Stejně tak musí být zaručeno automatické propojení administrace a generování administračních menu. Jde o podobný mechanismus, jakým disponuje publikační systém WordPress při správě pluginů.
O společná data (všeobecně používaná data v databázi, konfigurace apod.) se musí starat již zmíněná vlastní aplikace. Z důvodu přehlednosti musí být všechna společná data soustředěna na jednom místě.

Administrační rozhraní

Největší nároky na administrační rozhraní plynou z modulárního konceptu aplikace. Je třeba moduly nejen dynamicky nahrát do aplikace, ale je třeba přímo generovat administrační možnosti dle dostupných modulů. V řešeném modulu elektronického obchodu je základem administrace správa zboží a objednávek, v modulu obstarávajícím uživatele, jde o jednoduchou správu uživatelských nastavení.

Uživatelské rozhraní

V řešeném modulu elektronický obchod nejsou kladeny zvláštní nároky na rozhraní. Registraci a správu uživatelů obstarává modul User a jedná se tak tedy pouze o správu košíku. Je nutné, aby bylo umožněno přidávat zboží do košíku uživatelům jak přihlášeným, tak nepřihlášeným. Je třeba také ošetřit možnost, že uživatel naplní košík jako nepřihlášený a následně se přihlásí, stejně tak naopak. Pro všechny varianty přihlášení a odhlášení je nutno mít košík aktuální a co nejvíce komfortní pro uživatele. Samozřejmostí je výpis zboží a kategorií zboží.

Vývoj webových aplikací pomocí PHP frameworků V

admin — Sat, 20 Jun 2009 21:17:37 +0000

Po minulém popisu komponent dnes končí teoretická část. Helpery.

Helpery

Helper je pomocná funkce, ulehčující programátorům práci. Často používaný kód či specifická funkčnost lze uložit do helperu a ten následně používat. Helpery v Zend Frameworku dělíme na action helpery a view helpery. První jsou používány v controllerech, druhé ve view.
Zend Framework obsahuje některé předdefinované helpery.
Action helpery

ActionStack helper umožňuje vkládat požadavky na další zpracování action pomocí front controller pluginu Actionstack. [25]
Autocomplete usnadňuje práci s automatickým doplňováním formulářů ContextSwitch a jeho specializovaná verze

AjaxContext nastavuje odpověď vhodnou pro použití jiného formátu. [25]
FlashMessenger uchovává text napříč aplikací. Umožňuje tak uchovávat výstup, který chceme použít při dalším načtení stránky. Nevýhodou FlashMessengeru je, že není schopen pojmenovávat prostor, proto je nutno k ukládanému textu přidávat další informace o něm (např. info|toto je info text). Nejlépe například nějakým znakem oddělit a následně pracovat s částmi řetězce. [25]
View Renderer helper zajišťuje, že se po skončení action vykreslí příslušný view, bez dalšího nastavování. Toto chování lze samozřejmě změnit. Programátor tedy vytvoří v controlleru metodu action a k ní dle přijatých jmenných konvencí soubor view. O vlastní správné propojení se pak už postará framework. [25]

View helpery

Action View Helper je schopen načíst konkrétní action z controlleru a vložit výsledek do view. [25]
Partial Helper slouží k znovupoužití často opakovaných prvků ve view. Tento prvek je uložen ve vlastním souboru a do view vkládán pomocí tohoto helperu. Poskytován je také PartialLoop, který je načítán opakovaně. [25]
Placeholder Helper je vhodný pro skládání obsahu stránek. Ukládá pojmenovaná data, ke kterým pak lze přistupovat v libobolném view. [25]
Skupina helperů Doctype, HeadLink, HeadMeta, HeadScript, HeadStyle, HeadTitle a InlineScript jsou pak konkrétními implementacemi Placeholder helperu. [25]
HTML Object vkládá do view html prvky v tagu . Vhodné například pro vkládání flash animací. [25]
JSON Helper nastavuje správnou hlavičku odpovědi a vypíná použití layoutu. [25]
Translate Helper pomáhá při práci s vícejazyčnou aplikací. Využívá knihovnu Zend_Translate. [25]

Jmenné konvence

Všechny soubory frameworku jsou uloženy ve dvou adresářích. Hlavní
a původní adresář je „Zend“ a druhý, sloužící pro ukládání dalších dílších knihoven (Extras), je „ZendX“. Protože PHP zatím nepodporuje jmenné prostory, je použito jednoduchého pravidla, kdy jsou jednotlivé třídy v adresářové struktuře a zanořené třídy se jmenují dle vyšších adresářů. Např. Zend_Db_Table_Row třída je uložena na adrese Zend/Db/Table/Row.php. [25]

Podmínky pro fungování

Pro optimální chod je doporučovaná minimální verze PHP 5.2.3 a novější.
S jistým rizikem je možno používat tento framework od PHP verze 5.1.4. Pro spouštění veškerých testů je nutný PHPUnit 3.0.
Při používání pouze některých component je nutné reflektovat možnou závislost na jiných komponentách. [25]

Vývoj webových aplikací pomocí PHP frameworků IV

admin — Thu, 18 Jun 2009 21:07:17 +0000

Dnes základní text bakalářky z teoretického hlediska – popis Zend Frameworku. Lehký nástin jednotlivých komponent.

Základní koncept Zend Frameworku

Zend Framework je jednoduchý PHP framework určený k tomu, aby pomohl odstranit nudné programování a naopak pomohl zaměřit se na řešení konkrétních problémů. Jeho síla je ve vysoce modulárním MVC designu, díky kterému je naprogramovaný kód opakovaně použitelný a rychle vyvíjený. Využívá komponentový a kompletně objektový přístup. Tento framework obsahuje předpřipravené řešení pro obrovské množství problémů, na které může programátor narazit. Díky komponentovému přístupu je však možno tuto funkcionalitu extrahovat a používat zvlášť. Díky relativně malé provázanosti jednotlivých komponent je také rychlejší pochopení a učení práce s frameworkem. Za celým projektem stojí firma Zend Technologies Ltd, která stojí i za samotným PHP. [18]

Filozofie existence

• Poskytnout zdroj vysoce kvalitních komponent, napsaných kompletně v PHP verze 5
a vyhovující E_STRICT. Každá chyba je tedy výsledkem kódu aplikace a ne frameworku.

• Poskytnout kompletní systém pro vývoj webových aplikací. Není tedy nutné používat jiné knihovny, přestože je to umožněno.

• Jednoduše, jak jen to je možné. Neměnit PHP, které je postaveno na jednoduchém
a elegantním řešení. V této zásadě pokračovat.

• Podporováno firmou Zend, je tudíž menší šance že framework se přestane vyvíjet. Firma také dodá kapacity na tvorbu dokumentace, která je často problémem.

Popis komponent

V následujícím textu jsou uvedeny komponenty, které byly použity při vývoji aplikace. Důraz je kladen na tři hlavní komponenty MVC, tedy Zend_Db, Zend_View
a Zend_Controller.

Zend_Acl
Komponenta pro práci a autorizací. Umožňuje nastavit uživatelská práva a dále spravovat přístup uživatelů k zadaným sekcím. Uživatelská práva lze dědit a vytvořit tak hierarchickou strukturu uživatelů.
Název Acl je odvozen od spojení Access Control List (seznam kontrolovaných přístupů). Pro práci s touto knihovnou je třeba rozlišovat dva pojmy, role a zdroj. Zdroj je chráněný objekt, jehož přístup je kontrolován. Role je poté objekt, který žádá
o přístup ke zdroji. Zend_Acl pak spravuje právě tyto dva objekty, neboli způsob přidělování rolí ke zdrojům. [25][20]

Zend_Auth
Při práci s uživateli je třeba je jednoznačně identifikovat. O tuto problematiku se stará právě tato komponenta, využívající Zend_Session ve výchozím nastavení.
Zend_Auth se zabývá pouze autentizací, nikoli autorizací. Autentizace je identifikační kontrola subjektu. Autorizace je proces rozhodování o tom, zda umožnit přístup k subjektu, čímž se zabývá knihovna Zend_Acl.[25][20]

Zend_Cache
Ukládání výsledků jednotlivých operací je nutnou podmínkou pro rychlý chod aplikací. Ukládat lze výstup funkcí, tříd, či souborů. Lze definovat i místo uložení. Označení jednotlivých výsledků umožňuje pokročilou správu dat. [25][20]

Zend_Config
Konfigurační nastavení je možno ukládat v konstantách a dále s nimi takto v aplikaci pracovat. Tato komponenta umožňuje nyní toto nastavení uložit v externím souboru ve formátu XML či INI a jednotlivé prvky uspořádat hierarchicky. [25][20]

Zend_Controller
Zend Framework využívá návrhového vzoru Front controller [19]. Myšleno tím je to, že všechny požadavky obsluhuje jediný soubor, který se stará o další zpracování.
Zend_Controller odesílá požadavek na konkrétní action příslušného controlleru. Pro usnadění programování lze zaregistrovat pluginy, a to ve všech krocích zpracování. Plugin je funkce, která je spouštěna dle zadaných kritérií, upravující výchozí chování. Odeslání požadavku na konkrétní action se odehrává ve dvou fázích. V první router na základě adresy urči, který modul, controller a action se má s jakými parametry spustit
a tuto informaci předá dispatcheru. Ve druhé přichází na řadu zmíněný dispatcher, který již požadavek odesílá na vybraný controller a action, tak jak je zobrazeno na obrázku Obr. 2. Proces výběru je velmi důležitý, protože transformuje URL, úpravou tohoto procesu lze měnit výchozí chování. To počítá s adresou ve tvaru server.com/{modul}/{controller}/{action}/{další parametry} (modul je volitelný), změnou chování routeru můžeme definovat, dnes používané a oblíbené, SEO adresy.
Obrázek č. 2 – Zpracování požadavku prohlížeče

Zdroj: ALLEN, Rob, LO, Nick, BROWN, Steven: Zend Framework in Action. Greenwich: Manning Publications, 2008. ISBN 978-1933988320.

Zmíněné pluginy lze zaregistrovat v šesti fázích procesu zpracování (každý plugin bude volán dle použité funkce).

Pojmenování jednotlivých funkcí v pluginech může být následující:

• routeStartup() je volána před začátkem procesu směrování (routing).

• dispatchLoopStartup() je volána předtím, než začne probíhat proces odesílání (dispatch).

• preDispatch() je volán před každou action.

• postDispatch() je volána po skončení action.

• dispatchLoopShutdown() je volána po skončení všech action.

• routeShutdown() je volán po skončení procesu směrování.

Nyní je tedy zřejmé, že pomocí pluginů lze libovolně měnit chování aplikace
e všech krocích zpracovávání úživatelského požadavku. O samotné spouštění se stará framework, stačí tedy plugin zaregistrovat a následně pojmenovat. Pojmenování následně určí okamžik, kdy bude plugin spuštěn. Proces zpracovávání je zobrazen na obrázku Obr. 3.

Obrázek č. 3 – Zpracování požadavku prohlížeče dle probíhajících procesů

Zdroj: ALLEN, Rob, LO, Nick, BROWN, Steven: Zend Framework in Action. Greenwich: Manning Publications, 2008. ISBN 978-1933988320.

K přidávání funkcionality lze naprogramovat vlastní helpery, které lze volat kdekoliv v controlleru. Framework obsahuje některé předdefinované helpery. [25][20]

Zend_Date
Tato komponenta nabízí detailní a jednoduché API pro práci s časem. [25][20]

Zend_Db
Jednou z nejrozsáhlejších komponent v Zend Frameworku je právě Zend_Db. Umožňuje pracovat se všemi databázemi prostřednictvím jednoho rozhraní. Zend_Db obsahuje množství adaptérů na různé databáze. Knihovna Zend_Db obsahuje také parser, který přizpůsobí SQL dotaz pro konkrétní databázi, navíc obsahuje profiler, takže můžete snadno zjišťovat, kolik času zabralo spojení s databází či konkrétní dotazy. [20] Aplikací návrhových vzorů Table Data Gateway [21] a Row Data Gateway [22] vznikají třídy Zend_Db_Table a Zend_Db_Table_Row. Práci rovněž ulehčuje třída Zend_Db_Select, která vytváří objektové rozhraní pro databázové dotazy.
Vhodné je také přidat další logiku do vlastních funkcí, které mohou vracet již naformátované výsledky. Využijeme toho například v modulu Shop, kdy je třeba kompetní informace o konkrétním produktu poskládat z několika tabulek. Vytvořením vlastní funkce getProduct, umístíme tuto funkčnost přímo ke zdroji dat.
Zend_Db podporuje množství adaptérů, které můžeme vybrat pro komunikaci
s databází. Každý adaptér je založen na nějakém PHP rozšíření a výběr je tedy závislý na parametrech hostingu. [25][20]

Podporované databáze

• IBM DB2 a IDS (pdo_ibm PHP rozšíření)
• MySQL (pdo_mysql PHP rozšíření)
• MS SQL (pdo_mssql PHP rozšíření)
• Oracle (pdo_oci PHP rpzšíření)
• Postrge SQL (pdo_pgsql PHP rozšíření)
• SQLite (pdo_sqlite PHP rozšíření)
• MySQL (mysqli PHP rozšíření)
• Oracle (oci8 PHP rozšíření)
• IBM DB2 (ibm_db2 PHP rozšíření)
• Firebird/Interbase (php_interbase PHP rozšíření)
• Firebird/Interbase, using the php_interbase PHP extension

Zend_Form
Cílem této komponenty je zjednodušení práce s formuláři. V aplikaci lze nadefinovat jednotlivé prvky, jejich validátory, filtry a způsob zobrazení. Ve view pak již stačí formulář pouze zobrazit. Použití zmíněných validátorů při tvorbě formuláře následně velmi usnadní prácí s validací po odeslání. Použitím jediné funkce isValid() lze zkontrolovat celý formulář.[25][20]

Zend_Layout
Umožňuje skládání stránek ve vybraném layoutu (šabloně). Je aplikací dvoukrokového zpracování HTML [23]. Hlavní cíle této komponenty jsou následující:
• automatizovat výběr a zobrazování layoutu, pokud je použit návrhový vzor MVC
• poskytovat samostatný prostor pro proměnné související s daným obsahem
• umožnit kompletní konfiguraci layoutů
• umožnit vypnutí, či změnu layoutu odkudkoliv (controller či view)
• dodržovat stejná pravidla chování jako ViewRenderer, ale umožnit je změnit
• umožnit použití jako samostatné komponenty

Přestože je možno tuto komponentu používat jako součástí MVC frameworku či samostatně, chování a používání je velmi podobné. U obou variant je nutno vytvořit soubor obsahující základní layout a v něm zobrazovat proměnné. Způsob naplnění je pak zcela na volbě programátora. [25][20]

Zend_Loader
Základní komponenta pro nahrávání potřebných souborů a tříd. Využívá jmenných konvencí frameworku a překládá názvy tříd do skutečných adresářových adres. Je možno využít PHP funkce pro automatické nahrávání tříd. [25][20]

Zend_Locale
Tato komponenta zajišťuje zobrazování obsahu ve správném jazyce. Nejde však jen o pouhý překlad, ale přímo o lokalizaci, protože např. Stejné číslo může být v jiných zemích jinak zobrazováno (desetinná čárka, tečka). Tato komponenta spolupracuje
s mnoha dalšími a zajišťuje nezbytnou podporu pro lokalizační komponenty celého frameworku, jako jsou:
• Zend_Translate, překlad textu
• Zend_Date, lokalizace data a času
• Zend_Calendar, lokalice kalendářních dat
• Zend_Currency, lokalizace měn
• Zend_Locale_Format, zpracování a generování lokalizovaných čísel
• Zend_Locale_Data, práce s daty z CLDR (http://cldr.unicode.org/)

Pracuje s mezinárodně uznávaným standardem pro rozeznávání regionů
a jazyků, jehož seznam je na [24], seznam aktuálně podporovaných identifikací je uveden v manuálu frameworku. [25][20]

Zend_Registry
Tato třída slouží k uchovávání globálních dat napříč celou aplikací. [25][20]

Zend_Session
Obsahuje mechanizmy pro práci se sessions. Komponentu používá například Zend_Auth jako svůj výchozí adaptér. [25][20]

Zend_Translate
Komponenta potřebná pro vícejazyčné aplikace. Aktuálně podporuje devět adaptérů pro vstup dat jako je Gettext, Csv či běžné PHP pole. Komponenta poskytuje vlastní třídu umožňující snadno vytvořit libovolný jiný adaptér.[25][20]

Zend_Validate
Komponenta pro validaci dat. Aktuálně obsahuje následující třídy pro kontrolu dat:
• Alnum – pouze abeceda a čísla (mezera volitelně)
• Alpha – pouze abeceda
• Barcode – čárový kód (aktuálně EAN-13 a UPC-A)
• Between – porovnává velikost čísla vzhledem k daným mezím. Je možno nastavit i jen jednu.
• Ccnum – kontrola platnosti kreditních karet
• Date – ve výchozím nastavení porovnává s tvarem YYYY-MM-DD
• Digits – kontrola pouze čísel
• EmailAddress – kontrola platnosti emailové adresy. Je možno zapnout i kontrolu, jestli emailová adresa přijímá emaily, či kontrolu IDN domén.
• Float – kontrola čísla s desetinnou čárkou
• GreaterThan – porovnává s předem nastavenou hodnotou (větší než)
• Hex – kontrola hexadecimálního čísla
• Hostname – ve výchozím nastavení kontrola DNS adresy, je možno zapnout i kontrolu IP adresu
• InArray – kontroluje zda se zadaný řetězec vyskytuje jako součást jiného
• Int – kontrola celého čísla
• Ip – kontrola platnosti IP adresy
• LessThan – porovnává s předem zadanou hodnotou (menší než)
• NotEmpty – kontrola, jestli hodnota obsahuje nějaká data
• Regex – porovnávání s regulárním výrazem
• StringLength – kontrola délky řetězce, pracuje i s kodováním UTF-8

S touto komponentou se nejčastěji setkáme společně s Zend_Form, kdy je možno validátory přidat přímo k formuláři při jeho tvorbě. Kontrola následně probíhá pomocí funkce isValid(). [25][20]
Zend_View
Základní komponenta pro správu view (pohledů). Kooperativně Zend_View může pracovat s komponentou Zend_Layout, která umožňuje spojování jednotlivých view v layoutech (šablonách). Framework lze samozřejmě používat se sofistikovanými produkty jako je například Smarty, zde budeme však používat řešení nabízené přímo tímto frameworkem. U větších projektů se aplikace neobejde bez oddělení aplikační a prezentační logiky, vcelku však nezáleží jakou z variant programátor zvolí. Zend Framework nabízí tuto možnost a pro svou jednoduchost je v této aplikaci použita. Jednotlivé view jsou vytvořeny pomocí PHP, takže oproti Smarty není třeba znát další speciální tagy. Jednotlivé proměnné se do view přiřazují v příslušném controlleru.
K přidávání funcionality lze naprogramovat vlastní helpery, které můžeme volat kdekoliv ve view. Framework obsahuje některé předdefinované helpery. [25][20]

Všechny komponenty frameworku lze rozdělit do šesti kategorií:
MVC
• Zend_Controller, Zend_Db, Zend_Layout, Zend_View

Autorizace, autentizace
• Zend_Acl, Zend_Auth, Zend_Session

Webové služby
• Zend_Feed, Zend_GData, Zend_OpenId, Zend_InfoCard
• Zend_Service_* (skupina tříd pro podporu externích služeb)

Internacionalizace (I18N) a lokalizace (L10N)
•Zend_Currency, Zend_Date, Zend_Locale, Zend_View, Zend_Translate

Meziaplikační komunikace
• Zend_Http_Client, Zend_Json, Zend_Ldap, Zend_Rest, Zend_TimeSync, Zend_XmlRpc

Jádro
• Zend_Cache, Zend_Config, Zend_Filter, Zend_Form, Zend_Log, Zend_Mail, Zend_Memory, Zend_Pdf, Zend_Registry, Zend_Search, Zend_Uri, Zend_Validate

Každá komponenta obsahuje množství tříd, včetně hlavní třídy, podle které je pojmenována a uvedena v seznamu. Například Zend_Config obsahuje Zend_Config_Ini a Zend_Config_Xml třídy.

Vývoj webových aplikací pomocí PHP frameworků III

admin — Tue, 16 Jun 2009 21:01:34 +0000

Třetí pokračování. Tentokrát to vyšlo na popis frameworků, dávám sem ale jenom Zend.

Zend Framework

Je to relativně nový framework založený opět na MVC architektuře. Oproti předcházejícím frameworkům se jedná o velmi rozsáhlý projekt. Obsahuje obrovské množství knihoven, řešících velkou část programátorských postupů. Tento fakt je kladem i záporem celého frameworku. Neoddiskutovatelným faktem zůstává, že se jedná o nejrychleji vyvíjený framework.
Je dostupné velké množství návodů a popisů problémů, většinou však v angličtině. České diskusní fórum je živé a dle počtu školení je možné usuzovat, že popularita tohoto frameworku roste rychlým tempem. [6][14]
Licence: nová BSD (http://www.opensource.org/licenses/bsd-license.php)

Výběr frameworku

Pro ukázku práce s frameworkem lze zvolit téměř libovolný framework ze zde popsaných, či zcela jiný, zde nezmíněný. Smyslem této kapitoly není vybrat nejlepší a jediný přijatelný framework, každý má své klady a zápory. Jedním z hlavních kritérií je však obsáhlost dokumentace a celková velikost komunity, která produkuje návody
a v diskuzích poskytuje cenné rady. Toto kriterium usnadní první kontakty programátora s frameworkem. Zejména proto byl pro tuto práci vybrán Zend Framework, který se nejenže vyvíjí obrovskou rychlostí, ale hlavně dokumentace
a množství návodů usnadní počáteční práci. Do užšího výběru pro větší a obsáhlejší projekty byl vybrán Zend, Nette a Sympfony. Kriteriem, které rozhodlo, se nakonec stala velikost vývojářského týmu, v případě Nette je to jeden člověk a v případě Sympfony dva lidé. Výhledově se tak jedná o rizikový parametr, bez ohledu na další vlastnosti těchto frameworků. Jedná se čistě o předpoklad budoucího vývoje.

Při použití slova framework se v následujícím textu vždy jedná o vybraný Zend Framework. U textů zmiňující jiný framework, je toto zmíněno.

Vývoj webových aplikací pomocí PHP frameworků II

admin — Tue, 09 Jun 2009 21:01:28 +0000

Minule jsem přidal kus bakalářky, teď je tu pokračování. Postupně to sem budu nahrávat a publikovat tedy jakýsi úvodník do Zend Frameworku.

Definice pojmu framework

Framework je softwarová struktura, která slouží jako podpora při programování a vývoji a organizaci jiných softwarových projektů. Může obsahovat podpůrné programy, knihovnu API, návrhové vzory nebo doporučené postupy při vývoji. PHP frameworky jsou většinou souborem knihoven, které se však snaží omezovat možnosti špatného programování a usnadňovat programování kvalitních aplikací. Důvodem existence libobolného PHP frameworku je vyřešení často opakovaných problémů, se kterými se vývojář potýká. Kompexnost frameworku se tak odvíjí od počtu a hloubky těchto problémů, které je daný framework schopen řešit. Nabídka frameworků pro PHP není nijak úzká, proto je možno vybrat vždy ten nejvhodnější pro danou aplikaci.

Cíle frameworků

• Jednotný styl práce
• Vést k lepšímu kódu
• Řešit běžné a časté problémy
• Rychlejší vývoj aplikací
• Ekonomický efekt

Jednotný styl práce umožní spolupráci více programátorů na jednom projektu, protože styl není dán osobou programátora či firemními postupy, ale vlastním frameworkem. Vedení k lepšímu kódu je myšlenkový postup, který opět vychází z filozofie frameworku. Framework často nabízí řešení a programátor ho může využít, bez toho, aby se pokoušel toto řešení nalézt. Snižuje se tím také pravděpodobnost chyb. Řešením běžných a častých problémů (např. autorizace, formuláře) je ušetřen čas potřebný pro vývoj vlastních funkcí aplikace. Výsledkem je rychlejší tvorba aplikace
a s tím spojený ekonomický efekt.

Model – View – Controller architektura

Jedná se o softwarovou architekturu, která rozděluje aplikaci jako celek do tří komponent. Každá je pak nezávisla na dvou zbývajících a jsou tak možné efektivní změny aplikace. Jde o tyto komponenty: Model, View a Controller. Model reprezentuje data aplikace, view uživatelské rozhraní a controller obsahuje aplikační logiku [5].
Komunikace mezi těmito komponentami pak funguje na základě jednoduchého cyklu, kdy controller obdrží požadavek uživatele, na jejichž základě upraví data v modelu. View pak pomocí modelu zobrazí výsledek. Po skončení aplikace opět čeká na další podnět. Celý systém je zobrazen na obrázku Obr. 1. a v dalším textu je vždy použita zkratka MVC.
Obrázek č. 1 – Model – View – Controller architektura

Zdroj: ALLEN, Rob, LO, Nick, BROWN, Steven: Zend Framework in Action. Greenwich: Manning Publications, 2008. ISBN 978-1933988320.

Vývoj webových aplikací pomocí PHP frameworků I

admin — Tue, 09 Jun 2009 20:54:49 +0000

Takže bakalářka :) Postupně to sem budu nahrávat a publikovat tedy jakýsi úvodník do Zend Frameworku. Občas ale nějaký text vynechám, nemá smysl sem dávat všechno.

Úvod…

V dnešním globalizovaném světě, je existence sítě internet známá snad každému. Na této ohromné síti prezentují firmy své produkty a jednotlivci své názory. Každý, kdo chce dnes něčeho dosáhnout, musí mít svou webovou prezentaci, stejně tak jak vznikla před několika lety nutnost vlastnit automobil. Množství webových prezentací neustále narůstá, stejně tak, jak narůstá počet lidí s připojením k internetu. Každý chce, aby jeho webová prezentace splnila své cíle a správně fungovala, zůstaneme-li u analogie s automobilem, každý chce, aby jezdil. Co je však na celém automobilu nejdůležitější? Karoserie, vzhled, je sice vidět na první pohled, ale kvalita vozidla se odvíjí od kvality motoru. Stejně tak i webové prezentace mají svou karoserii
i svůj motor. Vzhled webové aplikace je pro uživatele samozřejmě důležitý, ale kvalita se také odvíjí od použitého motoru. Následující text se pokusí přiblížit jednu
z možností jak a čím efektivně pohánět webové aplikace na dnešní internetové dálnici.

Cíl práce…

Cílem této práce je vytvoření jednoduché webové aplikace pro správu obsahu, konkrétně elektronický obchod. Aby byla aplikace co nejvíce použitelná a rozšiřitelná, je tento obsah třeba definovat co nejvíce obecně. Aplikace tedy musí umět spravovat libovolný obsah, který může být později definován, primárně však jde o již zmíněný elektronický obchod.

Zmíněná aplikace bude naprogramována pomocí jednoho z PHP frameworků
s postupným uvedením postupu a porovnání s běžnými programovacími prostředky, jako demonstrace teoretických postupů.

Základním předpokladem pro splnění cílů práce je dobrá znalost vybraného programovacího prostředku. Protože se bude jednat o první autorův kontakt
s frameworkem, je třeba nastudovat množství informací. V domácím prostředí bohužel neexistuje tématická kniha, jediným tištěným materiálem bude proto kniha
o návrhových vzorech [4], která je cenným zdrojem informací o efektivním návrhu aplikace, z které bude čerpáno napříč celou prací. Vlastním těžištěm první části, rešeršní, je seznámení s frameworkem a všeobecně s teoretickými základy nutnými pro programování. Zde bude základním zdrojem informací manuál k frameworku.

Druhá, praktická, část práce se bude zabývat již vlastním vývojem aplikace
a popisem nejčastěji řešené problematiky. Řešení této problematiky bude názorně porovnáno s běžnými programovacími prostředky. Podkladem pro praktickou část je jedna z mála publikací zabývajících se praktickým postupem programování pomocí frameworku, Zend Framework in Action [2].