Klíčová slova:

Poděkování

Chtěl bych poděkovat především vedoucímu projektu Janu Krausovi za odborné rady a vstřícný přístup během práce na tomto projektu.

Dále bych chtěl poděkovat své rodině a přítelkyni za duševní podporu po celou dobu mého studia.

Abstrakt

Tato bakalářská práce popisuje implementaci online katalogu produktů.

Obsahuje porovnání nejpoužívanějších technologií pro vývoj webových aplikací. Dále potom konkrétní řešení s použitím technologie ASP.NET MVC.

Součástí řešení je parser pro čtení souborů z programu MS Office Excel, které jsou použity pro jednoduché plnění databáze. Samotná aplikace potom obsahuje podporu uživatelských účtů, vyhledávání a možnost seskládání košíku s produkty, ze kterého se nakonec vytvoří poptávka. O poptávce jsou administrátoři informováni pomocí e-mailu a dále ji vyřizují mimo tento systém.

Klíčová slova:

ASP.NET MVC, katalog produktů, ClosedXML

Abstract

This bachelor thesis describes implementation of online products catalogue. It contains comparison of the most frequently used technologies for web applications. It also contains concrete implementation with use of ASP.NET MVC.

Important part of the solution is parser which reads information from files of MS Office Excel. These files are used to fill database with data. Rest of the application contains user accounts, search and shopping cart with products. With this cart user can create a demand. Once the demand is created email is sent to administrators and they process the demand outside the system.

Key words:

ASP.NET MVC, products catalogue, ClosedXML

Obsah

1  Úvod ... 12 

2  Serverové skriptovací jazyky ... 13 

2.1  Rozšířenost ... 13 

2.2  PHP ... 14 

2.2.1  Historie ... 14 

2.2.2  Výhody ... 14 

2.2.3  Roztříštěnost ... 14 

2.2.4  Bezpečnost ... 15 

2.2.5  Frameworky ... 17 

2.3  ASP.NET ... 19 

2.3.1  WebForms ... 19 

2.3.2  MVC ... 21 

2.4  Java ... 26 

2.5  Porovnání ... 27 

3  Návrh řešení ... 28 

3.1  Technologie ... 28 

3.2  Databáze ... 29 

4  Aplikace ... 35 

4.1  Parser konfiguračních souborů ... 35 

4.1.1  Zdrojová data ... 35 

4.1.2  Microsoft Office Interop ... 36 

4.1.3  ClosedXML ... 37 

4.1.4  Struktura dokumentu ... 37 

4.1.5  Log ... 41 

4.2  Veřejná část ... 42 

4.3  Sestavení url adres ... 49 

4.4  Rychlost ... 49 

4.4.1  Měření ... 49 

4.4.2  Zrychlení aplikace ... 51 

4.5  Rozšiřitelnost ... 53 

5  Závěr ... 54 

A.  Přílohy ... 59 

Seznam obrázků

obr. 1 – Použití serverových skriptovacích jazyků ... 13 

obr. 2 – Diagram MVC [22] ... 21 

obr. 3 – Návrh databáze produktů ... 29 

obr. 4 – Návrh databáze uživatelů ... 32 

obr. 5 – Parametry produktu ... 36 

obr. 6 – Panel překladů a odkazů na další instance aplikace ... 38 

obr. 7 – Panel produktu 1 ... 39 

obr. 8 – Panel produktu 2 ... 40 

obr. 9 – Hlavní stránka aplikace ... 43 

obr. 10 – Výběr atributů produktu ... 44 

obr. 11 – Poptávkový košík ... 45 

obr. 12 – Prostředí pro práci s konfiguračními soubory ... 48 

Seznam kódů

kód 2 – Ukázka neošetřeného kódu proti XSS [6] ... 16 

kód 3 – Struktura XML nákupního košíku/poptávky ... 33 

kód 4 – Ukázka výstupu logu ... 42 

Seznam příloh

Příloha A.1 – Mobilní zobrazení hlavní stránky ... 59 

Příloha A.2 – Vyhledání výrazu „smc“ ... 59 

Příloha A.3 – Zobrazení detailu produktu ... 60 

Příloha A.4 – 2. krok košíku – zadání kontaktních údajů ... 60 

Příloha A.5 – 3. krok košíku – shrnutí vytvářené poptávky ... 61 

Příloha A.6 – Zobrazení košíku po vytvoření poptávky ... 61 

Příloha A.7 – Registrační formulář ... 62 

Příloha A.8 – Administrace ... 62 

Příloha A.9 – Výsledky měření rychlosti aplikace ... 63 

Příloha A.10 – Obsah přiloženého CD ... 64 

Cizí slova a zkratky

AJAX

Asynchronous JavaScript and XML –

technologie pro asynchronní komunikaci mezi serverem a prohlížečem bez nutnosti obnovení stránky

API Application Programming Interface – rozhraní, pomocí kterého aplikace komunikuje

Cache Vrstva zrychlující přístup k pomalým médiím ukládáním často používaných dat z těchto médií

CGI Common Gateway Interface – požadavek

serveru může obsloužit externí aplikace

Cookies Data uložená u prohlížeče, která se vždy posílají serveru spolu s požadavkem

Dependency Injection Technika pro určení závislostí komponent na jiných

framework Knihovny nebo soubor knihoven přinášející určitou funkčnost a usnadňující tak práci programátorovi

front-end Část webové aplikace viditelná uživatelům Hosting Pronájem prostoru a výkonu nějakého serveru

za konkrétním účelem

HTML entita Značka používaná zástupně za speciální znaky v HTML

HTTP Session Relace mezi klientem a serverem, která u sebe může mít uložené malé množství dat

Lazy loading Strategie načítání dat až tehdy, když jsou potřeba

Linq Sada funkcí dostupná v .NET, která umožňuje dotazování nad kolekcemi podobně jako SQL ORM Objektově relační mapování – zajišťuje

mapování relační databáze na objekty

Parser Část kódu, která zpracovává údaje z nějakého formátu

POSIX Portable Operating System Interface – rozhraní umožňující přenositelnost aplikací mezi

operačními systémy

UI User Interface – rozhraní, kterým aplikace komunikuje s uživatelem

Unobtrusive Javascript Javascript, kde události nejsou definovány v HTML značkách, ale jsou přiřazeny až za běhu URL Uniform Resource Locator – přesná adresa

odkazující na konkrétní zdroj

WinForms Technologie používaná pro vývoj formulářových aplikací pod rodinou jazyků .NET

1 Úvod

Cílem práce je vytvoření online katalogu produktů. Je nutné nastudovat a vybrat technologie, ve kterých bude aplikace implementována. Ta by měla být především uživatelsky nenáročná. Měla by obsahovat jednoduchou možnost aktualizace dat, široké možnosti nastavení parametrů prezentovaných produktů a měla by být připravená na internacionalizaci a použití více jazyků.

Po dokončení by měla být aplikace prakticky použitelná a otevřená případnému dalšímu rozvoji. Důvodem k vytvoření této aplikace je jednak specifičnost parametrů produktů a spolu s tím neexistence podobné aplikace na trhu.

Z velké části se aplikace podobá e-shopům, ale přece jen má rysy, kvůli kterým nelze klasický systém pro e-shopy použít. Produkty totiž nemají určeny počty kusů, které jsou k dispozici, ale hlavně nemají nastavené ceny.

Košík, který si uživatel sestaví a z kterého nakonec vytvoří poptávku, není vůbec závazný. Po vytvoření poptávky se teprve otevírá komunikace, během té se případně upraví požadavky a až poté se vytvoří objednávka.

Další zvláštností jsou velké možnosti nastavení parametrů u produktů.

Produkt má totiž z pravidla několik parametrů, kde si uživatel může vybrat jednu z možností, čímž volí výsledné funkce produktu. Díky tomu si sestaví výsledný typ produktu přesně podle jeho potřeby.

Po dokončení by aplikace měla běžet i ve více instancích v různých jazycích na více serverech. Jednotlivé instance by pak měly přes možnost změny jazyka odkazovat jedna na druhou. Uživatel by potom ani nemusel poznat, že přešel na jinou doménu.

2 Serverové skriptovací jazyky

2.1 Rozšířenost

obr. 1 – Použití serverových skriptovacích jazyků

Na obr. 1 jsou v levé části zobrazeny 2 grafy nejpoužívanějších skriptovacích jazyků a to v obdobích leden 2014 a 2015. PHP je jednoznačně nejpoužívanějším serverovým jazykem v obou obdobích. ASP.NET si drží druhé místo a za zmínku stojí také podíl Javy, která je poslední ve třetici s podílem nad 1 procento.

V pravé části obr. 1 je zobrazeno použití programovacích jazyků i v porovnání s aplikacemi, na které je jazyk použit. Lze pozorovat, že se PHP i ASP.NET používají rovnoměrně pro malé i velké aplikace, i když je ASP.NET téměř o jednu měrnou jednotku používanější u větších aplikací.

Oproti tomu Java je používána především u větších aplikací. Pro grafy byla použita data ze sítě W3Techs [7][8].

2.2 PHP

2.2.1 Historie

Historie skriptovacího jazyka PHP sahá do roku 1994, kdy Rasmus Lerdorf chtěl vytvořit systém pro počítání přístupu k jeho webovým stránkám. Tento systém původně napsal v jazyce Perl, ale protože to příliš zatěžovalo server [1], přepsal ho do jazyka C. V červnu roku 1995 vydal Rasmus zdrojový kód veřejnosti [3].

Po celou dobu vývoje bylo jádro PHP několikrát přepsáno. Do vývoje se postupem času přidali také Andi Gutmans a Zeev Suraski a nakonec se stali hlavními vývojáři. Jejich jména neslo i nové jádro Zend (složenina z jejich křestních jmen) v PHP 4 v PHP 5 už pak bylo jádro Zend Engine 2.0. PHP 5 je také poslední velká vydaná verze PHP [2].

Podle obr. 1 je PHP v současnosti nejpoužívanějším serverovým skriptovacím jazykem, což je dáno tím, že to byl prakticky první jazyk, kterým se daly vytvářet dynamické webové stránky. Spolu s tím hrál velkou roli také aktivní vývoj a jednoduchost použití.

2.2.2 Výhody

Mezi výhody PHP patří zejména jednoduchost, s tím související strmá křivka učení. PHP samotné obsahuje rozsáhlý soubor funkcí a další se dají přidat z repozitáře PEAR [4]. Díky jeho rozšířenosti je hosting pro PHP webovým standardem, navíc patří k těm levnějším. Existuje velké množství projektů a kódů, které lze zdarma využít.

2.2.3 Roztříštěnost

PHP je ale i jazykem velmi roztříštěným. Obsahuje mnoho podivných chování [9], na které se musí programátor připravit. Spousta z nich vznikla nejspíše i z původního smýšlení, jak bylo napsáno v dokumentaci z PHP 2.0 [10]. A sice že většina skriptů v PHP bude jednoduchá a pravděpodobně i

psána lidmi, kteří nejsou programátoři. Ti pouze chtějí logický jazyk, který se zvládnou rychle naučit.

Bohužel tento náhled vedl naopak k tomu, že se jazyk chová v některých situacích nelogicky. Jako příklad lze uvést funkčnost operátoru „==“ který je vlastně v PHP v praxi téměř nepoužitelný [11].

2.2.4 Bezpečnost

Další vlastností PHP, dalo by se říci nevýhodou, je přítomnost bezpečnostních rizik, na která si musí dát programátor vždy pozor, a to při každém jednotlivém použití konkrétního kódu. Důvodem výskytu těchto rizik v PHP není špatný návrh, ale může za to z velké části doba, kdy bylo PHP vytvořeno. V několika prvních verzích se ocital internet ještě v době, kde lidé byli rádi, že spolu mohou komunikovat a prakticky nikdo neměl důvod někomu dalšímu škodit. Nebyl tedy důvod přikládat možným útokům velkou důležitost. Pro názornost je uvedeno několik případů nejjednodušších a nejčastějších útoků.

SQL injection 

SQL injection je útok na databázi, který je možné provést zadáním zdrojového kódu do pole, které vyplňuje uživatel. Pokud tento vstup není na serveru ošetřen, je kód zpracován a útočník tak může získat kontrolu nad databází, potažmo nad celou webovou aplikací.

<?php

uName = getRequestString("UserName");

uPass = getRequestString("UserPass");

sql = "SELECT * FROM Users WHERE Name ='" + uName + "' AND Pass ='" + uPass + "'"

?>

kód 1 – Ukázka neošetřeného kódu proti SQL injection [5]

Zde předvedený ukázkový kód nemusí být ničím výjimečným. Jelikož PHP umožňuje používat proměnné přímo v textu, je to lákavý způsob jak napsat dotaz na databázi. Parametrům přijatým z formuláře od uživatele se ale nikdy nedá věřit.

Některé implementace konkrétních databázových systémů v PHP přináší funkce na escapování proměnných, které se dají použít na vstupní proměnnou. V tu chvíli se škodlivý kód neprovede. Některé implementace také mají možnost použít celou obsluhu dotazu přes objekt s funkcionalitou přidávání parametrů. V takovémto případě jsou parametry escapovány automaticky.

XSS 

XSS neboli Cross-site scripting je útok zaměřený většinou na ostatní uživatele, případně administrátory webové aplikace.

Typickým příkladem je diskuze, kde uživatel kromě textu své zprávy vloží také HTML kód. Například takový, který načítá skript z jeho vlastního serveru (odtud pochází i název tohoto útoku). Pokud toto není na serveru ošetřené, bude se tento skript spouštět každému uživateli, který na stránku přistoupí, a to včetně administrátora.

Pokud je navíc použit systém přihlašování pomocí Cookies, lze tyto Cookies zjistit, díky tomu se přihlásit jako administrátor aplikace a získat tak nad ní kontrolu.

<?php

echo $_GET['id'];

kód 2 – Ukázka neošetřeného kódu proti XSS [6]

V uvedeném kódu se na stránku vypíše jakýkoliv kód v podobě, v jaké přišel v parametru id metody GET. Stejně jako v předchozím případě se jedná o neošetřený vstup od uživatele. Jako ochranu před tímto útokem lze použít PHP funkci „htmlspecialchars“, která převede všechny speciální znaky na

HTML entity a na webové stránce se potom zobrazí jen čistý text, který uživatel například zadal do diskuze.

Další možností je použít funkci „strip_tags“, která odstraní speciální znaky a zanechá pouze čistý text. Tuto funkci lze použít již při ukládání do databáze. Problém obou možností řešení je ale nutnost na ně nezapomenout a důsledně používat u každého vstupu či výstupu.

CSRF 

CSRF neboli Cross-site request forgery je typ útoku, díky kterému může útočník upravit data určité webové aplikace, ke kterým má přístup pouze administrátor. To lze provést, pokud má konkrétní webová aplikace administrační rozhraní dostupné pouze pro přihlášené uživatele s oprávněním administrátora. Zároveň je nutné odhadnout některé akce, které lze v tomto rozhraní vykonat.

Útočník připraví webovou stránku, na kterou naláká administrátora webové aplikace. Webová stránka potom (často na pozadí) provede nějakou akci v napadené webové aplikaci s využitím kontextu přihlášeného administrátora, který o tom většinou ani neví.

Problém s ošetřením tohoto typu útoku je ten, že samotné PHP neumožňuje jednoduchým způsobem se na něj připravit. Je nutné použít nějakou vlastní nebo externí funkci, která problém řeší.

2.2.5 Frameworky

V poslední době je trend nepsat webové aplikace v čistém PHP, ale použít některý z mnoha dostupných frameworků. Frameworky jsou knihovny, které mají ulehčit práci při programování aplikace. To znamená méně psaní, přehlednější kód a rychlejší vývoj. [12]

Nejčastějšími zástupci jsou Zend, Nette a Symfony. Existuje samozřejmě nespočet dalších frameworků. Pro konkrétní případy může být vhodný jiný framework, protože je na daný případ zrovna lépe připravený, ale v důsledku

přináší každý framework víceméně to samé a je téměř jedno, který bude zvolen.

Framework přináší rychlejší vývoj. Obsahuje rozšiřující funkce PHP, které by programátor musel psát sám. Také má často vlastní metody pro vytváření formulářových prvků, které mohou navíc obsahovat třeba validaci.

Framework přináší i přehlednější kód. Framework má typická místa, kam psát určité části kódu. Celková struktura projektu je potom přehlednější a nutí programátora dodržovat určitou stylizaci.

Jednou z největších výhod frameworků bývá ladící prostředí. PHP samotné nemá žádné plnohodnotné prostředí pro ladění chyb v kódu. Při spoustě chyb se kód interpretuje zvláštním způsobem a výsledkem je například prázdná stránka. Potom programátor sám musí hledat, kde zapomněl středník, omylem napsal jednoduché „rovná se“ místo dvojitého, apod.

Framework většinou přichází s komfortnějším ladícím prostředím, které na konkrétní řádek s chybou upozorní a často lze také sledovat proměnné, cookies apod. za běhu aplikace, což v jednoduchém PHP lze realizovat pouze vypisováním do stránky.

Frameworky jsou často již navrženy s ohledem na bezpečnost, takže například útoky uvedené v kapitole Bezpečnost řeší už ve výchozím stavu.

Pro přístup k databázi se zpravidla používá celá databázová vrstva, která předchází SQL injection. Frameworky také většinou obsahují metody pro ošetření CSRF útoku.

Framework s sebou také často nese šablonovací systém, který umožňuje vytvářet efektivně šablony webových stránek. Například hlavní layout a do něho poté vkládat šablony jednotlivých stránek. Šablony bývají také rovnou ošetřeny proti útoku XSS.

2.3 ASP.NET

Ještě před ASP.NET zde bylo pouhé ASP (Active Server Pages). ASP jako takový nebyl moc oblíbený ani používaný [13]. Konceptuálně ASP vypadalo podobně jako PHP, ale jako skriptovací jazyk používalo VBScript nebo JScript. Microsoft přišel ale do světa HTML poměrně pozdě, a tak se mu ani nepodařilo získat dostatečnou uživatelskou základnu [13]. Měl spoustu vývojářů, kteří vytvářeli programy ve WinForms a chtěl toho využít. Přišel proto s ASP.NET a na něm postavenou platformou WebForms.

Ačkoliv název ASP.NET je odvozen od ASP, jsou obě technologie velmi odlišné. ASP.NET staví na CLR (Common Language Runtime), který je společný napříč všemi aplikacemi .NET Frameworku [14]. Aplikace v ASP.NET se tak dají psát ve všech jazycích .NET Frameworku, což jsou například Visual Basic .NET, C#, JScript.NET, ale i některé mutace Perlu či Pythonu.

ASP.NET je kompilovaná platforma, výsledný zdrojový kód je tedy zkompilován do binárních DLL souborů a jeho zpracování na straně serveru je tak rychlejší než čistě skriptovací jazyky.

2.3.1 WebForms

WebForms, jak už název napovídá, jsou odvozeny od WinForms, a to nejen tím názvem. WebForms byl způsob Microsoftu, jak nalákat vývojáře vyvíjející na platformě WinForms. Vlastní ovládání a princip vytváření aplikací je proto velmi podobný.

Stejně jako byli vývojáři zvyklí v grafickém rozhraní vytvořit vzhled desktopové aplikace ve WinForms, je to možné i tady. Rozdíl je prakticky jen v tom, že výsledný kód je v HTML. Jednotlivé ovládací prvky mají také obdobně své vlastnosti a události, při kterých se vykonává určitý kód.

Výsledný kód z WebForms je velmi podobný ostatním skriptovacím jazykům, jako je například PHP. Zároveň se WebForms snaží udělat

z bezestavového HTML stavový protokol. Používá k tomu ViewState případně SessionState.

ViewState v sobě zakódovaně uchovává aktuální stav aplikace pro daného uživatele a je renderován a odesílán s každým formulářem HTML.

SessionState na druhou stranu uchovává stav uživatele na serveru (buď přímo v paměti, nebo v databázi). Klient si drží jen identifikátor své session nejčastěji v podobě Cookie. Tato možnost vyžaduje vyšší hardwarové nároky serveru.

Vývoj 

První, poměrně jednoduchá verze WebForms, byla vydána v lednu roku 2002, společně s ASP.NET a .NET Frameworkem. Další verze přicházely také společně.

V druhé verzi (listopad 2005) přišel mimo jiné Microsoft s modelem Code- Behind, což znamenalo rozdělení zdrojového souboru WebForms na 2 části.

První se statickým HTML kódem a druhou dynamickou serverovou část, která se prováděla na serveru. V této verzi přišla taky spousta dalších novinek, jako například nové ovládací prvky, nové objekty pro práci se zdroji dat, schémata, prvky pro přihlašování a další [14].

V listopadu roku 2007 přináší další verze především nativní podporu AJAXu a podporu Linq. Linq je soubor sql-like příkazů, pomocí kterých lze pracovat s kolekcemi různého typu.

S další verzí .NET Frameworku a také ASP.NET byl představen Framework ASP.NET MVC. Podpora architektury WebForms nebyla ukončena a stále jsou do něho přidávány novinky, často shodné s novinkami v ASP.NET MVC, nicméně v současné době je větší pozornost upřena právě na tento nový framework.

2.3.2 MVC

MVC jako návrhový vzor 

MVC je chápán jako návrhový vzor, ale spíš než návrhový se dá nazvat architektonickým vzorem, protože mnohem více popisuje celkovou architekturu aplikace.

MVC stojí na 3 základních komponentách, jak je vidět na obr. 2. Model, což je vlastně business vrstva. Stará se o data a business logiku okolo nich.

View, to je samotné uživatelské rozhraní. Dostává data z modelu a zobrazuje je uživateli. Poslední částí je Controller, který podněcuje změny v Modelu, která si uživatel vyžádal v UI (například kliknutím na tlačítko). Controller může také upozornit View na změny v Modelu a uživatelské rozhraní přezobrazí nová data uživateli.

MVC framework 

Princip ASP.NET MVC je od WebForms zcela odlišný. Už jen uživatelské rozhraní, které nelze vizuálně editovat jako ve WebForms. HTML kód se zde píše standartním způsobem. V tomto kódu lze používat některé HTML helpery, které umožňují vytvářet elementy například pro konkrétní vlastnosti modelu, který se zobrazuje. Tyto HTML helpery ale většinou neobsahují žádné komplexní prvky. Jedná se především o formulářové prvky, které tak získají automatickou validaci.

HTML kód se píše do souborů uvnitř složky Views, což zcela správně evokuje analogii k View z návrhového vzoru MVC.

Projekt webové aplikace obsahuje ještě složku Controllers, která v sobě uchovává samotné Controllery. Controller jako takový je jediným místem pro výkonný serverový kód (mimo samotný model, který bývá v jiném projektu).

Ve Views se tak má dít opravdu jen prosté zobrazení dat získaných právě z Controllerů.

obr. 2 – Diagram MVC [22]

Vývoj 

První verze frameworku MVC byla vydána v roce 2009. Obsahovala základní rozdělení do Controllerů a View, koncept routování (tzn. Jednoduché vytváření URL adres), jednoduché helpery pro vytváření HTML elementů, AJAX helpery pro jednoduchou práci s AJAXovými odkazy a formuláři, automatické mapování dat z formuláře do objektů a základní validaci [14].

MVC framework tak jak byl navržen, byl opravdu velmi rozšiřitelný.

Ačkoliv v této verzi neobsahoval ještě některé pokročilejší funkcionality, jako například Dependency Injection, nebyl problém si je doprogramovat, protože většinu bázových objektů bylo možné rozšířit nebo nahradit objektem svým [15].

Druhá verze, vydaná o rok později (2010), přinesla některá další vylepšení, přestože původní jádro zůstalo téměř stejné. Mezi novinky se řadí rozšířená validace modelů na základě atributů jednotlivých vlastností. Tato validace fungovala serverově i na klientovi pomocí Javascriptu. Dalšími novinkami jsou například HTML helpery postavené na lambda výrazech, asynchronní práce s Controllery, HTML šablony pro jednotlivé modely nebo třeba „oblasti“ (Areas), které umožňují velké aplikace rozdělit například na veřejnou část a administraci [15].

Třetí verze přišla po necelém roce od verze druhé a také přinesla několik novinek. Mezi ně se řadí nový zobrazovací engine Razor, Unobtrusive Javascript a celkově lepší práce s Javascriptem a další [15].

V další verzi přináší MVC lepší podporu mobilních zařízení mimo jiné pomocí mobilní šablony webu. Přidává Web API, pro jednoduchou možnost vytváření vlastních webových služeb s aplikačním rozhraním [16].

Pátá verze MVC přináší výchozí podporu několika možností ověřování uživatelů, sama obsahuje Bootstrap šablonu pro uživatelské rozhraní a další funkcionality [17].

V současnosti poslední verzí MVC frameworku je verze 6 (2015), stojící na ASP.NET 5. Samotná verze ASP.NET je relativně přelomová. Přináší podporu pro operační systémy postavené na Linuxu a také pro OSX. Do této doby mohly tyto webové aplikace běžet jen pod operačním systémem Windows [18].

Jak už bylo naznačeno v kapitole WebForms, tato technologie už není podporována. Existuje odnož zvaná ASP.NET 4.6, která ještě WebForms podporuje, ale je zřejmé, že do budoucna s ní už Microsoft nepočítá [19].

Hlavním programovacím jazykem této platformy se nyní stává C# na úkor Visual Basic. NET, jehož podpora byla odstraněna. HTML helpery jsou nyní umístěny jako atributy HTML elementů, což zvyšuje čitelnost kódu [18].

S nastupujícím trendem Javascriptu přichází do MVC i podpora GruntJS (případně Gulp) [18], což jsou nástroje používané především front-end vývojáři ke kompilaci CSS a Javascriptu. Spolu s tím je také přidána podpora pro NPM a Bower [18], což jsou balíčkovací systémy především Javascriptových aplikací.

Spolu s růstem Javascriptu přibývá i takzvaných SPA (Single Page Application). Asi nejznámějším frameworkem pro psaní těchto aplikací je AngularJS. Proto tato verze přidává také nativní podporu této platformy [18].

Dalšími novinkami jsou Dependency Injection Framework a nový framework pro psaní unit testů xUnit.net [18].

Jak je z postupného vývoje vidět, ASP.NET MVC staví stále na stejném základě, pouze přidává nové funkce a možnosti. S poslední verzí navíc šel velmi naproti současným trendům vývoje webových aplikací.

Bezpečnost  XSS 

Proti XSS (Cross-site scripting) je MVC chráněno hned na dvou místech.

Prvním místem je výpis hodnoty z proměnné. Pokud je totiž použit

vykreslovací engine Razor, který je výchozím pro MVC aplikace, tak při výpisu obsahu proměnné do stránky základním způsobem (přes znak @), engine automaticky převede speciální znaky na HTML entity. Výsledný text je tak zobrazen skutečně pouze jako text, i kdyby obsahoval jakýkoliv škodlivý skript. Je samozřejmě možné explicitně text vypsat bez kódování do entit, ale vyžaduje to vědomou akci programátora [20].

Druhé místo, kde MVC brání útočníkovi v XSS, je již při přijetí hodnot z formuláře. Pokud totiž některá z hodnot obsahuje jakýkoliv HTML, ale i jiný kód, je požadavek odmítnut a na serveru vyvolána výjimka. Ta se mimochodem může uložit a případně se může odeslat e-mail na administrátora, aby věděl, že se pravděpodobně někdo pokouší o XSS útok.

Opět je možné explicitně pro určité pole HTML kód povolit, ale znovu to vyžaduje přímou a vědomou akci programátora.

CSRF 

Cross-site request forgery je typ útoku, který je v MVC frameworku také řešen, bohužel by mohl být vyřešen lépe. MVC obsahuje HTML helper, který je nutné zavolat uvnitř HTML formuláře. K tomu potom na straně kontroleru označit akci atributem, který oznamuje validaci tokenu proti CSRF [21].

Ideálním řešením by bylo podobné použití jako v případě ochrany proti XSS, kdy by se helper volat nemusel a automaticky by byl přítomen při vykreslení jakéhokoliv formuláře. Pomocí atributů by se potom udělovaly výjimky, kde se tento token použít nemá, ale ve výchozím stavu by byla ochrana zapnutá.

SQL Injection 

Ochrana proti SQL injection je v MVC dána použitím ORM systému, kterým je ve výchozím nastavení EntityFramework. Díky tomu se programátor prakticky vyhýbá přímým SQL dotazům a veškerou práci s databází obstarává zprostředkovaně jako práci s dostupnými objekty.

umožňuje nad kolekcemi volat metody známé z SQL. V tomto případě se jedná konkrétně o Linq to Entities [23]. Entity Framework potom z tohoto Linq dotazu vytvoří SQL dotaz, jehož parametry jsou ošetřeny proti SQL injection.

Programátor samozřejmě může vytvořit dotaz přímo v SQL a provést ho nad databází. Pro tento případ nabízí Entity Framework použití proměnných v dotazu, které jsou při vložení jako parametry opět ošetřeny. Samozřejmě je možné vytvořit dotaz čistě pomocí spojování řetězců. Tím by se vytvořil dotaz, který by byl zranitelný. Bohužel pokud z formuláře přijde nějaký kód, je opět zachycen filtrem, který už byl popsán u útoku XSS. Programátor by tedy musel definovat, že pole nemá být chráněno. V tu chvíli by už byl útok typu SQL injection proveditelný.

Databáze 

Jak už bylo zmíněno, pro práci s databází je v MVC vyhrazen Entity Framework. Jedná se o ORM systém, který mapuje řádky z databáze na instance objektů (entity). Ve výchozím nastavení je Entity Framework nastaven na strategii CodeFirst, která umožňuje vytvářet relační databázi objektů a vazeb mezi nimi. Po vytvoření všech objektů a vazeb jsou dvě možnosti, jak z objektů vytvořit databázi.

První možností, která umožňuje kontrolu vytvořené struktury, jsou migrační třídy, zkráceně migrace. Migrace je automaticky vygenerovaná třída (pomocí Entity Frameworku), která obsahuje metodu pro zvýšení verze databáze (zpravidla přidání sloupců) spolu s metodou snížení verze databáze, která umožňuje z nové verze přejít zpět na původní (odebrání nově přidaných sloupců). Těchto migračních tříd může být nekonečně mnoho, používají se totiž i pro vytvoření databáze, i pro přechod mezi verzemi databáze.

Druhá, více automatizovaná možnost, je zapnutí takzvaných automatických migrací. To paradoxně znamená, že žádné migrace nejsou viditelně vytvářeny, ale podle aktuálního stavu databáze se vždy vygeneruje jedna velká migrace, která upraví databázi tak, aby odpovídala modelu.

Při použití obou zmíněných možností se databáze upravuje se spuštěním aplikace. Entity Framework poté dovoluje vytvořit metodu, ze které je možné naplnit databázi inicializačními daty, pokud aplikace nějaká potřebuje. Tato metoda je potom volána po každé úpravě databáze.

2.4 Java

Jak je vidět už na obr. 1, Java je jazyk používaný především u větších aplikací. Důvodem je léty prověřená stabilita a rychlost. Java je hojně využívaná u nejvíce navštěvovaných portálů internetu [24], které potřebují vysokou výkonnost na klíčových místech systému.

Proč Java není používaná více a hlavně u menších aplikací? Jedním problémem je pomalejší vývoj. Je totiž nutné kód napsat, zkompilovat, nasadit na testovací server a potom teprve zjistit, jak vše funguje. Druhým důvodem je částečně paradoxně právě malá rozšířenost, díky které není velký výběr hostingů, které podporují tuto technologii. Mimo to je Java paměťově náročnější a hostingy jsou tak dražší než například u PHP [25].

Pro vývojáře, který chce začít dělat webové aplikace, není Java příliš atraktivní ani tím, že vlastně není žádný oficiální způsob, jak aplikace vytvářet. Pokud nechce psát chování celé aplikace sám, musí použít některý z nepřeberného množství frameworků [26].

Java sama o sobě také neobsahuje moc velké množství nástrojů a pro rozšířenější funkčnost je nutné použít balíčky třetích stran. To nakonec vede k mnoha referencím a díky částem cizího kódu, které se třeba ani nepoužijí, je pak výsledná aplikace velká.

Na druhou stranu je ale Java v současnosti pravděpodobně nejvýkonnějším nástrojem, ve kterém lze psát webové aplikace. Použil ji i Twitter, když měl výkonnostní problémy, protože jeho aplikace napsaná původně v Ruby On Rails nezvládala zpracovávat miliony požadavků.

rychlosti. Po přepsání hlavní části aplikace do Javy výkonnostní problémy zmizely [27].

Co se týče bezpečnosti, která je probíraná u obou předchozích platforem, nedá se u Javy jednoznačně určit, právě kvůli zmíněnému vysokému počtu frameworků, které lze pro vývoj v Javě použít. Obecně pokud je práce s databází řešena přes nějaký framework, vstupy by měly být ošetřeny a proto SQL injection nehrozí. Co se týče útoku XSS, tak existují frameworky s šablonovacími systémy, kde je výchozí výpis kódován do HTML entit. Stejně tak ale existují ty, kde ve výchozím stavu výpis kódován není, a proto je nutné všude volat další metodu, nebo použít jiný zápis pro kódovaný výstup. Pro ochranu proti CSRF je v některých frameworcích hotová funkčnost, zatímco v jiných chybí a je nutné ji implementovat vlastním způsobem.

2.5 Porovnání

Tabulka 1 – Porovnání serverových jazyků

PHP  ASP.NET 

JAVA 

WebForms  MVC 

Výhody  + rychlost vývoje 

+ jednoduchost  + levný a dostupný 

hosting  + rozsáhlý balík 

funkcí 

+ kompilovaný kód 

+ kompilovaný kód  + potvrzená 

výkonnost  + grafický editor 

+ stavové http 

+ architektura MVC + možnosti 

rozšiřitelnosti 

Nevýhody 

‐ náchylnost  k chybám 

‐ příliš jednoduchý  (nutný 

framework) 

‐ roztříštěnost 

‐ menší výběr hostingů 

‐ větší paměťová náročnost  ‐ obtížný výběr  drahého hostingu

‐ ještě větší pam. 

náročnost 

‐ obtížný výběr  frameworku 

‐ do budoucna  nepodporovaný 

‐ malá kontrola  nad HTML 

‐ větší nároky pro  začátečníky 

3 Návrh řešení

3.1 Technologie

Pro tento projekt jsem se rozhodl použít ASP.NET [33][34] MVC [29].

V době vytváření aplikace byla nejvyšší dostupná verze 4.

Tuto variantu jsem zhodnotil jako nejlepší pro vytvoření této ne úplně triviální aplikace, u které jsou předpoklady pro další rozvoj. ASP.NET MVC je v případě potřeby vysoce přizpůsobivý. Na druhou stranu u určitých částí lze nechat výchozí implementaci. Vývoj v něm je rychlý, jelikož už samotný vytvořený projekt obsahuje plně funkční webovou aplikaci, která se už dále jen upravuje. K mému rozhodnutí přispěly i dobré zkušenosti, které s vývojem v tomto frameworku mám. Jako hlavní programovací jazyk jsem zvolil C#.

Spolu s tím Microsoft SQL databázi, která je téměř automatickou volbou pro tuto technologii. Abych s ní mohl komfortně pracovat, vybral jsem Entity Framework v poslední dostupné verzi 6 [30], protože mapuje jednotlivé záznamy z tabulek na konkrétní instance objektů (entity). Jedná se o ORM systém. Také usnadňuje psaní dotazů, které probíhá formou Linq přímo v jazyce C#. Nehledě na možnost návrhu databáze přímo ze zdrojového kódu, které jsem také využil.

CodeFirst je název přístupu návrhu databáze ze zdrojového kódu, který Entity Framework nabízí. To znamená, že databáze nebyla vytvořena pomocí SQL skriptů, ale byly vytvořeny objekty, které na sebe mají určité vazby.

Entity Framework podle toho vytvořil databázi. Jednotlivé objekty však prakticky stejně přestavují tabulky.

Ze strany uživatelského rozhraní jsem použil framework Bootstrap ve verzi 3 [31]. Pro ten jsem použil komerční šablonu [36], která obsahovala základní prvky, které jsem chtěl použít v designu aplikace.

Pro vytvoření vlastních stylů aplikace jsem použil technologii LESS, jejíž soubory se potom kompilují do CSS, oproti tomu tato technologie přináší větší komfort a celkově méně kódu pro dosažení stejného výsledku.

Pro interaktivnost stránky jsem použil Javascript s pomocí frameworku jQuery [32] a několika dalších doplňků.

3.2 Databáze

Na obr. 3 je vidět návrh části databáze z pohledu produktů. Jedná se o část databáze, která se používá k zobrazování produktů. Tato část databáze je také vždy kompletně promazána a jsou všude vytvořeny nové záznamy, pokud administrátor použije jiný konfigurační soubor.

Tabulka Products na obr. 3 obsahuje seznam produktů, které samy o sobě nejsou nijak obsáhlé. V podstatě mají název a slug, což je název převedený do tvaru, který vyhovuje URL. Tento slug je potom součástí URL adresy konkrétního produktu.

obr. 3 – Návrh databáze produktů

Produkt rozšiřuje v první řadě tabulka ProductDescriptions, kde jsou uložené popisky produktu už v konkrétním jazyce. Popisky mohou být různého typu. Nejjednodušším je text, který může být buď jednoduchý, nebo formátovaný pomocí HTML. Mezi další typy patří odkazy na obrázky, na dokumentaci. Trochu speciálním typem popisku je popisek určující kategorii.

Tento popisek, kterým může být například text „výkonový analyzátor“, je navázán na určitou kategorii v tabulce ProductCategories (například „Výkonové analyzátory“), do které potom spadá.

Obě tabulky (popisků i kategorií produktů), stejně jako některé další, jsou napojeny na tabulku TranslationLanguages, čímž je určeno v jakém konkrétním jazyce záznamy jsou. K této tabulce (TranslationLanguages) je také vázána tabulka TranslationPhrases, kde jsou překlady pro všechny veřejné texty používané napříč celými stránkami.

Mimo uvedené popisky a zařazení do kategorií rozšiřují produkt ještě atributy z tabulky ProductAttributes. Kombinací vybraných atributů u některého produktu vznikne konkrétní typ produktu s přesně danými parametry, mezi které patří například rozsah vstupních napětí nebo zda je u produktu ochrana přepětí či nikoliv. Hodnota atributu bývá zpravidla jedno písmeno či krátká kombinace více znaků.

Jednotlivé atributy jsou zařazeny do skupin, které jsou uloženy v tabulce ProductAttributesGroups. Tyto skupiny pouze dělí atributy. Z každé skupiny lze vybrat pro typ produktu vždy jen jeden atribut. Druhou vlastností je uchovávání pozice. Díky tomu se výběr atributů zobrazuje v konkrétním pořadí.

Aby bylo pro zákazníka jednoduché zjistit, co který atribut znamená, mají atributy přidělené popisky, které se dynamicky zobrazují při jejich výběru. Tyto jsou uloženy v tabulce ProductAttributesDescriptions. Popisky atributů mají vždy název a hodnotu.

Popisky jsou k atributům navázány přes vazební tabulku ProductAttributeDescriptionProductAttributes, která zprostředkovává vazbu M:N. Pokud není popisek propojen s žádným atributem, zobrazuje se vždy. Pokud ale v tabulce má nějaké záznamy, zobrazuje se jen při vybrání konkrétního atributu.

Popisky jsou také pro přehlednost rozděleny do skupin a případně podskupin. Jednotlivé skupiny jsou definovány v tabulce ProductAttributeDescriptionGroups, kde mají svůj název a jsou spojeny s konkrétním jazykem. Tyto skupiny mohou obsahovat konkrétní popisky i podskupiny. Skupiny uvnitř skupin neboli podskupiny jsou potom definovány v tabulce ProductAttributeDescriptionSubGroups. Vizuálně potom tvoří menší nadpis ve skupině, pod kterým jsou zobrazeny popisky náležící této podskupině.

Na obr. 4 je zobrazená struktura databáze týkající se uživatelů. Některé tabulky mají prefix AspNet, což je důsledkem použití některých výchozích implementací správy uživatelů. Díky tomu je také databáze připravena pro různá další použití. Například zde tabulky AspNetUserClaims a AspNetUserLogins nejsou zatím aplikací používány. Jedná se o tabulky, které se využívají při napojení aplikace na jinou autentizační autoritu (například Google, Facebook apod.).

Výchozí tabulkou zde je AspNetUsers, kde jsou uloženi uživatelé systému, a to včetně těch, kteří mohou administrovat aplikaci. Právě administrátoři jsou potom přes vazební tabulku AspNetUserRoles propojeni s rolí Administrator, která je uložena v tabulce AspNetRoles. Uživatel obecně musí mít nutně vyplněný e-mail, aby bylo možné na něj odeslat případný odkaz na obnovení zapomenutého hesla. Kromě toho má uživatel možnost vyplnit ještě kontaktní jméno, telefonní číslo a adresu společnosti, kterou zastupuje. Adresa je poté uložena v tabulce Addresses. Pokud jsou tyto údaje zadány, jsou potom předvyplněny při vytváření poptávky.

Další tabulkou z návrhu je tabulka ShoppingCarts, která v sobě uchovává stav všech košíků všech uživatelů aplikace. Primárně se košík spojí se zákazníkem přes unikátní identifikátor, který se zákazníkovi uloží do Cookies. Pokud je zákazník přihlášený nebo se poté přihlásí, spojí se košík přímo s jeho účtem.

Obsah košíku se ukládá ve formátu XML do sloupce Content v tabulce ShoppingCarts. Toto XML pole bylo zvoleno místo klasického návrhu, kdy by měl košík na sebe navázány objekty produktů spolu s počty a dalšími informacemi. Důvody byly hned dva. Prvním je to, že produkty jako takové nemusí být trvalé, a proto by relační vazby byly nevhodné, dokonce i zbytečné.

Druhým důvodem byla možnost kopírovat košík do poptávky, která z něho

obr. 4 – Návrh databáze uživatelů

V případě, že zákazník dokončí výběr produktů a potvrdí vytvoření poptávky, smaže se záznam z tabulky ShoppingCarts a vytvoří se nový v tabulce Demands. Do tohoto nového záznamu se zkopíruje obsah z pole Content. V případě propojení původního košíku s uživatelem zůstává i poptávka propojená s daným uživatelem. Poptávku si později převezme uživatel s oprávněním administrátor, který ji začne vyřizovat. To se projeví změnou stavu poptávky a zároveň propojení s administrátorem, takže lze zjistit, kdo poptávku zpracovává.

Administrátor je také jediný, kdo může pracovat s tabulkou DataSets.

Tato tabulka obsahuje záznamy, které se vážou na jednotlivé konfigurační soubory. Po nahrání konfiguračního souboru se zde vytvoří záznam, který je spojený s uživatelem, který ho nahrál. Uživatel potom může otestovat validitu souboru, čímž se vyplní pole ParserState a také může soubor použít, čímž se nastaví pole IsInUse. Také dojde ke smazání všech dat z části databáze, kde jsou produkty a posléze opět naplnění novými daty.

Struktura XML nákupního košíku/poptávky

<Cart>

<Items>

<CartItem Id="1" Count="3" Url="http://www.kmbsystems.cz/cs/product/smc- 144#L-NOCT-N-N-N-P-100" UID="9e4c47f7-c94f-4c8c-ba45-5ce31247c972">SMC 144 L- NOCT-P-100</CartItem>

<CartItem Id="1" Count="2" Url="http://www.kmbsystems.cz/product/smc- 144#U-X_100mA-R-B-E-S-100" UID="b67a6619-6733-4436-8cd4-affdd0625822">SMC 144 U-X/100mA-R-B-E-S-100</CartItem>

<CartItem Id="1" Count="6" Url="http://www.kmbsystems.cz/product/smc- 144#L-S015-I-D-E-P-400" UID="a5027a1e-4f0c-45ee-a1dc-40bbd4570e06">SMC 144 L- S015-I-D-E-P-400</CartItem>

</Items>

<Note>Prosím o zavolání.</Note>

<Contact Email="T.Zenkner@email.cz" Phone="+420XXXXXXXXX">Tomáš Zenkner</Contact>

<Address Street="Pražská 1" City="Liberec" Country="Czech Republic"

ZipCode="46001">Company s.r.o.</Address>

</Cart>

kód 3 – Struktura XML nákupního košíku/poptávky

V uvedeném kódu je vidět struktura XML, pomocí které je uložen obsah košíku, ale stejně také poptávka.

Obsah se vytváří postupně tak, jak se plní košík. Položka přidaná do košíku je CartItem, vnořená v elementu Items, který je v elementu Cart. Tato položka obsahuje atributy, které jsou vlastnostmi dané položky v košíku.

Atribut Id je hodnota id produktu, který je v databázi. Tato hodnota není 100% spolehlivá, protože pokud byl během vytváření košíku použit jiný konfigurační soubor, tak daný produkt už má jiné id. Další atributem je Count, což je počet položek, o které má zákazník zájem. Atribut Url obsahuje kompletní URL adresu přesně k danému typu produktu. Posledním atributem je UID. Tento atribut obsahuje unikátní id dané položky v tomto XML. Pomocí tohoto id se párují zákaznické akce s položkami z UI. Hodnota uvnitř elementu CartItem je potom přesný název produktu spolu s typem.

Po naplnění košíku položkami, o které má zákazník zájem, je nutné zadat kontaktní údaje na zákazníka (což je většinou nákupčí, který zastupuje nějakou společnost). Tyto kontaktní údaje jsou poté uloženy v elementu Contact, který je vnořený v elementu Cart. Tento element obsahuje atribut Email, ve kterém je uložený e-mailový kontakt a atribut Phone, ve kterém je uložený telefon na zákazníka. Jako hodnota je zde uloženo jméno na kontaktní osobu.

Poslední částí této struktury je adresa společnosti, která stojí za poptávkou. Ta je uložena v elementu Address, který je vnořený v elementu Cart. Tento element obsahuje atributy, kterými jsou Street (ulice), City (město), Country (země) a ZipCode (poštovní směrovací číslo apod.).

Hodnotu u tohoto elementu obsazuje název společnosti.

Kromě předchozích údajů lze vyplnit i poznámku, což je univerzální způsob pro případné dodatky ze strany zákazníka. Poznámka je uložena jako hodnota v elementu Note, který je vnořený v kořenovém elementu Cart.

4 Aplikace

4.1 Parser konfiguračních souborů

Pomyslným jádrem celé aplikace je parser konfiguračních souborů. Ten zprostředkovává naplnění databáze daty potřebnými pro chod webu. Pomocí konfiguračních souborů, takzvaných Datasetů, se provádí nejen lokalizace webu do dalších jazykových mutací spolu s nalinkováním ostatních instancí webů na jiných doménách, ale také zadání produktů a všech parametrů k nim. Tento způsob plnění databáze byl vybrán s ohledem na jednoduchost zadávání dat a v případě problémů také jednoduchost návratu k předchozímu, funkčnímu sestavení.

Aby byla práce s konfiguračními soubory jednoduchá, byl zvolen formát, který je výstupem z programu Microsoft Office Excel. Toto rozhodnutí také usnadňuje práci s webem pracovnicím administrativy, které se tak nemusí učit obsluhu nového uživatelského rozhraní.

4.1.1 Zdrojová data

Kromě popisků, obrázků, dokumentace a kategorií zde byly dva základní problémy. Jak dostat následující obrázek ve strukturované podobě do databáze? A jak umožnit zákazníkovi jednoduše vybrat konkrétní typ produktu o který má zájem?

Na obr. 5 jsou parametry produktu s názvem SMC. Konkrétní typ produktu je poté vytvořen kombinací dalších čísel a písmen. Na určitém místě za názvem může být vybrána vždy jedna z možností písmen, která symbolizuje konkrétní vlastnost výsledného typu.

Zvolené řešení nakonec určuje, že jednotlivé možnosti jsou uvedeny vedle názvu produktu ve sloupcích jako ve skupinách. K nim relevantní popisky jsou uvedeny níže v dokumentu a mají u sebe možnosti, při kterých se mají zobrazit. Popisky potom mohou být zařazeny ve skupinách nebo podskupinách, pro lepší strukturu výsledných popisků. Dodatek, že některé

atributy (M a E v tomto případě) nelze kombinovat zatím řešený není, ale jeho řešení je naplánováno do další verze aplikace.

obr. 5 – Parametry produktu

Konkrétní řešení a jeho detailní vysvětlení je uvedeno u obr. 7 a obr. 8.

Zobrazení atributů a jejich výběr je vysvětlen dále u obr. 10.

4.1.2 Microsoft Office Interop

Původní návrh počítal s použitím technologie přímo od společnosti Microsoft, která je dodávána jako součást balíku Microsoft Office. Microsoft Office Interop [37] je technologie, která umožňuje číst a upravovat dokumenty vytvořené v nástrojích MS Office. Možnosti jsou široké, od podpory velkého množství formátů až po rozšířené funkce obsažené v samotném balíku MS Office.

Po provedení základní implementace, která byla ve vývojovém prostředí plně funkční, se ukázalo, že ji nebude možné použít v produkčním prostředí.

Aby tato technologie fungovala, je nutné, aby byl na cílovém stroji nainstalován balík Microsoft Office, což v případě webových serverů není většinou možné. Řešením by bylo použít VPS, což je ale finančně náročné a proto byl zvolen jiný postup.

4.1.3 ClosedXML

Další možností pro práci s dokumenty z MS Excel bylo použít otevřený formát OpenXML, ve kterém jsou soubory standardně ukládány od verze MS Office z roku 2007.

Protože by bylo komplikované pracovat s čistými soubory XML, byla použita stávající implementace pro práci s těmito soubory, nazvaná ClosedXML [28]. Díky tomuto projektu nebylo nutné pracovat přímo se soubory, ale pouze komunikovat s rozhraním, které implementace nabízí.

Byla navržena a implementována také ještě jedna pomyslná vrstva, která umožňuje procházet buňky po krocích ve všech směrech a také respektuje pravidla nastavená v dokumentu, jako jsou například komentáře, které začínají znakem „#“.

Pomocí této technologie se nakonec podařilo efektivně zpracovávat soubory formátu *.xlsx. To je sice omezení oproti Microsoft Office Interop, ale protože je to výchozí formát aplikace MS Office Excel, není to tak závažné.

4.1.4 Struktura dokumentu

Pro uložení veškerých dat v souboru se využívají panely a uvnitř nich je vždy definovaná struktura, kterou by měla data dodržovat. Kvůli použití panelů a praktické potřebě 3. rozměru oproti klasické tabulce nebylo možné použít nějaký jednoduchý formát, jako by mohl být *.csv, kde jsou data na řádcích oddělena většinou středníkem. Cílem totiž bylo, aby všechna data byla v jednom souboru.

Každý panel by tedy měl respektovat určitou strukturu. Aby bylo prostředí přátelštější pro obsluhu, je možné do dokumentu psát komentáře, tzn. texty, které parser nevidí a vidí je pouze uživatel. Tyto texty jsou většinou vysvětlujícího rázu, kdy popisují právě strukturu panelu, aby si ji uživatel nemusel pamatovat. Za komentář je považován text, který začíná znakem „#“.

Parser po detekci tohoto znaku zbytek textu ignoruje. 

Překlady a odkazy na další domény 

obr. 6 – Panel překladů a odkazů na další instance aplikace

Jedním z panelů dokumentu by měl být panel s názvem Translations.

V tomto panelu se potom definují překlady webové aplikace. První skupina dat je označena Sites, jak je vidět na obr. 6. V této sekci se definují odkazy na další jazyky v ostatních instancích této aplikace. Tyto jazyky jsou potom přidány mezi nabízené lokalizace i u této instance. Po kliku na ně je uživatel přesměrován na jinou doménu, ale vlastně by si neměl téměř ničeho všimnout, pouze změny jazyka.

Další sekcí je sekce označená slovem Languages. V této sekci se definují jazyky, které budou dostupné přímo na této instanci a jejichž překlady budou explicitně vyplněny v další sekci. Výchozím jazykem, kterým disponuje aplikace i bez konfiguračního souboru, je angličtina. Zvolená kultura je en-US. Proto tento jazyk není nutné v konfiguračním souboru definovat a také jsou pro něj předvyplněny překlady frází, aby se podle něho daly vyplnit překlady dalších jazyků.

Zmíněné překlady se vkládají v další sekci, která je označena jako Translations. V této sekci jsou v prvním sloupci jednoznačná označení jednotlivých frází, v druhém sloupci jsou předvyplněné anglické texty a do dalších sloupců se přidávají už lokalizované překlady podle hlavičky kultury,

která je uvedena nad každým sloupcem. Vyplněním všech překladů se stane každá veřejná část aplikace lokalizovanou do nových jazyků.

Produkty 

obr. 7 – Panel produktu 1

Na obr. 7 je zobrazen panel produktu. Panely produktu nemají žádná speciální jména, pro přehlednost se ale doporučuje použít název produktu.

V názvu panelu také může být kultura, která určuje jazyk, ve kterém jsou zadané popisky a další údaje o produktu. Pokud kultura není vyplněna, jak je vidět na obrázku u právě otevřeného panelu, tak je použita výchozí en-US, čili se jedná o popisky a parametry pro výchozí jazyk, angličtinu.

V samotném panelu se pak hledá první buňka v první sloupci, ve které je název produktu. Po nalezení se čtou atributy po skupinách ve sloupcích, které jsou vpravo od nalezeného názvu.

Po načtení skupin může, ale nemusí, následovat sekce s názvem Predefined types, ve které jsou definovány vybrané atributy produktu a tvoří tak už konkrétní typ produktu.

Další sekcí je Descriptions, ve které jsou jednoduché popisky produktu, ať už jako prostý text, nebo HTML. Pokud má v pravém sloupci vedle sebe nějaký text, bere se tento text jako název kategorie, do které produkt patří a daný popisek slouží jako označení produktu v kategorii.

obr. 8 – Panel produktu 2

Na obr. 8 je vidět druhá část panelu produktu. Po popiscích je zde sekce Images, ve které jsou odkazy na obrázky týkající se daného produktu. Další sekcí je sekce s názvem Documents, kde jsou obdobně vyplněny odkazy na jakékoliv dokumenty týkající se daného produktu. Na rozdíl od obrázků mají dokumenty ještě své názvy umístěné ve druhém sloupci. Mezi dokumenty nejčastěji patří návody na používání a údržbu.

Poslední sekcí dat je sekce s nadpisem Parameters. V této sekci jsou ve skupinách a podskupinách uloženy popisky, které se dynamicky mění během volby atributů produktu. V prvním sloupci je uveden název skupiny. V dalším může být uveden název podskupiny, ale ta není povinná. Ve třetím sloupci jsou čárkou oddělené atributy, při kterých se daný popisek zobrazuje. Ve čtvrtém sloupci je potom název hodnoty a v posledním, pátém, hodnota

4.1.5 Log

S takovouto složitou strukturou je nutné mít nějakou možnost zobrazit si případné chyby v dokumentu. Z tohoto důvodu byl zaveden log, do kterého se vypisují nalezené problémy v průběhu zpracovávání souboru. Uživatel také může soubor zpracovat jen zkušebně a zjistit jeho chyby ještě předtím, než ho použije.

Samotný algoritmus zpracovávání je navržen tak, že je k datům velmi benevolentní. Přeci jen obsluhou budou lidé a lidé chyby dělají. Algoritmus si proto umí poradit se sekcemi, které nemají nadpisy, se zpřeházenými sekcemi, ve většině případů dokáže odhalit data v sekci, do které nepatří a správně tyto data zpracuje, s chybějícími nebo nesmyslnými daty.

Aby uživatel mohl chyby nalézt a opravit, případně byl upozorněn na něco, co ani on neměl v úmyslu, vypisuje se do logu průběh celého zpracování.

Log byl navržen se třemi stupni hlášení. První stupeň je standartní logovací zpráva, která pouze vypisuje, co se zrovna děje. Druhým stupněm je varování, že něco není úplně v pořádku, nebo by mohla proběhnout nějaká nechtěná akce. Třetím stupněm hlášení je chyba, která způsobila, že nelze ve čtení pokračovat. Tento třetí stupeň zatím nebyl nikde použit.

Po dokončení čtení konfiguračního souboru se vyhodnotí správnost dokumentu a tato informace se uloží k Datasetu. V případě, že v logu jsou pouze zprávy prvního stupně, je dokument vyhodnocen jako naprosto v pořádku. Pokud se v logu objeví alespoň jedno hlášení typu varování, je soubor vyhodnocen jako zpracován s varováním. Pokud se objeví chybová zpráva a čtení je tak ukončeno, je dokument hned označen jako chybný.

Zde je vidět ukázkový výstup logu ze čtení konfiguračního souboru. U řádků, kde to dává smysl, se zobrazuje i adresa buňky, kde se daný údaj podařilo nalézt. Na konci je malé shrnutí s výsledným stavem a počtem varování, na které se narazilo. V případě, že zde není 0, může uživatel potom dohledat a zkontrolovat konkrétní varování.

[Log]: ====== Start parsing ======

[Log]: Searching for translations.

[Log]: Using 'Translations' as translation sheet.

[Log]: Searching sites definition.

[Log]: Found site 'http://www.kmb.es' [A4].

[Log]: Found site 'http://www.kmb-systems.de' [A5].

[Log]: Found definition of default language 'en-US' [A11].

[Log]: Found language definition 'cs-CZ' [A12].

[Log]: Found translation area.

[Log]: ======= Next sheet ========

[Log]: Parsing product sheet '(cs-CZ) SMC 144'.

[Log]: Found sheet culture: 'cs-CZ'.

[Log]: Using 'cs-CZ' as sheet culture.

[Log]: Searching product name cell.

[Log]: Found product name 'SMC 144' [A3].

[Log]: Searching product attributes.

[Log]: Attributes found, parsing groups.

[Log]: Parsing 1. group of attributes [B3].

[Log]: Parsing 2. group of attributes [C3].

[Log]: Searching predefined product types.

[Log]: Predefined product types found at [A16].

[Log]: No predefined types defined.

[Log]: Searching product descriptions/images/documents.

[Log]: Descriptions found at [A20]

[Log]: Images found at [A29]

[Log]: Documents found at [A37]

[Log]: Searching product parameters.

[Log]: Parameters found at [A45].

[Log]: Reading group 'AUX' [A45].

[Log]: Reading group 'Měřené veličiny' [A54].

[Log]: Reading subgroup 'Frekvence' [B55].

[Log]: Reading subgroup 'Napětí' [B58].

[Log]: ====== Parsing ended ======

[Log]: Final parser state: ParsingOK [Log]: Warnings: 0

[Log]: =========== End ===========

kód 4 – Ukázka výstupu logu

4.2 Veřejná část

Hlavní stránka

Na obr. 9 je zobrazena hlavní stránka aplikace. Vlevo nahoře lze vidět logo a vedle něj prvek pro přepínání jazyka. Dále vpravo je text Nepřihlášen, který se po kliknutí rozbalí na možnosti Přihlásit a Registrovat. Dalším prvkem je zelený košík, uvnitř kterého je počet položek v košíku (na tomto zobrazení 0).

Uprostřed je velké vyhledávací pole a pod ním přehled produktů, kde jsou jednotlivé produkty vypsány do kategorií. Na tomto konkrétním obrázku je pouze jeden produkt, jelikož se jedná o testovací verzi. Na pravé straně v patičce už jsou potom jen užitečné odkazy Domů a Kontakty.

Celý design je navržený jako responsivní, což znamená, že se přizpůsobí velikosti zařízení. Proto je možné prohlížet aplikaci také na tabletu či telefonu

a pro tato zařízení se vždy zobrazí design obsahující prvky právě pro ně.

Příklad zobrazení na mobilním zařízení je uveden jako Příloha A.1.

obr. 9 – Hlavní stránka aplikace

Vyhledávání

Po zadání výrazu do vyhledávacího pole na hlavní stránce se provede hledání. Zadaný výraz se vyhledává v názvu produktu, v textech popisků, názvech dokumentace, typech produktů a v popiscích atributů. Seznam vyhledaných produktů je potom řazen podle názvu a zobrazován stránkovaný po 10 položkách, viz Příloha A.2.

Detail produktu

V detailu produktu (Příloha A.3) dominují popisky produktu sekundované obrázkovou galerií. Pod touto galerií jsou také odkazy na stažení dokumentace nebo manuálů. Nad galerií a pod odkazy na stažení jsou umístěna tlačítka pro přidání konkrétního typu produktu do košíku. Pro výběr konkrétního typu produktu (tzn. nastavení atributů) se použije prvek, který je pod popisky produktu.

Výběr atributů produktu

obr. 10 – Výběr atributů produktu

Výběrem atributů u produktu vznikne konkrétní typ produktu. Pro výběr atributů slouží prvek zobrazený na obr. 10. Hlavní částí je několik prvků pro výběr atributů v jednotlivých skupinách. Po každé změně výběru se název typu produktu nastaví podle atributů, také se zobrazí/skryjí popisky podle vybraného typu a také se změní URL adresa.

Jak je také vidět na obrázku, URL adresa koresponduje s vybraným typem.

Lze tak adresu někomu poslat a on dostane konkrétní typ produktu. Tato adresa se také ukládá do košíku, takže se uživatel může podívat na konkrétní typ produktu, který chce poptat.

Ještě nad výběrem atributů jsou předpřipravené typy produktů, které jsou doporučované a jejichž výběr bývá častou volbou. Po kliknutí na ně se přednastaví atributy, které těmto typům odpovídají.

Košík

obr. 11 – Poptávkový košík

Po kliknutí na tlačítko Do košíku se přidá produkt v konkrétním typu do košíku. Na obr. 11 je pak zobrazeno okno nákupního košíku tak, jak ho vidí uživatel. Na této stránce lze upravovat počty položek a také položky odebírat.

Uživatel se může zavřením okna pomocí křížku nebo kliknutím na tlačítko Zpět na web vrátit k prohlížení a přidávání dalších položek.

Po tom, co výběr dokončí a obsah košíku odpovídá tomu, co chce poptat, klikne uživatel na tlačítko pokračovat a tím se dostane na druhý z kroků naznačených v horní části, tedy Kontaktní informace. Mezi jednotlivými kroky lze přecházet i klikáním na oranžové kroužky vždy u daného kroku.

V dalším kroku je ještě nutné vyplnit kontaktní údaje na nákupčího a společnost, kterou zastupuje (Příloha A.4). Veškeré zadané údaje se ukládají, takže pokud uživatel v posledním kroku například zavře košík a vrátí se k němu další den, tak zde uvidí nejen jednotlivé položky v košíku, ale také vyplněné kontaktní údaje včetně poznámky.

Ve třetím kroku pak vidí uživatel rekapitulaci celé poptávky, ještě předtím než ji potvrdí. Vidí zadané údaje a přehled produktů s jejich počty (Příloha A.5). Po kontrole těchto údajů může uživatel již vytvořit poptávku a tím se dostane na poslední obrazovku (Příloha A.6), kde je poděkování.

V tuto chvíli přibyla v administraci nová poptávka a na administrátory systému byl právě odeslán e-mail s popisem této poptávky. Součástí e-mailu je i odkaz do administrace této aplikace, aby uživatel mohl hned přejít a začít poptávku vyřizovat. Jak to proběhne, je dále popsáno v kapitole Administrace.

Uživatelský účet

Pro uživatele, který se chystá vytvořit poptávku, je výhodné založit si účet. Díky tomuto účtu bude moci sledovat stavy svých poptávek. Také si může v účtu uložit kontaktní údaje a informace o firmě, takže když vyplňuje poptávku, nemusí je znovu zadávat. Navíc se košík neváže jen k prohlížeči přes Cookie, ale je spojen i s daným účtem, takže po přihlášení na jiném zařízení se uživatel dostane ke svému košíku.

Při registraci je nutné vyplnit pouze jednoduchý formulář (Příloha A.7), kde je povinný pouze e-mail, který je totiž nutný k případné obnově zapomenutého hesla. Mimo to musí logicky uživatel zadat ještě své přihlašovací jméno a heslo. Po vytvoření může uživatel hned využívat výhody spojené s účtem.

Uživatelský účet je mimo jiné použitý také k přístupu do administrace, na to k němu ale musí být přiřazena role Administrátor. To je vlastně jediná role, která v systému je. Standartní účet bez role je totiž brán jako zákaznický. Aby byl v systému alespoň jeden administrátor, je při zavedení databáze vytvořen.

Administrace

Celé administrační rozhraní je v anglickém jazyce, a to je neměnné. To bylo zvoleno pro to, aby se snížil počet textů, které jsou nutné k překladu.

Obsluha by měla zvládat anglický jazyk alespoň na základní úrovni, navíc je administrace velmi jednoduchá.

Po vstupu do administrace se objeví stránkovaný seznam poptávek.

U poptávky je vidět datum vytvoření, společnost a člověk, který poptávku vytvořil, stav a případně také administrátor, který poptávku zpracovává.

Dále je možné přejít na detail poptávky.

Nahoře jsou záložky Demand, která vede na tuto stránku a Import pro přepnutí na stránku, kde se nahrávají konfigurační soubory. Vpravo je ještě umístěn odkaz Leave, který uživatele odvede z administrace zpět na hlavní stránku aplikace (Příloha A.8).

V detailu poptávky je vidět vše, co je k poptávce dostupné, tzn. datum vytvoření, kontakt, adresa, případná poznámka, a také seznam poptaných položek. Je zde ještě umístěno tlačítko na převzetí poptávky. Pokud na něj administrátor klikne, je přiřazen k poptávce jako zpracovávající a poptávka je převedena do stavu probíhajícího zpracování. Zákazník potom vidí tento stav ve svém účtu.

Pokud by se chtěl zákazník například informovat na svou poptávku telefonicky, obsluha se může podívat do seznamu poptávek na hlavní stránce.

V posledním sloupci vidí uživatele, který si poptávku k sobě přiřadil. Díky tomu hned ví koho kontaktovat a zjistit stav.