Implementace internetového informačního systému v Ruby on Rails

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Implementace internetového informačního systému v Ruby on Rails BAKALÁŘSKÁ PRÁCE Marek Hulán Brno, jaro 2007

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Radek Pelánek, Ph.D. 11

3 Shrnutí Tématem této bakalářské práce je popis frameworku Ruby on Rails a implementace informačního systému pro korespondenční semináře s jeho využitím. První část se věnuje jazyku Ruby a spíše teoretické části frameworku. Druhá část se zabývá implementační stránkou konkrétního systému a je proložena více příklady. m

4 Klíčová slova Ruby, framework, MVC architektura, Ruby on Rails

5 Obsah 1 Úvod 1 2 Základy práce s frameworkem Jazyk Ruby MVC architektura Framework Ruby on Rails Základní komponenty Správa databáze a běhové prostředí aplikace 11 3 Implementace konkrétního systému Požadavky systému pro korespondenční semináře Vztahy a role modelů Kontroléry Autentizace a autorizace Layout Lokalizace Rozesílání ů 29 4 Realizace systému Vývojový server Přesun na školní server Přesun na nový server Statistika návštěvnosti 33 5 Závěr 35 A Obsah CD 36 Literatura a odkazy 37 v

6 Kapitola 1 Úvod Žijeme v době velkého rozšíření Internetu, jakožto prostředku pro komunikaci mezi lidmi. Ti jej užívají často nejen jako komunikačního média, nýbrž také jako jakéhosi ředitele, který každému jednotlivci přiřadí konkrétní činnost. Informační systémy stále častěji řídí běh i malých skupinek osob, které, pokud dodržují určená pravidla, fungují efektivně. Často se pokoušíme najít způsob, jak takový systém správně a rychle vytvořit. Tvůrci se předhánějí v rychlosti, kdo dřív hotové řešení dodá. Zajisté dosti záleží na základních kamenech, na kterých vývojáři začnou své systémy stavět. Stále existují zastánci tvorby na zelené louce, tedy programátoři, kteří každou aplikaci začínají psát bez připravených pomůcek. Dále existuje skupina vývojářů, kteří mají vlastní pomůcky nachystané, nicméně o těch lze bezpečně tvrdit, že znovu vynalézají kolo. A jen málokdy je to kolo opravdu kulaté. Teprve v poslední řadě stojí programátoři používající již hotová řešení. Těch je na výběr veliké množství. Ruby on Rails Následující text by měl poodhalit, jak ke tvorbě malého informačního systému využít framework Ruby on Rails a poukázat na výhody tohoto řešení. K tomu je třeba se nejprve seznámit s tím, jak framework funguje. Ruby on Rails je framework používaný ke tvorbě internetových stránek. Obsahuje velkou řadu nástrojů, které vývojáři ušetří spoustu práce. Samotné knihovny jsou napsány v jazyku Ruby - odsud název Ruby on Rails. Celý framework se stal velmi oblíbeným pro svoji jednoduchost a komfort. Programátorovi nabízí širokou škálu pomocných funkcí, podporu pro testování kódu a několik zajímavých pomůcek pro správu aplikace. Díky velkému rozšíření existuje mnoho doplňků, které zjednošují použití Ruby on Rails, či přidávají zcela nové funkce. Ačkoliv se framework stále bouřlivě vyvíjí, již dnes je velmi často používán pro tvorbu webových aplikací. Autoři si byli vědomi změn, které nastávají mezi různými verzemi, a proto má každá aplikace možnost používat libovolnou verzi frameworku. O kvalitách Ruby on Rails dále svědčí fakt, že programátoři proslulého vývojového prostředí NetBeans začlenili jazyk Ruby a projekty Ruby on Rails jako první adoptivní jazyk do svého programu. 1

7 1. ÚVOD Organizace práce Pro programování nad frameworkem Ruby on Rails je třeba alespoň elementární znalost jazyka Ruby, proto se hned zpočátku 2. kapitoly zaměříme na jeho základní vlastnosti. Dále budeme pokračovat základními principy Ruby on Rails. Na jednoduchém příkladu si ukážeme, jak je aplikace konstruována. Vysvětlíme si, jak jsou provázány jednotlivé součásti frameworku a jak se pracuje s databází. Ve 3. kapitole rozebereme tvorbu konkrétního informačního systému. Jedná se o systém korespondenčních seminářů. Po prvotní analýze požadavků se zaměříme na databázový model. U jednotlivých částí si vysvětlíme, co mají za úkol reprezentovat a jak se s nimi pracuje. Poté se podíváme na funkční část systému. Podrobněji se budeme zabývat implementací práv a zajímavým funkcím aplikace, jako je například lokalizace nebo rozesílání ů řešitelům. Závěrečnou kapitolu věnuji poznatkům získaným při nasazování systému do ostrého provozu a popisuji problémy, na které jsem při realizaci narazil. Zaměříme se především na problémy s rychlostí stránek a rozdíl mezi cgi a fastcgi přístupem. Dále uvedu bližší statistické informace o aplikaci. Přínos vlastní práce Hlavním cílem bylo naprogramovat informační systém korespondenčních seminářů. O splnění cíle svědčí systém běžící na adrese <http: //ks.muni. cz>, který obsahuje 3 semináře. Denně jej navštěvují desítky lidí. Aplikace zprostředkovává kontakt mezi řešiteli a organizátory a zjednodušuje jejich vzájemnou komunikaci. Elektronické odevzdávání a opravování řešení přináší jak výhody ekonomické (především pro organizátory), tak i ekologické. Zároveň systém umožňuje vytvářet statistiky, jak se které školy podílejí na řešení a které dosahují nejlepších výsledků. 2

8 Kapitola 2 Základy práce s frameworkem Hned zpočátku je třeba představit jazyk Ruby. V následující části se budeme věnovat základům syntaxe a popíšeme si elementární vlastnosti. Dále se podíváme na architekturu aplikace, která se v Ruby on Rails používá. Základy použití frameworku probereme na jednoduchém příkladu databáze filmů. Na závěr si vysvětlíme, co je běhové prostředí aplikace a co jsou to migrace. 2.1 Jazyk Ruby Ruby je velmi mladým interpretovaným jazykem. Je vyvíjen tak, aby kombinoval výhody imperativního a funkcionálního paradigmatu. Vychází z několika autorových oblíbených jazyků, a sice Perlu, Smalltalku, Eiffelu, Ady a Lispu. Ruby se syntaxí snaží přiblížit přirozenému jazyku. Jeho cílem je, aby byl kód velmi dobře čitelný a aby bylo jednoduché jej napsat. Jazyk je čistě objektový a slabě typovaný. Přehlednost a objektový přístup je nejlépe ilustrován na příkladu times { print "Ruby je čistě objektový jazyk!" } Příklad 2.1.1: přehlednost a objektový přístup Aniž by jste znali syntaxi jazyka Ruby, je na první pohled patrné, co tento příkaz dělá. Z příkladu vidíme, že i číslo je objektem. V mnoha jiných jazycích jsou čísla reprezentovaná tzv. primitivními datovými typy. Ruby však následuje jazyk Smalltalk a všem typům přiřazuje metody a atributy. Objekty jsou neustále otevřené, což znamená, že kdekoliv v programu můžete libovolnému objektu přidat nějakou metodu, atribut, či je libovolně předefinovat. Na jedné straně to může vést k jakési neuzavřenosti tříd a obavám o nechtěný přepis jejich metod a atributů, ale na straně druhé to programátorům dává do rukou velmi mocný nástroj. Pokud o otevřenost tříd nestojíte, můžete použít metodu freeze, která zmrazí objekt a již jej není možné upravovat. Ruby dále zavádí propracovanou manipulaci s tzv. bloky. Pokud se znovu podíváte na první příklad, vidíte, že se volá metoda times objektu 5 a jako parametr se jí předá blok uzavřený složenými závorkami. Metoda time poté pětkrát provede kód obsažený v tomto bloku. Bloku lze také předávat parametry. Lépe to vysvětlí příklad Jako objekt nám 3

9 2.2. MVC ARCHITEKTURA nyní posloužilo pole s názvy sloupečků. Na začátku bloku jsme uvedli, že je vyžadována proměnná column. Metoda map zavolá na každém prvku pole kód následujícího bloku, přičemž za column dosadí aktuální prvek pole. Metoda map vrátí nové pole, které bude obsahovat tytéž názvy, avšak zarovnané na 15 znaků. Jedna z konvencí jazyka ruby je existence podobné metody, jejíž název končí vykřičníkem. Taková metoda nevytváří nový objekt, ale nahradí objekt původní. Pokud bychom chtěli zarovnat všechny prvky v původním poli, použili bychom metodu map!. Zde je opět vidět snaha, přiblížit se reálnému světu a přirozenému jazyku. ['jméno', 'prijmeni', 'plat'].map { column column.center(15) } => [" jméno ", " prijmeni ", " plat "] Příklad 2.1.2: bloky Ruby nepovoluje vícenásobnou dědičnost, nicméně její absenci nahrazuje pomocí tzv. mixinů. Libovolná třída může přimixovat několik modulů. Například pokud definujete vlastní datový typ pole a chcete, aby obsahovalo základní výčtové metody, můžete přimixovat modul Enumerable. Tyto vlastnosti vedly vývojáře Ruby on Rails k tomu, aby svůj framework postavili právě na jazyku Ruby. Podrobnější informace o jazyku Ruby lze nalézt v knize: Programming Ruby [4] Pro srovnání uvedu základní vlastnosti jazyka PHP, který bývá velmi často používán při tvorbě internetových aplikací. Jedná se také o interpretovaný jazyk. PHP sice podporuje objekty, nicméně jazyk na nich není vůbec vystavěn. Ačkoliv jsou v něm implementovány výjimky, žádná z vestavěných funkcí je nepoužívá. Způsob pojmenovaní funkcí se často liší, např. funkce str_replace a Strien. V názvu první je k optickému oddělení použito podtržítko, v názvu druhém podtržítko chybí. Nad PHP existuje několik různých frameworků, které se snaží přiblížit kvalitám Ruby on Rails, nicméně základním nedostatkem je právě jazyk PHP 2.2 MVC architektura Ruby on Rails respektuje tzv. Model, View, Controller architekturu. V podstatě to znamená oddělení funkční, zobrazovací a vykonávací logiky. Model Model je datovým základem celé aplikace. Poskytuje prostředky jak pro získání dat z úložiště, tak pro jejich ukládání a aktualizaci. V rámci Ruby on Rails je model třídou, která zprostředkovává kontakt s databází. Každý model je potomkem třídy ActiveRecord, která je základní komponentou frameworků. Modely reprezentují aktuální stav databáze. 4

10 2.3. FRAMEWORK RUBY ON RAILS Pohled (View) Pohled zobrazuje obsah modelu. Je zodpovědný za výstup aplikace a k datům přistupuje přes modely. V Ruby on Rails generuje webové stránky v xhtml (případně jiném) formátu. Je obsažen v knihovně s názvem Action View, která obsahuje zejména metody pro práci s xhtml značkami a pro směrování dalších požadavků. Soubory s pohledy obsahují xhtml kód a ERb, neboli Embedded Ruby. Jedná se tedy o kombinaci xhtml a jazyka Ruby. Kontrolér (Controller) Kontrolér definuje chování aplikace. Zpracovává vstupy od klienta a určuje, jak se s nimi má zacházet. Na základě těchto vstupů pracuje s modely a na závěr své práce určuje, který pohled použít pro výsledné zobrazení. Knihovna, která v Ruby on Rails toto zařizuje, se jmenuje ActionController. Přijímá vstupy z HTTP požadavků, které odesílá klientský internetový prohlížeč. Veřejné metody kontroléru nazýváme akcemi, které klient může volat. Celkové schéma znázorňuje obrázek 2.1. " -^ -«i ' = } Kontrolér Obrázek 2.1: Schéma MVC architektury 2.3 Framework Ruby on Rails Nyní prozkoumáme framework podrobněji. Nejprve je třeba ukázat, jak se vytvoří nová aplikace. Ukážeme si, kam patří jednotlivé součásti a kde se nalézají konfigurační soubory. Poté nahlédneme na modely, kontroléry a pohledy. Na velmi jednoduchých příkladech si vysvětlíme jejich vzájemnou součinnost. Pro každý projekt je třeba vytvořit novou adresářovou strukturu. Ruby on Rails s sebou přináší skript, který vykoná vše potřebné. Na unixovských systémech stačí zadat příkaz rails nazev_projektu 5

11 2.4. ZÁKLADNÍ KOMPONENTY a vytvoří se adresář s názvem nazev_projektu, obsahující projektový strom. Každá část projektu v něm má své místo. V následujícím textu budou cesty uváděny relativně od kořenu projektového stromu. Nejdůležitější položky si nyní popíšeme. V podadresáři app se nachází všechny soubory, které obsahují zdrojový kód aplikace. Adresář app je nadále rozdělen do čtyř dalších skupin, které jsou: controllers helpers models views Podadresář controllers obsahuje všechny kontroléry aplikace. Helpers je podadresář určený pro pomocné metody, které je možné využít v pohledech. Modely jsou obsaženy v models a pohledy ve views. Podadresář pohledů je rozdělen dalšími podadresáři, které se jmenují podle názvu kontrolérů. Dále obsahují speciální adresář nazvaný layouts, který obsahuje společné šablony. V adresáři config najdeme konfigurační soubory aplikace. Důležité jsou zejména environment.rb, routes.rb a database.yml, o kterých bude řeč později. Podadresář public je jediný veřejný adresář celé webové aplikace. Pouze sem se smí klient přímo podívat, a proto jsou zde uloženy například obrázky, javascriptové knihovny či prosté html stránky. V adresáři public je umístěn i tzv. dispatcher, který zařizuje propojení klienta s interpretem jazyka ruby. Tomuto interpretu jsou podávány zdrojové kódy z adresáře app, které následně zpracovává. V adresáři script se nachází pomocné skripty, které Ruby on Rails obsahují. Najdeme mezi nimi například univerzální generátor souborů (pro generování kontrolérů, modelů, pohledů a dalších), generátor dokumentace, integrovaný webový server Webrick nebo měřič času pro jednotlivé úkony. Skripty se spouštějí přímo z kořenového adresáře aplikace. Na unixovských systémech tedy příkaz./script/generate controller MujPrvniKontroler vygeneruje kontrolér do správného umístění /app/controllers. Pokud spustíte skript se špatnými parametry, vypíše na standardní výstup svůj poměrně obsáhlý způsob použití. 2.4 Základní komponenty Jak jsem již nastínil, jednotlivé části frameworku jsou rozdělené do několika komponent. Nyní je na čase představit ty základní a popsat, jak se používají. 6

12 2.4. ZÁKLADNÍ KOMPONENTY ActiveRecord ActiveRecord slučuje práci objektů a databáze. Mapuje třídy podle jména na databázové tabulky. Jednotlivé instance dané třídy reprezentují konkrétní záznamy, tedy řádky. Objekty jsou mezi sebou provázány a kopírují tak vztahy tabulek, které jsou odkazované cizími klíči. Představme si následující situaci. Databáze obsahuje tabulku filmů a filmových žánrů. SQL schéma pro vytvoření by mohlo vypadat jako v příkladu CREATE TABLE 'categories' ( ^iď int(10) unsigned NOT NULL auto_increment, 'name' varchar(40) NOT NULL, PRIMARY KEY (, id, )>; CREATE TABLE 'films' ( ^iď int (10) unsigned NOT NULL auto_increment, 'name' varchar(40) NOT NULL, 'category^d' int (10) unsigned NOT NULL,, created_at' 1 timestamp NOT NULL, PRIMARY KEY ('id')); Příklad 2.4.1: SQL schéma tabulek filmů a filmových žánrů Z příkladu je vidět, že obě tabulky jsou svázány l:m vztahem a sice, že každý film patří do právě jedné kategorie (id kategorie obsahuje sloupec category_id). Naproti tomu kategorie může obsahovat několik filmů. Nyní se podívejme, jak je daný příklad zaznamenán v Ruby on Rails. Každý model má vlastní soubor v adresáři app/models. Framework se snaží přiblížit přirozenému jazyku a proto jsou odpovídající názvy někde v čísle jednotném, někde v čísle množném. Jak je vidět na příkladech a 2.4.3, obě třídy mají za předka ActiveRecord. Pomocí metody has_many respektive belongs_to je nastaven vztah mezi objekty. Ruby on Rails předpokládají, že tabulka films obsahuje sloupec category_id, který udává id kategorie. Toto standardní chování se sice dá změnit, nicméně, většinou k tomu není sebemenší důvod. class Category < ActiveRecord::Base has_many :films Příklad 2.4.2: app/models/categoryrb class Film < ActiveRecord::Base belongs_to :category Příklad 2.4.3: app/models/film.rb 7

13 2.4. ZÁKLADNÍ KOMPONENTY Nyní máme v kontroléru dostupné dvě třídy Film a Category, jejichž třídní metody nebo instance můžeme používat ke změnám stavu databáze. Mezi často používané třídní metody patří find. Pomocí ní z tabulky přiřazené modelu vybíráme konkrétní řádky, které jsou reprezentovány jednotlivými instancemi. ActionController ActionController je jádrem zpracování internetového požadavku. Obyčejně jsou kontroléry složeny z několika veřejných metod, které nazýváme akce. Tyto akce odpovídají akcím v url, na které se klient snaží připojit. Při příchozím požadavku je url typicky rozpracováno na jednotlivé části. Například říká, že klient požaduje zavolání metody list kontroléru films. Kontrolér films se v takovém případě hledá v souboru app/controllers/films_controller.rb. Jak kontrolér vypadá ilustruje příklad Tento kontrolér má dvě akce. První z nich se jmenuje index a je volána, pokud není v url parametr akce přítomen. Jedinou její funkcí je zavolat akci list a potom přepnout na zobrazení té samé akce. Druhou metodou je list, která je o něco zajímavější. Ta do instanční proměnné films uloží kolekci všech filmů, které jsou v databázi. Docílí toho tak, že zavolá metodu find objektu Film a předá jí parametr :all. Metoda find s parametrem :all vždy vrací pole obsahující instance třídy, jejíž metoda byla volána. Úkolem akce list tedy je připravit data, která budou později zobrazena. Po skončení akce list se automaticky zavolá stejnojmenný pohled. Tomu jsme v akci index zabránili a vynutili jsme zobrazení pohledu pro akci list. class FilmsController < ApplicationController def index list rer :action => 'list' def list gfilms = Film.find :all Příklad 2.4.4: app/controllers/films_controller.rb V kontroléru je možné pracovat s modely, a to, jak je z databáze číst, tak je také aktualizovat, ukládat či mazat. K tomu slouží metody update, save a destroy. Stejně tak lze vytvořit nový záznam v databázi. Stačí pouze vytvořit novou instanci modelu, nastavit jí potřebné atributy a zavolat její metodu save. Vytvoření nové kategorie by mohlo vypadat podobně, jak to ukazuje příklad Tato akce nejprve vytvoří novou instanci třídy Category a konstruktem předá tzv. hash s inicializačními hodnotami. Hash je v podstatě asociované pole. Jako klíče mohou být použity řetězce nebo symboly. 8

14 def create Ocategory = Category.new(:name => 'nová Příklad 2.4.5: vytvoření nové kategorie v databázi 2.4. ZÁKLADNÍ KOMPONENTY Kontrolér tedy může změnit stav databáze, načíst potřebné údaje a potom předá slovo pohledu. ActionView ActionView poskytuje základnu pro zpracování výstupu aplikace. Je v něm možné přistupovat na instanční proměnné kontroléru. Kód pohledu se píše pomocí ERb, což je kombinace xhtml a Ruby. V podstatě při generování nahradí Ruby procesor vlastní kód jeho výsledkem a vrátí již zcela čistou internetovou stránku. Velmi často mívá každá akce kontroléru vlastní pohled. V tomto pohledu už by se neměl měnit stav databáze, stále je však možné z ní získávat dodatečné informace. Pohled pro akci list ukazuje příklad <hl>seznam filmů</hl> <table> <tr> <th>název</th> </tr> <% for film in gfilms %> <tr> <tdx%=h film.name %></td> <td><%= link_to 'Editovat', :action => 'edit', :id => film.id %></td> <td><%= link_to 'Smazat', { :action => 'destroy', :id => film.id }, :confirm => 'Opravu?', :method => :post %></td> </tr> <% %> </table> <%= link_to 'New film', :action => 'new' %> Příklad 2.4.6: pohled kontroléru films akce list V příkladu je vidět, jak vypadá ERb v praxi. Vše co je mezi značkami <% a %> je interpretováno jako příkazy jazyka Ruby. Vidíme tedy, že nejprve je na stránce nadpis, záhlaví tabulky a následuje cyklus, ve kterém se vypisují řádky tabulky, obsahující jednotlivé filmy Cyklus zavádí lokální proměnnou film, kterou iteruje pole films, což je instanční proměnná kontroléru. Všimněte si, že v cyklu se pak volá metoda name proměnné film, která vrací 9

15 2.4. ZÁKLADNÍ KOMPONENTY hodnotu z tabulky v databázi. ActiveRecord se sám postaral o vytvoření tzv. attr_accessorů, které slouží pro přístup a případně pro změnu atributů. Pokud bychom například chtěli jméno změnit na jiný řetězec, slouží k tomu metoda name=, tedy použili bychom příkaz film.name= 'nový název'. Dále si v příkladu můžeme všimnout helperu v podobě link_to, který tvoří odkaz na url, obsahující parametry zadané pomocí hashe. Odkaz na mazání ukazuje pokročilá nastavení tohoto helperu. Tento pohled není kompletní internetová stránka, neboť neobsahuje všechny potřebné značky. V praxi se totiž používají tzv. layouty, které jsou sdílené pro celé kontroléry. Ty obsahují hlavičku stránky a většinou i její konec. Layout si můžeme představit jako obal kolem každého pohledu daného kontroléru. Pokud chceme layout použít, pak jej pouze v kontroléru zapneme, jak to ukazuje příklad Layout se hledá v adresáři app/views/layouts/. Jak může vypadat layout ukazuje příklad class FilmsController layout 'standard' < ApplicationController Příklad 2.4.7: kontrolér films s layoutem <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" xml:lang="en" lang="en"> <head> <meta http-equiv="content-type" content="text/html;charset=utf-8" /> <title>filmy: <%= controller.action_name %></title> <%= stylesheet_link_tag 'css_style' %> </head> <body> <%= yield %> </body> </html> Příklad 2.4.8: layout app/views/layouts/standard.rhtml Layouty se taktéž píší pomocí ERb. Od pohledů se liší pouze místem <%= yield %>, které označuje obsah obalené stránky. Za povšimnutí stojí objekt controller, který reprezentuje aktuální kontrolér a dále helper stylesheet_link_tag, který připojuje stránce stylový css soubor. 10

16 2.5. SPRÁVA DATABÁZE A BĚHOVÉ PROSTŘEDÍ APLIKACE 2.5 Správa databáze a běhové prostředí aplikace Autoři frameworku Ruby on Rails si uvědomili, že se během životního cyklu aplikace mění její databázové schéma. Většina programátorů používá při psaní kódu nějaké pomocné verzovací nástroje. Na databázi se však nevztahují a pokud ano, pak jen v omezené míře a nelze se mezi jednotlivými verzemi přepínat. Z toho důvodu byly zavedeny tzv. migrace. K jejich popisu je třeba vědět, jak se pracuje s databází. To nám osvětlí následující text. Běhová prostředí Každá nová aplikace má přednastavené tři druhy běhového prostředí. Tyto druhy kopírují životní cyklus od vývoje až po nasazení v ostrém provozu. Každé prostředí by mělo mít vlastní databázi. Čerstvě vytvořená aplikace má přednastavené běhové prostředí development, tedy vývoj. Takto je aplikace nastavena po celou dobu vývoje a dovoluje nám tím kontrolovat všechny výjimky, které jsou vyhozeny v našem kódu. Během vývoje je též vhodné psát testy, pro které je připraveno jiné prostředí s názvem test Jedná se o prostředí, které se používá pouze při kontrole zdrojového kódu. Testování v Ruby on Rails je však nad rámec této práce. Ve chvíli, kdy je aplikace nasazena do ostrého provozu, přepne se do prostředí production. Pokud při běhu dojde k nějaké chybě a je vyhozena výjimka, aplikace ji nezobrazí a vypíše pouze konfigurovatelné hlášení, která klienta informuje o tom, že server má potíže. To je dobré zejména kvůli bezpečnosti. Pokud by potenciální útočník viděl úryvky zdrojového kódu, mohl by je v budoucnu uplatnit při průniku do systému. Běhová prostředí můžeme definovat i vlastní. Jejich konfigurační soubory jsou k nalezení v adresáři config/environments. Je možné si nadefinovat vlastní pravidla pro zaznamenávání informací, hlášení chyb či použití poštovního modulu. Jaké běhové prostředí se zrovna pro aplikaci používá je uloženo v souboru config/environment.rb. V praxi se však použité prostředí nastavuje na vyšší úrovni a sice na webovém serveru, na němž aplikace běží. Dále je v tomto souboru možné přenastavit výchozí chování Ruby on Rails, tedy například vypnout překlady mezi jednotným a množným číslem pojmenování objektů a podobně. Nastavení databáze Jak již bylo řečeno, každé prostředí by mělo mít vlastní databázi. Ta se však nenastavuje přímo v konfiguračních souborech jednotlivých prostředí, ale v jednom centrálním souboru. Nalezneme jej v config/database.yml. Přípona yml říká, že se jedná o soubor ve formátu YAML. Zkratka YAML stojí za slovy "YAML Ain't Markup Language". Nejedná se tedy o značkovací formát, ale o prostý text formátovaný bílými znaky. Je tedy třeba dodržovat přesné odsazení pomocí mezer. Programátoři Ruby často používají soubory ve formátu YAML, neboť se domnívají, že xml formáty jsou zbytečně složité a obsahují mnoho nepotřebných údajů. Kolik textu je třeba na popsání konfigurace databáze, je možno vidět na příkladu Více je o tomto formátu k nalezení na internetových stránkách 1 autorů. 1. < 11

17 development: adapter: mysql host: database.server.cz username: nejake_jmeno password: nejake_heslo database: database_development test: adapter: mysql host: database.server.cz username: nejake_jmeno password: nejake_heslo database: database_test production: adapter: mysql host: database.server.cz username: nejake_jmeno password: nejake_heslo database: database_production 2.5. SPRÁVA DATABÁZE A BĚHOVÉ PROSTŘEDÍ APLIKACE Příklad 2.5.1: konfigurační soubor config/database.yml Každé běhové prostředí může mít zcela jiné parametry. Není tedy problém například vývojové prostředí provozovat nad databází MySQL a ostrý provoz nad PostgreSQL. Databázová vrstva je naprosto oddělená, a protože se místo SQL dotazů používají modely, můžeme kdykoliv databázový adaptér vyměnit. Ruby on Rails momentálně podporuje databáze MySQL, PostgreSQL, SQLite, SQL Server, IBM DB2, Informix a Oracle. Stále se však pracuje na nových ovladačích. Migrace Nyní se konečně můžeme věnovat migracím. Jak již bylo zmíněno, verzování databázového schéma je problém. Pokud například ukládáme SQL skript, který obsahuje strukturu, může se lišit mezi jednotlivými databázemi například v datových typech. Pokud by jste na jiné databázi chtěli schéma vytvořit, bylo by třeba skript upravit. Další problém nastane, pokud se rozhodnete změnu vrátit. Obyčejně je třeba vymazat všechny tabulky a vše znovu vytvořit. To s sebou nese nepříjemnosti v podobě ztráty dat, jejich zálohy a následné obnovy a tak dále. Migrace jsou univerzálním řešením. Jednotlivé migrační soubory popisují změny, které se v databázi mají provést. Díky tomu, že migrace také využívají ActiveRecord, odpadá problém přenositelnosti mezi různými databázovými servery. Nejlépe asi vše vysvětlí příklad Soubor s migrací obsahuje jednu třídu, která má dvě metody - up a down. V metodě 12

18 2.5. SPRÁVA DATABÁZE A BĚHOVÉ PROSTŘEDÍ APLIKACE class InitialSchema < ActiveRecord::Migration def self.up create_table "films" do t t.column "name", :string, :limit => 40, t.column "created_at", :datetime, :null create_table "categories" do t t.column "name", :string, :limit => 40, def self.down drop table :films drop table :categories :null => false => false :null => false Příklad 2.5.2: db/migrate/001_initial_schema.rb up je umístěn kód, který se vykoná, pokud databázi aktualizujeme na tuto verzi. V metodě down se naopak nalézá kód, který je použit, pokud se vracíme z této migrace na nižší verzi. Up tedy vytvoří dvě tabulky (films a categories), zatímco down je vymaže. Spuštěním příkazu rake migrate se spustí aktualizační proces. Zjistí se aktuální verze schéma databáze a pokud existují novější soubory s migracemi, provede se kód, který je v nich obsažen. Jak je vidět na příkladu, tabulkám jsme v migraci nepřidávali sloupec id. O ten se postarají samotné Ruby on Rails. Nyní se podívejme na to, jak přidat vztah mezi tabulkami. Vytvoříme k tomu nový soubor migrace. Jeho obsah znázorňuje příklad class AddRelation < ActiveRecord::Migration def self.up add_column :films, :category_id, :integer def self.down remove_column :films, :category_id Příklad 2.5.3: db/migrate/002_add_relation.rb V příkladu je vidět, že do tabulky films přidáváme sloupec category_id, který je číselný. Pokud bychom se od této migrace chtěli vrátit o verzi níž, metoda down smaže sloupec category_id. V migracích můžeme využívat všechny modely a jejich metody. Bylo by tedy možné například všem filmům zadat výchozí kategorii. Na to stačí pouze metoda Film.update_all, které bychom předali parametry, jaký sloupec se má upravit a hodnoty, 13

19 2.5. SPRÁVA DATABÁZE A BĚHOVÉ PROSTŘEDÍ APLIKACE které má použít. Občas však není vyhnutí a je třeba použít přímo SQL kód (například pokud nastavujeme cizí klíče, nebo měníme vlastnosti sloupců). K tomu slouží metoda execute, jíž jako parametr předáme string obsahující SQL kód. Je dobré se tomuto způsobu vyhýbat, pokud to jde, nicméně v některých případech to možné není. Pokud se chceme přepnout na konkrétní verzi databázového schéma, použijeme k tomu opět příkaz rake, tentokrát s parametrem verze. Příkaz pro migraci na verzi 1 vypadá takto: rake migrate VERSION=l. Rake projde všechny migrace v pořadí od aktuální verze sestupně a zavolá jejich metody down. Aktuální verze schéma je uložena přímo v databázi ve speciální tabulce schema_info. Tu si rake udržuje sám při každém procesu migrace. Více informací můžeme o frameworku Ruby on Rails nalézt v knize: Agile Web Development with Rails [6] 14

20 Kapitola 3 Implementace konkrétního systému V následující kapitole se budeme věnovat implementaci konkrétního systému. Jedná se o webovou aplikaci vytvořenou pro korespondenční semináře. Nejprve shrneme, jaké požadavky stanovili zadavatelé. Poté rozvrhneme modely tak, aby vyjadřovaly stavy aplikace. Následně popíšeme, jak rozdělit funkcionalitu do jednotlivých kontrolérů. Dále vyřešíme autentizaci uživatelů a následnou autorizaci. Na závěr popíšeme řešení některých zvláštních funkcí systému, jako je lokalizace chybových hlášení do českého jazyka nebo rozesílání elektronické pošty. Jak celá aplikace vypadá a jak funguje je vidět na adrese <http: //ks.muni.cz> 3.1 Požadavky systému pro korespondenční semináře Před začátkem jakékoliv práce je třeba provést analýzu, kterou zjistíme, co zadavatel od systému přesně očekává. Je třeba zjistit, jaké jsou předpokládané hlavní funkce aplikace, zda je třeba rozlišovat přístupová práva mezi jednotlivými uživateli a případné nápady a návrhy na zlepšení do budoucí verze. Nyní si popíšeme základní body, které jsme zjistili od zadavatele. Stěžejní funkce systému Nejprve si uvedeme základní požadované funkce. Jedná se o nástin toho, co systém musí umožňovat. Detailněji jsou položky rozebrány později. Jednoduché přidávání novinek a článků. Zadávání sad příkladů Zobrazení výsledkové listiny řešitelů Diskuze všech uživatelů Registrace nových řešitelů Řešitelé smí odevzdávat příklady elektronicky Opravující smí příklady opravovat a zadávat bodové ohodnocení 15

21 Systém by měl umožňovat pracovat s více semináři 3.2. VZTAHY A ROLE MODELŮ Jak je ze seznamu vidět, musíme implementovat malý redakční systém. Dále je zapotřebí, aby se k systému mohli uživatelé přihlašovat a bude třeba i rozdělit jejich pravomoci, podle toho, zda se jedná o řešitele či opravujícího. Systém musí být navržen tak, aby nebyl problém přidávat či odebírat nějaký seminář. Nyní je na řadě tvorba databázového schématu dle dosavadních poznatků. To popíšeme rozložením modelů a jejich konfigurací. 3.2 Vztahy a role modelů Abecedně si seřadíme a popíšeme všechny modely, které naše aplikace využívá. Uvedeme také vzájemné vztahy. V modelech nejsou uvedeny úplně všechny vztahy, nebo jsou uvedeny pouze jednostranně. Je to z toho důvodu, že pokud bychom se ptali na svázané údaje pomocí metod modelů, mohlo by dojít k výrazně neefektivním dotazům. Proto jsou některé vazby zakázány a na místech, kde by k náročným dotazům docházelo, jsou použity fragmenty sql kódu, který řeší daný problém efektivněji. Ve výpisu modelů též neuvádím některé modely, které nejsou důležité pro fungování aplikace. Model Article soubor funkce vztahy důležité atributy poznámka app/models/article.rb zastupuje články has_many :discussion_positions :name, :preface, :text článek se dědí z objektu Discussion (viz níže) Model Article představuje objekty článků. Každý má svůj název, předmluvu a samotný text. Všechny tyto atributy jsou před uložením kontrolovány. Pokud by kterýkoliv z nich byl prázdný, uložení by se nezdařilo. Pro ilustraci, jak se v modelu validace provádí viz. příklad Model Article se nedědí přímo z ActiveRecord::Base, jak tomu obyčejně bývá, ale z modelu Discussion, což je model diskuze. Article je tím pádem vázán na tabulku discussions, nicméně systém jej chápe jako objekt článku. V databázi je tím pádem jediná tabulka obsahující jak články, tak diskuze a Ruby on Rails tyto dva druhy rozlišují podle speciálního sloupce, který se jmenuje class. Podobně jsou řešeny i jiné modely, jako je například novinka. Je to z toho důvodu, že struktura novinky je v podstatě stejná jako struktura článku a nemá smysl mít tedy dvě různé tabulky. Další výhodou je, že takto poděděné objekty získají všechny metody, které obsahuje model Discussion. Ten tedy obsahuje společné metody, například pro počet diskuzních příspěvků, které jsou vázány na konkrétní článek. 16

22 3.2. VZTAHY A ROLE MODELŮ # následující 3 řádky zaručují neprázdnost validates_presence_of :name, :message => 'Název - nesmí být prázdný' validates_presence_of :preface, :message => 'Úvod - nesmí být prázdný' validates_presence_of :text, :message => 'Text - nesmí být prázdný' # dále prověříme délku, avšak pouze pokud vůbec byl nějaký obsah zadán validates_length_of :name, :maximum => 255, :too_long => 'Název - nesmí být delší než 255 znaků', :if => Proc.new{ article!article.name.blank? } validates_length_of :preface, :maximum => 65535, :too_long => 'Úvod - nesmí být delší než znaků', :if => Proc.new{ article!article.preface.blank? } validates_length_of :text, :maximum => 65535, :too_long => 'Text - nesmí být delší než znaků', :if => Proc.new{ article!article.text.blank? } Příklad 3.2.1: validace článku před uložením Model Contribution soubor funkce vztahy důležité atributy poznámka app /models /contribution.rb zastupuje příspěvky v diskuzích belongs_to :person belongs_to :discussion belongs_to :super_parent has_many :all_children has_and_belongs_to_many :watchmen :name, :text, :created_at obsahuje metody pro rekurzivní počítání příspěvků Model Contribution reprezentuje jednotlivé příspěvky v diskuzích. Dalo by se říct, že diskuze jsou všechny novinky, články, sady příkladů, příklady, řešení a samotné diskuze. Na každý z těchto objektů je možné navázat příspěvky. Je to z toho důvodu, že diskutovat lze o všem. Příspěvky jsou vázány dále na osoby. Tento vztah určuje, kdo příspěvek vytvořil. Zároveň jsou příspěvky organizovány do stromu. Tato struktura umožňuje rozpoznat, na který konkrétní záznam bylo odpovídáno. Razení do stromu provádí metoda acts_as_tree, která modelu přidefinuje metody jako například children, která vrací seznam všech potomků daného uzlu. Vztah s modelem Watchmen je ve tvaru m:n. Watchmen je model, který počítá nepřečtené příspěvky jednotlivým uživatelům pro všechny diskuze. 17

23 3.2. VZTAHY A ROLE MODELŮ Model DBLog soubor funkce vztahy důležité atributy poznámka app/models/db_log.rb skrze něj se zapisují informace o uživatelích belongs_to :person belongs_to :seminar belongs_to :year :ip, :org DBLog se používá k zaznamenávání statistik o prohlížení stránek. V podstatě se při každém vykreslení libovolné stránky uloží odkaz na přihlášenou osobu, aktuální seminář a ročník. Dále se ukládá IP adresa a příznak, zda je přihlášená osoba organizátorem. Model DiscussionPosition soubor funkce vztahy důležité atributy poznámka app/models/discussion_position.rb mezistupeň, který určuje pořadí diskuzí pro jednotlivé semináře a ročníky belongs_to : discussion belongs_to : seminar belongs_to :year Je třeba mít různé pořadí všech diskutabilních věcí pro různé semináře. Systém obsahuje například možnost sdílet články mezi semináři a proto je třeba, aby se články neřadily pouze podle data. Jinak by se mohlo stát, že nejnovější a nejdůležitější článek pro daný seminář bude odsunut nověji vytvořenými méně závažnými sdílenými články. Model Discussion soubor funkce vztahy důležité atributy poznámka app/models/discussion.rb zastává obecnou diskuzi belongs_to : seminar belongs_to :year belongs_to :person has_many :watchmen has_many contributions has_many :stored_files has_many :images has_many :discussion_positions :name je předkem pro další diskutabilní objekty 18

24 3.2. VZTAHY A ROLE MODELŮ Discussion představuje diskuzi, která není k ničemu navázaná. Diskuze obsahuje několik příspěvků, které jsou řazeny do stromu a vznikají tak diskuzní vlákna. Samotný model Discussion tvoří kořenový příspěvek všech vláken na něj navázaných. Každá diskuze uchovává odkaz na uživatele, který diskuzi vytvořil. Discussion je předkem pro další objekty, u kterých je možné diskutovat. Jako kořenový příspěvek takto může sloužit článek, novinka, sada příkladů, příklad a řešení. Je žádoucí aby každá takováto diskuze obsahovala obrázky. Proto má diskuze vztah l:m s tabulkou obrázků. Ze stejného důvodu je Discussion vázán na soubory. Model Example soubor funkce vztahy důležité atributy poznámka app/models/example.rb představuje jednotlivé příklady belongs_to :pack has_many solutions :name, :points příklad se dědí z objektu Discussion Příklad obsahuje pouze název a maximální bodové ohodnocení. Samotné zadání je v souboru, který je připojen k sadě příkladů. Na model Example jsou navázána řešení, která vytváří řešitelé. Celý postup odevzdání je podrobněji popsán u modelu řešení. Model Image soubor funkce vztahy důležité atributy poznámka app/models/image.rb zastupuje obrázky nahrané v systému belongs_to : discussion belongs_to :person :name obrázky jsou fyzicky uloženy v adresáři public/images/ Obrázky mají v databázi uloženo pouze jméno. Podle něj se daný obrázek dohledá ve správné cestě na disku. Jedná se o soubory, které by měly být veřejně dostupné, a proto se nacházejí v adresáři public. Model IndividualSolver soubor funkce vztahy důležité atributy poznámka app /models / individual_solver. rb je zástupcem řešitele jednotlivce belongs_to :person :org je potomkem třídy Solver, nedědí tedy přímo z ActiveRecord::Base Některé semináře vyžadují řešitele v podobě jednotlivce, jiné zase v podobě několikačlenného týmu. IndividualSolver představuje jednotlivce. Je vázán na osobu, tedy na uživa- 19

25 telský účet. Atribut org udává, zda se jedná o adminitrátora či nikoliv VZTAHY A ROLE MODELŮ Model News soubor funkce vztahy důležité atributy poznámka app/models/news.rb zprostředkovává tabulku s novinkami :name, :text, :org novinka se dědí z objektu Discussion Novinka je tedy dalším druhem diskuze. Tu však není třeba řadit různě pro jednotlivé semináře, a proto nemá vztah s DiscussionPosition. Novinka se užívá k oznámení nějaké důležité zprávy jak řešitelům, tak administrátorům. Pomocí atributu org lze nastavit, zda je novinka určena pouze pro adminitrátory či pro všechny. Model Pack soubor funkce vztahy důležité atributy poznámka app/models/pack.rb představuje sadu příkladů has_many :examples :name, :preface, :text, :placed_at, :deadline_at, :corrected_at, :closed_at sada se dědí z objektu Discussion Sada příkladů reprezentuje skupinu příkladů, které se zveřejňují řešitelům. Sada s sebou nese 4 důležitá data, a sice datum vystavení (placed_at), datum odevzdání (deadline_at), datum opravení (corrected_at) a datum uzavření (closed_at). Datum vystavení podává informaci o tom, kdy bude sada oficiálně zveřejněna. Pokud je tento údaj v budoucnosti, sada se zobrazuje pouze administrátorům, kteří ji mohou stále upravovat. Po vypršení data zveřejnění již systém před každou úpravou varuje, že sadu vidí řešitelé. Datum odevzdání představuje časovou hranici, do kdy je možné řešení elektronicky odevzdávat. Po vypršení již není možné žádné řešení do systému nahrát. Datum opravení informuje řešitele o tom, kdy bude celá sada nejpozději opravena a kdy se započítá do celoročního hodnocení. Mezi daty opravení a uzavření je období, kdy si řešitelé mohou své opravené příklady prohlédnout a případně vznášet protesty. Po uplynutí data uzavření již není možné měnit bodové ohodnocení libovolného řešení. Všechna tato data jsou při ukládání kontrolována. Musí odpovídat časové souslednosti ve vyjmenovaném pořadí, tj. například datum odevzdání nepředchází datu vystavení. Nemusí být vyplněny všechny, ale opět platí podmínka, že pokud je vyplněno nějaké datum, pak jsou vyplněna i všechna data předchozí. 20

26 3.2. VZTAHY A ROLE MODELŮ Model Person soubor funkce vztahy důležité atributy poznámka app/models/person.rb reprezentuje uživatele belongs_to :school has_many :individual_solvers has_many contributions has_many :watchmen has_many :stored_files has_many :images has_many: discussions has_and_belongs_to_many :teams :login, :hashed_password, : Tento model zastupuje uživatelský účet. Při registraci si uživatel volí přihlašovací jméno (login) a heslo. Při ukládání se kontroluje unikátnost loginu a délka hesla. Dále každý účet musí obsahovat , jméno, příjmení a rok maturity. Heslo se v databázi ukládá ve formě hashe, který je počítán funkcí shal. Jak je vidět ze vztahů, osoba patří do nějaké školy. Dále může patřit do některého z týmu nebo být jednotlivým řešitelem (nebo obojí). Dále má každý uživatel hlídače nových příspěvků (watchmen), může vkládat příspěvky, zakládat diskuze a případně i nahrávat obrázky a přílohy (stored_files). Model Seminar soubor funkce vztahy důležité atributy poznámka app/models/seminar.rb zprostředkovává jednotlivé semináře belongs_to :year has_many: solvers has_many :seminar_informations has_many :seminar_links :name, :shortcut, :type Seminář je základem celé aplikace. Důležitým atributem je type, který říká, zda se jedná o seminář, který je řešen v týmech či jednotlivci. Nad seminářem jsou v podstatě už jen ročníky. Každý seminář může mít několik řešitelů (a tedy buď týmů nebo jednotlivců). Další dva vztahy jsou vazby na modely, které jsem neuvedl, neboť nejsou nijak významné. Jedná se o vazbu na článek popisující daný seminář a na odkazy, které danému semináři přísluší. 21

27 3.2. VZTAHY A ROLE MODELŮ Model School soubor funkce vztahy důležité atributy poznámka app/models/school.rb číselník všech středních škol has_many :people :name Jedná se o číselník všech škol, které jsou systému známy. Při registraci uživatele se z nich vybírá. Číselník obsahuje jednu pseudoškolu, kterou si uživatel vybere, pokud navštěvuje takovou školu, která není v seznamu. Dále je požádán o kontaktování některého z administrátorů, aby školu přidal. Model Solution soubor funkce vztahy důležité atributy poznámka app/models/solution.rb odpovídá řešením belongs_to : example belongs_to : solver :points řešení se dědí z objektu Discussion Model Solution představuje jednotlivá řešení. Řešení může nabývat stavů neodevzdáno, odevzdáno a opraveno. Každé opravené řešení má přidělen počet bodů od opravujícího. Elektronické odevzdávání příkladů spočívá ve vytvoření nového, neodevzdaného řešení, následného nahrání souborů a odevzdání (tj. nastavení stavu na odevzdáno). Do odevzdaných řešení již řešitel nemůže zasahovat. Model Solver soubor funkce vztahy důležité atributy poznámka app/models/solver.rb reprezentuje řešitele belongs_to : seminar belongs_to :year has_many: discussions předek IndividualSolver a TeamSolver Tento model je mezivrstvou mezi seminářem a uživateli. Zároveň vytváří jednotné rozhraní na práci s řešitelem, ať už se jedná o tým nebo o jednotlivce. 22

28 3.2. VZTAHY A ROLE MODELŮ Model StoredFile soubor funkce vztahy důležité atributy poznámka app/models/stored_file.rb zpřístupňuje všechny uložené soubory belongs_to :person belongs_to :discussion :name soubory se ukládají do stored_files/ Soubory přiložené k diskuzím (například řešení nebo přílohy) se ukládají mimo veřejný adresář public. V databázi se ukládá jejich jméno a typ, nicméně na harddisku jsou uloženy pod jménem složeného z id v databázi a přípony posted. Při stahovaní se vynutí název souboru a tzv content type podle údajů v databázi. Model Team soubor funkce vztahy důležité atributy poznámka app/models/team.rb odpovídá týmu has_many :team_solvers has_and_belongs_to_many :people :name, :password Týmy jsou skupiny lidí, kteří řeší týmový seminář. Tým nejprve někdo založí a nastaví mu heslo. Automaticky se tím stává jeho členem. Další uživatelé se do týmu mohou přihlásit, pokud již nejsou členy nějakého jiného týmu a pokud znají heslo. Všichni v týmu mají stejná privilegia a není nikde zaznamenáno, kdo tým vytvořil. Model TeamSolver soubor funkce vztahy důležité atributy poznámka app/models/team_solver.rb je zástupcem řešitelského týmu belongs_to :team :org je potomkem třídy Solver, nedědí tedy přímo z ActiveRecord::Base TeamSolver představuje řešitele v podobě týmu. Je vázán na tým, který reprezentuje. Atribut org udává, zda se jedná o tým adminitrátorů či nikoliv. 23

29 3.3. KONTROLÉRY Model Watchmen soubor funkce vztahy důležité atributy poznámka app/models/watchmen.rb podává informace o nepřečtených příspěvcích belongs_to :person belongs_to : discussion has_and_belongs_to_many contributions jedná se o tabulku vazeb Watchmen pouze stanovuje vazby mezi diskuzí a uživatelem. Tyto vazby uchovávají informace o tom, kdo sleduje jaké diskuze. Systém umožňuje vypnout sledování diskuze a uživatel pak není upozorňován na nové příspěvky. Model Year soubor funkce vztahy důležité atributy poznámka app/models/year.rb reprezentuje ročník semináře has_many :seminar_informations :start_year Model Year představuje jednotlivé ročníky každého semináře. Obsahuje atribut start_year, který udává počáteční rok ročníku. V praxi totiž ročník často postihuje dva roky. Databázové schéma Zjednodušeně vše graficky znázorňuje databázové schéma na obrázku 3.1. Zde jsou zobrazeny pouze tabulky a jejich vztahy. Nejsou tedy například rozlišeny články od novinek, které jsou společně uloženy v tabulce discussions. 3.3 Kontroléry Nyní si stručně popíšeme funkce jednotlivých kontrolérů. Většina z nich obsahuje tzv. CRUD operace. CRUD je zkratka anglického sousloví Create-Read-Update-Delete, která vyjadřuje základní operace s daty. Zahrnuje tedy vytváření nových údajů, jejich zpětné vyvolání, úpravu a mazání. Následující tabulka shrnuje nejdůležitější funkce kontrolérů. V levém sloupečku se nachází název třídy daného kontroléru, v pravém pak funkce. 24

30 3.3. KONTROLÉRY ArticlesController ContributionsController DiscussionsController ExamplesController ImagesController MyLinksController NewsController PacksController PeopleController Seminar InformationsController Seminar LinksController SeminarsController SchoolsController SolversController StoredFilesController TeamsController WatchmenController YearsController CRUD operace s články řazení článků ve frontě CRUD operace s příspěvky výpis vlákna příspěvků CRUD operace s diskuzemi CRUD operace s příklady řazení příkladů v rámci sady uložení přijatého obrázku a záznam do databáze mazání obrázků CRUD operace s týmy nastavení uživatelského účtu přihlašování/odhlašování do/z týmu registrace řešitelů, výpis řešení výpis řešitelů systémové nástroje pro administrátory rozesílání ů CRUD operace s novinkami CRUD operace se sadami řazení sad ve frontě výsledková listina CRUD operace s uživateli přihlášení do systému přiřazení speciálních článků jako informací o semináři CRUD operace se specifickými odkazy semináře CRUD operace se semináři založení nového řešení označení za odevzdané či opravené hromadné nástroje pro opravu nástroje pro neelektronické odevzdání řešení úpravy řešitelů - přidání administrátorských privilegií uložení přijatého souboru a záznam do databáze úpravy souborů stahování vybraného souboru zobrazení detailu o týmu smazání týmu zapínání/vypínání sledování diskuzí CRUD operace s ročníky 25

31 3.4. AUTENTIZACE A AUTORIZACE 3.4 Autentizace a autorizace Jak již bylo výše nastíněno, systém musí rozlišovat mezi jednotlivými uživateli a přidělovat jim různá práva. Všechny návštěvníky rozdělíme do čtyř skupin. Tyto skupiny jsou uspořádány dle oprávnění, tedy vyšší skupina má vždy všechna práva skupin nižších. Rozdělení do skupin První skupinou je veřejnost, která se může koukat pouze na veřejné stránky. Nesmí přidávat příspěvky, ani odevzdávat řešení. V podstatě se smí pouze dívat na novinky, články, zadání příkladů, diskuze o nich a na výsledkovou listinu. Veřejnost jsou všichni návštěvníci, kteří nemají uživatelský účet. Pokud se zaregistrují, stávají se z nich uživatelé. Uživatel je součástí systému a může tedy pod svým uživatelským účtem vkládat diskuzní příspěvky. Uživatel není vázán na žádný seminář, takže není třeba mít pro každý seminář vlastní uživatelský účet. Pokud se uživatel rozhodne řešit nějaký korespondenční seminář, může se označit za řešitele. Řešitel naopak na seminář vázán je, a tedy pokud chce uživatel řešit více seminářů, musí se označit za řešitele pro každého z nich. Řešitel smí odevzdávat příklady. Díky tomu se ocitá na výsledkové listině, na které se zobrazuje jeho bodové hodnocení za jednotlivé příklady. Řešiteli se také umožní přistupovat do soukromé diskuze mezi ním a opravujícím u každého příkladu. Poslední skupinou lidí jsou administrátoři. Administrátorem se může stát řešitel, pokud jej jiný administrátor takto označí. To vynucuje předpoklad, že systém má vždy alespoň jednoho administrátora. Administrátor je osoba, která do systému vkládá novinky, články, nové sady příkladů či zakládá diskuze. V neposlední řadě také administrátor opravuje řešení a uděluje za ně bodové hodnocení. Administrátory jsou většinou všichni organizátoři korespondenčního semináře. Mezi administrátory se však práva nijak nerozlišují. Proces autentizace a autorizace Abychom byli schopni rozlišit, do které skupiny osoba patří, musíme nejprve zjistit, o jakou osobu se jedná. K tomu slouží přihlašovací formulář, pomocí nějž systém obdrží přihlašovací jméno a heslo, které použije k autentizaci. Z přijatého hesla se spočítá tzv. hash pomocí funkce SHA1. Pokud přihlašovacímu jménu v databázi odpovídá spočítaný hash, pak osoba zadala správné přihlašovací údaje a je jí povolen přístup do systému. Následuje uložení vybrané instance modelu Person do pole session, které uchovává všechny údaje o uživateli a přenáší je mezi stránkami. Autorizace se provádí při každé akci. Nejprve se zjistí, do jaké skupiny patří osoba, viz příklad Dále se pro daný kontrolér a akci zkontrolují přístupová práva, která jsou uložena v konfiguračním souboru. Tento soubor se nachází v adresáři config a nazývá se authorize.yml. Definují se v něm pravidla, které skupiny mají za jakých okolností přístup k jednotlivým akcím. V příkladu uvádím nastavení pro kontrolér článků. Každá akce má nastavené skupiny, které k ní mají přístup. Může následovat fragment kódu Ruby, který 26