Pro sdílení statického obsahu mezi různé uživatele stačí velmi jednoduchý HTTP server bez jakýchkoliv dalších modulů typu \textit{PHP}, \textit{Python} a dalších systémů, které by obsah dynamicky generovaly například z dat vytažených z databáze, nebo z uživatelského vstupu. Na straně serveru tedy nedochází ke zpracování obsahu těsně před jeho odesláním uživateli, čímž se v komunikaci mezi klientem a serverem se drasticky snižuje \uv{Time To First Byte}\footnote{Time To First Byte --- čas mezi odesláním požadavku a přijmutím prvního bajtu dat.} a tím dochází ke snížení celkové latence. \citep{mozttfb}
Pro sdílení statického obsahu mezi různé uživatele stačí velmi jednoduchý HTTP server bez jakýchkoliv dalších modulů typu \textit{PHP}, \textit{Python} a dalších systémů, které by obsah dynamicky generovaly například z dat vytažených z databáze, nebo z uživatelského vstupu. Na straně serveru tedy nedochází ke zpracování obsahu těsně před jeho odesláním uživateli, čímž se v komunikaci mezi klientem a serverem drasticky snižuje \uv{Time To First Byte}\footnote{Time To First Byte --- čas mezi odesláním požadavku a přijmutím prvního bajtu dat.} a tím dochází ke snížení celkové latence. \citep{mozttfb}
Snížení samotné latence může pozitivně přispět ke spokojenosti uživatelů, což dokazuje nespočet výzkumů na toto téma, například analýza z webového portálu Financial Times, kde se uvádí, že rychlost webové stránky negativně ovlivňuje hloubku jejího užívání, ať už je odezva sebemenší. Jak je zde rovněž uvedeno, data ukazují, že pohledu uživatelské spokojenosti a finančního dopadu existují jasné a důležité výhody při zrychlení webové stránky. Z tohoto výzkumu se autoři rozhodli v následujících měsících od vydání analýzy zainvestovat více času do úprav všech aspektů jejich nové stránky FT.com s cílem jejího zrychlení.\todo{Nechat opravit překlad}
Snížení samotné latence může pozitivně přispět ke spokojenosti uživatelů, což dokazuje nespočet výzkumů na toto téma, například analýza z webového portálu Financial Times, kde se uvádí, že rychlost webové stránky negativně ovlivňuje hloubku jejího užívání, ať už je odezva sebemenší. Jak je zde rovněž uvedeno, data ukazují, že z pohledu uživatelské spokojenosti a finančního dopadu existují jasné a důležité výhody při zrychlení webové stránky. Z tohoto výzkumu se autoři rozhodli v měsících po vydání analýzy investovat více času do úprav všech aspektů jejich nové stránky FT.com s cílem jejího zrychlení.\todo{Nechat opravit překlad}
Eliminováním dynamického obsahu se také předchází nevyžádaným vstupům od uživatele, které mohou být i cílené na prolomení bezpečnostních nedostatků webové aplikace a v některých případech mohou vést k úniku citlivých dat, převzetí kontroly útočníka nad webovou aplikací nebo celým serverem, podstrčení falešných dat uživateli a mnoho dalším běžně se stávajícím útokům. Statický web eliminuje tento problém, jelikož nemá žádný uživatelský vstup.
Eliminováním dynamického obsahu se také předchází nevyžádaným vstupům od uživatele, které mohou být i cílené na prolomení bezpečnostních nedostatků webové aplikace a v některých případech mohou vést k úniku citlivých dat, převzetí kontroly útočníka nad webovou aplikací nebo celým serverem, podstrčení falešných dat uživateli a mnoha dalším běžným útokům. Statický web eliminuje tento problém, jelikož nemá žádný uživatelský vstup.
Sledování a analýze nejčastějších chyb webových aplikací a serverů se věnuje organizace OWASP\footnote{The Open Web Application Security Project --- \url{https://owasp.org/}.}, která vydává aktualizované seznamy a statistiky. Podle OWASP byly v roce 2017 nejčastější tyto chyby a bezpečnostní nedostatky:
@ -22,25 +22,25 @@ Sledování a analýze nejčastějších chyb webových aplikací a serverů se
\item{Nefunkční řízení přístupu}
\item{Špatná konfigurace zabezpečení}
\item{Cross-Site Scripting (XSS)}
\item{Nezabezpečná deserializace}
\item{Uživání komponent se známými zranitelnostmi}
\item{Nezabezpečená deserializace}
\item{Užívání komponent se známými zranitelnostmi}
\item{Nedostatečné logování a monitorování}
\end{enumerate}
\citep{owasp2017}
Většina těchto chyb se vztahuje právě k dynamickým webovým aplikacím. Bezpečnost tedy závisí nejen na programátorovi který aplikaci vytváří, ale také na tom, že programovací jazyk je bezpečně implementován. To nelze tvrdit o nejpoužívanějším jazyce PHP, který nejen že obsahuje spousty chyb, viz seznam nalezených bezpečnostních děr \citep{cve_php}, ale zároveň nevede programátora ke psaní bezpečného kódu a ve výsledku vzniká nebezpečná aplikace, pokud si autor nedá pozor na správné ošetření vstupů a další bezpečnostní aspekty programu.
Většina těchto chyb se vztahuje právě k dynamickým webovým aplikacím. Bezpečnost tedy závisí nejen na programátorovi který aplikaci vytváří, ale také na tom, že programovací jazyk je bezpečně implementován. To nelze tvrdit o nejpoužívanějším jazyce PHP, který nejen že obsahuje mnoho chyb, viz seznam nalezených bezpečnostních děr \citep{cve_php}, ale zároveň nevede programátora k psaní bezpečného kódu, což má za následek nebezpečené aplikace, pokud si autor nedá pozor na správné ošetření vstupů a dalších bezpečnostních aspektů programu.
Skvělým příkladem chybovosti dynamických webů je systém Wordpress, ve kterém jsou každý rok nalezeny desítky bezpečnostních chyb \citep{cve_wordpress}, přičemž mnoho dalších přibývá s instalací špatně napsaných rozšíření. Například na začátku roku 2020 byla nalezena bezpečnostní chyba v rozšíření, které bylo využíváno na více než dvě stě tisících webových stránkách a potencionálním útočníkům umožnila smazat obsah databáze \citep{thehackernews_wordpress_1}. Na konci roku 2019 umožnila chyba ve dvou nezabezpečených rozšířeních neautorizované přihlášení k účtu administrátora bez použití hesla \citep{thehackernews_wordpress_2}.
Podstatným příkladem chybovosti dynamických webů je systém Wordpress, ve kterém jsou každý rok nalezeny desítky bezpečnostních chyb \citep{cve_wordpress}, přičemž mnoho dalších přibývá s instalací rozšíření, která postrádají bezpečnostní prvky. Například na začátku roku 2020 byla nalezena bezpečnostní chyba v rozšíření, které bylo využíváno na více než dvě stě tisících webových stránkách a potencionálním útočníkům umožňovala smazat obsah databáze \citep{thehackernews_wordpress_1}. Na konci roku 2019 umožnila chyba ve dvou nezabezpečených rozšířeních neautorizované přihlášení k účtu administrátora bez použití hesla \citep{thehackernews_wordpress_2}.
Údržba velkých webových aplikací je také často problematická. Kód je nutné udržovat v návaznosti na aktualizace daného jazyka, databázového systému a dalších věcí. Těmto aktualizacím se z bezpečnostních důvodů nelze vyhýbat. Statický web nemusí udržovat funkční propojení s databázemi a různými frameworky\todo{Lepši slovo?} a je tedy mnohem méně náročný na dlouhodobou údržbu. Při zvolení správného generátoru není nutná ani údržba šablon a celý systém při zachování stejného prostředí nepřestane fungovat. Protože statický generátor nepracuje s uživatelským vstupem, vyhýbá se bezpečnostním chybám a tím i nutným aktualizacím.
Údržba velkých webových aplikací je často problematická. Kód je nutné udržovat v návaznosti na aktualizace daného jazyka, databázového systému a dalších aspektů. Těmto aktualizacím se z bezpečnostních důvodů nelze vyhýbat. Statický web nemusí udržovat funkční propojení s databázemi a různými frameworky\todo{Lepši slovo?} a je tedy mnohem méně náročný na dlouhodobou údržbu. Při zvolení správného generátoru není nutná ani údržba šablon a celý systém při zachování stejného prostředí nepřestane fungovat. Protože statický generátor nepracuje s uživatelským vstupem, vyhýbá se bezpečnostním chybám a tím i nutným aktualizacím.
Jako každý jiný systém, i statické generátory mají své nevýhody. Hlavním z problémů je to, že správa statického generátoru a tvorba obsahu je náročnější, než klasické webové rozhraní s administračním panelem, různými uživateli a jednoduchou správou pro běžné technicky nenadané uživatele. Pro přidání nebo úpravu obsahu je nutné pracovat s lokálními soubory ve stromové struktuře a při generování je často potřebný zásah do shellu\footnote{Program pro interpretování příkazů v prostředí příkazové řádky.}. Tvorba systému pro automatizované generování je také náročnější než instalace některého z běžných CMS\footnote{Content Management System}. \citep{softpedia_generators}
Jako každý jiný systém, i statické generátory mají své nevýhody. Hlavním z problémů je to, že správa statického generátoru a tvorba obsahu je náročnější, než klasické webové rozhraní s administračním panelem, různými uživateli a jednoduchou správou pro běžné, méně technicky zaměřené uživatele. Pro přidání nebo úpravu obsahu je nutné pracovat s lokálními soubory ve stromové struktuře a při generování je často potřebný zásah do shellu\footnote{Program pro interpretování příkazů v prostředí příkazové řádky.}. Tvorba systému pro automatizované generování je také náročnější než instalace některého z běžných CMS\footnote{Content Management System}. \citep{softpedia_generators}
Generátor statického obsahu je tvořen ze tří hlavních částí. První částí jsou soubory šablon, které popisují rozložení stránky, vizuální vlastnosti, typografii, ale také vstupní a výstupní kódování a formáty. V podstatě definují jak a kam se bude obsah vkládat. Druhou částí je obsah obecně psaný v některém ze značkovacích jazyků, nejčastěji v jazyce Markdown. Obsah je strukturován do vlastních sekcí a souborů, aby bylo snadné rozlišit, do které části výsledné stránky patří. Třetí a poslední částí je samotné jádro generátoru, které zpracovává obsah, vkládá ho do šablon a renderuje statickou webovou stránku.
Ekosystém generátoru statického obsahu je tvořen ze tří hlavních složek. První částí jsou soubory šablon, které popisují rozložení stránky, vizuální vlastnosti, typografii, ale také vstupní a výstupní kódování a formáty. V podstatě definují jak a kam se bude obsah vkládat. Druhou částí je obsah samotný, napsaný v některém ze značkovacích jazyků, nejčastěji v jazyce Markdown. Obsah bývá strukturován do sekcí a souborů, aby bylo snadné rozlišit, do které části výsledné stránky patří. Třetí a poslední složkou je samotné jádro generátoru, které zpracovává obsah, vkládá ho do šablon a renderuje statickou webovou stránku.
Většina generátorů zároveň umí pracovat s konfiguračními soubory, kterými jde nastavit chování generátoru na jednom centralizovaném místě. Část z nich má také integrovaný jednoduchý web server, který umožňuje autorovi náhled výstupních stránek během tvorby obsahu.
Většina generátorů zároveň umí pracovat s konfiguračními soubory, kterými jde nastavit globální chování generátoru. Část z nich také integruje jednoduchý webserver, který umožňuje autorovi náhled výstupních stránek zatím co tvoří obsah.
Vysvětlení principu značkovacích jazyků, nebo také takzvaně \uv{makrup jazyků}, můžeme najít například v RFC 7764\footnote{Jako \textit{RFC} se označují standardy vydané organizací IETF (Internet Engineering Task Force).}, tedy že v počítačových systémech jsou kontextuální data ukládána a zpracována několika technikami. Informaci lze kódovat jako čistý text bez speciálních formátovacích znaků. Tento přístup je jednoduchý pro implementaci i použití, ovšem neumožňuje složitější formátování textu.
Definici konceptu značkovacích jazyků, nebo-li \uv{markup jazyků}, můžeme najít například v RFC 7764\footnote{Jako \textit{RFC} se označují standardy vydané organizací IETF (Internet Engineering Task Force).}, tedy že v počítačových systémech jsou kontextuální data ukládána a zpracována několika technikami. Informaci lze kódovat jako čistý text bez speciálních formátovacích znaků. Tento přístup je jednoduchý pro implementaci i použití, ovšem neumožňuje složitější formátování textu.
Kódovat lze můžeme i do binárních dat určených ke zpracování a interpretaci specializovaným programem. Zřejmou nevýhodou je to, že zdroj není čitelný bez programu určeného pro jeho interpretaci.
Kódovat můžeme i do binárních formátů určených ke zpracování a interpretaci specializovaným programem. Zřejmou nevýhodou je to, že zdroj není čitelný bez programu určeného pro jeho interpretaci.
Markup jazyky se snaží o spojení toho nejlepšího z obou světů, tedy o obsah čitelný v čistém textu s možností formátování. To je dosaženo tím, že běžným znakům jsou přiděleny speciální významy nedefinované původní znakovou sadou. Uživatel je schopen tyto znaky psát jako čistý text a vyjádřit tím speciální význam. Například v rámci jazyka Markdown se znak \texttt{\#} změní z běžného křížku na definování nadpisu první úrovně, nebo také kombinace znaků \texttt{<p>} značí začátek odstavce v HTML. \citep{rfc7764}
Markup jazyky se snaží o spojení nejlepšího z obou světů, tedy o obsah s možností formátování, který je jednoduše čitelný jak pro člověka, tak pro stroj. Toho je dosaženo tím, že v je v běžných textových souborech přiřezen vybraným znakům speciální význam. Uživatel je schopen tyto znaky psát bez potřeby speciálních nástrojů a tím jednoduše vyjádřit speciální význam. Například v rámci jazyka Markdown se znak \texttt{\#} změní z běžného křížku na definování nadpisu první úrovně, nebo také kombinace znaků \texttt{<p>} značí začátek odstavce v HTML. \citep{rfc7764}
\section{Nejběžnější jazyky}
Ke dnešnímu dni vnikl nespočet značkovacích jazyků. Nejpoužívanějším z nich jednoznačně HTML, ovšem tato práce se věnuje těm nejpoužívanějším jazykům, které mají uživateli usnadnit psaní a sázení obsahu. Uživatel tedy nemusí nutně řešit typografii a formátování obsahu při jeho psaní, tedy o věci, o které se později stará generátor pomocí šablon. U HTML je tomu naopak, kdy uživatel řeší samotný obsah i formátování v jednu chvíli skrze různé druhy formátovacích tagů. O vyplňování obsahu do HTML se v případě staticky generovaných webů stará právě samotný generátor.
V současnosti existuje nespočet značkovacích jazyků. Nejpoužívanějším z nich je jednoznačně HTML, ovšem tato práce se věnuje těm nejpoužívanějším jazykům, které mají uživateli usnadnit psaní a sázení obsahu. Uživatel se tedy nemusí při tvorbě nutně zabývat typografií a formátováním obsahu, což jsou aspekty, o které se později postará generátor pomocí šablon. U HTML je tomu naopak, uživatel řeší samotný obsah i formátování v jednu chvíli skrze různé druhy formátovacích tagů. O vyplňování obsahu do HTML se v případě staticky generovaných webů stará právě samotný generátor.
Vybrané jazyky jsou zároveň cílené na čitelnost samotného zdrojového obsahu v čistém textu bez nutnosti jeho interpretace speciálním prostředím či zpracováním do jiného formátu, například do PDF, DjVu, PostScript apod. Například podtržení textu je v nějakém pseudo-jazyce reprezentováno opravdovým podtržením pomocí spojovníků, nikoliv obalením nadpisu ve speciální deklaraci, jako je tomu například u HTML. Podtržení je poté pro čtenáře mnohem jasnější, jelikož nemusí přemýšlet, co v případě HTML daný tag vůbec způsobuje, ale podtržený vyplývá z kontextu.
Vybrané jazyky jsou zároveň cílené na čitelnost samotného zdrojového obsahu v čistém textu bez nutnosti jeho interpretace speciálním prostředím či zpracováním do jiného formátu, například do PDF, DjVu, PostScript apod. Například podtržení textu je v nějakém pseudo-jazyce reprezentováno opravdovým podtržením pomocí spojovníků, nikoliv obalením nadpisu ve speciální deklaraci, jako je tomu například u HTML. Podtržení je poté pro čtenáře mnohem jasnější, jelikož nemusí přemýšlet, co v kontextu HTML daný tag znamená, kdežto podtržení vyplývá z kontextu.
Seznam nejoblíbenějších jazyků je sestaven podle aktuálních statistik ze serveru Slant, který se věnuje obecnému určení oblíbenosti na základě hodnocení ze strany uživatelů. \citep{slant}
\subsection{Markdown}\label{kap:markdown}
Vznik jazyka Markdown byl 14. prosince roku 2014, když John Gruber vydal jeho první popis syntaxe a referenční implementaci.
Jazyka Markdown vznikl 19. března roku 2004, když John Gruber vydal první popis syntaxe a referenční implementaci.
Hlavním z cílů syntaxe jazyka je vytvářet co možná nejčitelnější obsah v syrové podobě. Dokument psaný v Markdownu by měl být publikovatelný sám o sobě jako čistý text bez dalších úprav a zpracování. Jazyk byl ovlivněn několika již existujícími specifikacemi jiných jazyků, ovšem největším zdrojem inspirace pro jeho vznik jsou čisté emailové korespondence. \citep{daringfireball}
První specifikaci Gruber vydal společně s referenční implementací v jazyce Perl, která slouží pro konverzi Markdownu do HTML. Tento program je také pojmenován jako\uv{Markdown}, ovšem mluvíme-li o \uv{Markdownu}, máme nejčastěji na mysli samotnou syntaxi. Ta je dnes již implementována v mnoha různých jazycích a programech. Gruberova specifikace ovšem není formální standard, kvůli čemuž vznikl veliký počet alternativních a více čí méně pozměněných implementací, které nemusí být navzájem kompatibilní. Nejčastějšími z nich jsou například Github Markdown, CommonMark, R Markdown a mnoho dalších. \citep{commonmark}
První specifikaci Gruber vydal společně s referenční implementací v jazyce Perl, která prováděla konverzi Markdownu do HTML. Tento program je také pojmenován \uv{Markdown}, ovšem mluvíme-li o \uv{Markdownu}, máme nejčastěji na mysli samotnou syntaxi. Ta má dnes mnoho implementací v různých programovacích jazycích. Gruberova specifikace ovšem není formální standard, kvůli čemuž vznikl veliký počet alternativních a více či méně pozměněných implementací, které nemusí být navzájem kompatibilní. Nejčastějšími z nich jsou například Github Markdown, CommonMark, R Markdown a mnoho dalších. \citep{commonmark}
Nevyužívanější formální specifikací je právě CommonMark\footnote{\url{https://commonmark.org/}}, který slouží jako pevný základ většiny rozšíření. \citep{github_formal_markdown_spec}.
Podobně jako je tomu u specifikací, existuje velké množství programů, které tyto různé specifikace překládají. Švýcarským nožem mezi nimi je program Pandoc\footnote{\url{https://pandoc.org/}}, který umí překládat Markdown do enormního výběru jiných formátů, nebo z jiných formátů zpět. Tato funkcionalita se nezvtahuje pouze na jazyk Markdown, ovšem Pandoc dokáže operovat mezi všemy podporovanými formáty, například dokáže konvertovat obsah z HTML do \TeX{}u. Na druhou stranu existují i velmi jednoduché překladače, například program smu\footnote{\url{https://github.com/Gottox/smu}}, který umí překládat Markdown do HTML nebo čistého textu a neobsahuje více než 600 SLOC\footnote{Source lines of code}, tedy řádků kódu hlavního programu.
Podobně jako je tomu u specifikací, existuje velké množství programů, které tyto různé specifikace překládají. Švýcarským nožem mezi nimi je program Pandoc\footnote{\url{https://pandoc.org/}}, který umí překládat Markdown do enormního výběru jiných formátů, nebo z jiných formátů zpět. Tato funkcionalita se nevztahuje pouze na jazyk Markdown, Pandoc dokáže operovat mezi všemi podporovanými formáty, například dokáže konvertovat obsah z HTML do \TeX{}u. Na druhou stranu existují i velmi jednoduché překladače, například program smu\footnote{\url{https://github.com/Gottox/smu}}, který umí překládat Markdown do HTML nebo čistého textu a neobsahuje více než 600 SLOC\footnote{Source lines of code}, tedy řádků kódu hlavního programu.
\subsection{Org-mode}
Org-mode vznikl jako jeden z módů pro editor Emacs\footnote{\url{https://www.gnu.org/software/emacs/}}. Funguje podobně jako ostatní markup jazyky, tedy jako jeden centrální systém pro správu obsahu, ze kterého lze vytvářet jiné formáty, například HTML, \LaTeX, Open Document, Markdown, PDF a podobně s možností přidání libovolného nového backendu\todo{České slovo?}. Cílem Org-mode je možnost ho používat i s minimální úrovní jeho znalosti, ovšem jeho funkcionalita je vždy přístupná. Vše je realizováno pouze na čistých textových souborech, nejlépe přenositelným typem souboru. Editor emacs je zároveň velmi často protován na různé druhy stsémů a je tedy možné ho využívat v podstatě kdekoliv. \citep{orgmanual}
Org-mode vznikl jako jeden z módů pro editor Emacs\footnote{\url{https://www.gnu.org/software/emacs/}}. Funguje podobně jako ostatní markup jazyky, tedy jako jeden centrální systém pro správu obsahu, ze kterého lze vytvářet jiné formáty, například HTML, \LaTeX, Open Document, Markdown, PDF a podobně s možností přidání libovolného nového backendu\todo{České slovo?}. Cílem Org-mode je možnost ho používat i s minimální úrovní jeho znalosti, ovšem jeho funkcionalita je vždy přístupná. Vše je realizováno pouze na čistých textových souborech, nejlépe přenositelným typem souboru. Editor Emacs je zároveň velmi často portován na různé druhy systémů a je tedy možné ho využívat v podstatě kdekoliv. \citep{orgmanual}
Podporuje také \uv{literate programming} a \uv{reproducible research}, tedy že Org soubory mohou obsahovat plně funkční bloky s kódem, které lze evaluovat v rámci systému a výstup bloků lze automaticky vkládat přímo do dokumentu. \citep{environment_for_literate_programming}
Podporuje také \uv{literate programming} a \uv{reproducible research}, tedy že Org soubory mohou obsahovat plně funkční bloky s kódem, které lze hodnotit v rámci systému a výstup bloků lze automaticky vkládat přímo do dokumentu. \citep{environment_for_literate_programming}
Jak popisuje Carsten Dominik ve svém krátkém technickém popisu, Org-mode umí navrhování, psaní poznámek, hypertextové odkazy, tabulky, seznamy, plánování projektů, GTD, HTML a \LaTeX{}, a to všechno v čistých textových souborech v editoru Emacs. \citep{carsten_dominik}
@ -51,7 +51,7 @@ Tento jazyk se již vzdaluje od původního konceptu čitelnosti zdroje, ovšem
Většina uživatelů se setkala spíše s jazykem \LaTeX, tedy s nadstavbou původního \TeX{}u, která má uživateli zjednodušit práci svými makry a rozšířeními. Realita je ovšem taková, že \LaTeX{} dělá celou práci složitější, jak popisuje doktor Olšák:
\begin{quote}
Představte si, že si nějaký uživatel přečte \LaTeX{}ovou příručku a nabyde dojmu, že mu bude stačit rozumět problematice sazby na úrovni této příručky. Pak se jednou překlepne třeba při sestavování tabulky a na terminálu na něj \TeX{} křičí: {\tt Extra alignment tab has been changed to "\verb|\cr|".} Uživatel začne znovu listovat ve své příručce a zjistí, že tam o~žádném "\verb|\cr|" není jediná zmínka. Má pak tři možnosti: (1)~Zmáčkne Enter a podobně se zachová i u~dalších chyb. Pomyslí si, že ten \LaTeX{} je něco tajemného a mystického. (2)~Propadne zoufalství a jde od toho. Dojde k~závěru, ľe je lepší zůstat u~Wordu. Vždyť stačí vzít tabulku v~Excelu a jednoduše ji přemístit do Wordu a jaképak smolení se s~nějakým podezřelým "\verb|\cr|". (3)~Pořídí si \TeX{}book a po intenzivním studiu nakonec řekne: \uv{aha}. V~tuto chvíli ale už nepotřebuje, aby mu \LaTeX{} zakrýval složitost \TeX{}u.
Představte si, že si nějaký uživatel přečte \LaTeX{}ovou příručku a nabude dojmu, že mu bude stačit rozumět problematice sazby na úrovni této příručky. Pak se jednou překlepne třeba při sestavování tabulky a na terminálu na něj \TeX{} křičí: {\tt Extra alignment tab has been changed to "\verb|\cr|".} Uživatel začne znovu listovat ve své příručce a zjistí, že tam o~žádném "\verb|\cr|" není jediná zmínka. Má pak tři možnosti: (1)~Zmáčkne Enter a podobně se zachová i u~dalších chyb. Pomyslí si, že ten \LaTeX{} je něco tajemného a mystického. (2)~Propadne zoufalství a jde od toho. Dojde k~závěru, ľe je lepší zůstat u~Wordu. Vždyť stačí vzít tabulku v~Excelu a jednoduše ji přemístit do Wordu a jaképak smolení se s~nějakým podezřelým "\verb|\cr|". (3)~Pořídí si \TeX{}book a po intenzivním studiu nakonec řekne: \uv{aha}. V~tuto chvíli ale už nepotřebuje, aby mu \LaTeX{} zakrýval složitost \TeX{}u.
\end{quote}\citep{nolatex}
Ve výsledku je tedy lepší, z různých důvodů popsaných doktorem Olšákem v jeho publikaci, použít samotný plain \TeX{} na úkor vyšší vstupní úrovně pro použivání jazyka.
@ -8,21 +8,21 @@ Modelový web se skládá ze dvou částí, a to z verzovacího systému pro spr
\subsection{Verzovací systém pro správu obsahu}\label{kap:vyber-vhodneho-systemu-verzovani}
Pro správu obsahu i šablon a statických souborů byl zvolen distribuovaný verzovací systém Git, který má v porovnání s jinými verzovacími systémy spousty výhod. Hlavní jeho výhodou je rozšířené využití v praxi a snadné používání. Díky svým decentralizovaným vlastnostem ho lze využívat v mnoha odlišných pracovních postupech. S naklonovaným repozitářem lze pracovat i bez připojení k síti, což lze považovat i za druh zálohy. Git také umožňuje slučování různých změn od mnoha uživatelů a dovoluje jednoduše řešit potenciální konflikty. \citep{why_is_git_better_than_x}
Pro správu obsahu i šablon a statických souborů byl zvolen distribuovaný verzovací systém Git, který má v porovnání s jinými verzovacími systémy, zejména centralizovanými, spousty výhod. Hlavní jeho výhodou je rozšířené využití v praxi a snadné používání. Díky svým decentralizovaným vlastnostem ho lze využívat v mnoha odlišných pracovních postupech. S naklonovaným repozitářem lze pracovat i bez připojení k síti, což lze považovat i za druh zálohy. Git také umožňuje slučování různých změn od mnoha uživatelů a dovoluje jednoduše řešit potenciální konflikty. \citep{why_is_git_better_than_x}
Skvěle využitelnou funkcí pro modelovou implementaci je také to, že po provedení změn v repozitáři lze pomocí Gitu spouštět skripty, které mohou provádět automatické generování obsahu a další užitečné operace. Tato funkcionalita je implementována v rámci modelové implementace v sekci \ref{kap:automaticke-generovani-obsahu}.
\subsection{Generátor statického webu}
Protože forma modelového webu odpovídá paradigmatu webové prezentace ze sekce \ref{kap:paradigmata-webova-prezentace}, byl pro jeho generování použit program Zola\footnote{\url{https://www.getzola.org/}}, jehož výhody jsou v sekci \ref{kap:paradigmata-webova-prezentace} popsány.
Protože forma modelového webu odpovídá paradigmatu webové prezentace ze sekce \ref{kap:paradigmata-webova-prezentace}, byl pro jeho generování použit program Zola\footnote{\url{https://www.getzola.org/}}, jehož výhody jsou popsány v sekci \ref{kap:paradigmata-webova-prezentace}.
\todo[inline]{Přesunout výběr a výhody generátoru sem.}
\section{Tvorba šablony}
Jak se uvádí v dokumentaci\footnote{\url{https://www.getzola.org/documentation/content/overview/}}, Zola pracuje s několika druhy stránek, primárně s takzvanou \uv{sekcí} a \uv{stránkou}. Každá sekce může mít vlastní obsah, ovšem může obsahovat i další subsekce, díky čemuž lze dělit obsah do stromové struktury. Stránka slouží pouze k předání obsahu a nikoliv k dalšímu větvení struktury. Dá se tedy říci, že stránka značí konec dané větve. Kořenem celého stromu je speciální sekce s názvem \uv{index}. Každá tato část standardně využívá vlastní HTML šablonu, ovšem nejde o pravidlo a každá část větve může využívat jinou šablonu. To je užitečné například u stránek s různým druhem obsahu. V rámci modelového webu zůstává druh obsahu stejný a není tedy třeba odchylovat se od standardní struktury.
Jak se uvádí v dokumentaci\footnote{\url{https://www.getzola.org/documentation/content/overview/}}, Zola pracuje s několika druhy stránek, primárně s takzvanou \uv{sekcí} a \uv{stránkou}. Každá sekce může mít vlastní obsah, ovšem může obsahovat i další subsekce, díky čemuž lze dělit obsah do stromové struktury. Stránka slouží pouze k předání obsahu a nikoliv k dalšímu větvení struktury. Dá se tedy říci, že stránka reprezentuje list v rámci stromovité struktury. Kořenem celého stromu je speciální sekce s názvem \uv{index}. Každá tato část standardně využívá vlastní HTML šablonu, to není ovšem pravidlo a každá část větve může využívat jinou šablonu. To je užitečné například u stránek s různými druhy obsahu. V rámci modelového webu zůstává druh obsahu stejný a není tedy třeba odchylovat se od standardní struktury.
Soubory se šablonami se nachází ve složce \texttt{templates/}, ve které generátor vždy očekává šablonu \texttt{index.html}. Ta se využívá jak k vykreslení úvodní kořenové stránky, tak ji mohou ostatní šablony rozšiřovat. Tato kořenová šablona tedy obsahuje základní strukturu celé stránky, přičemž navazující šablony jen mění určité části obsahu a nedefinují celou strukturu znovu.
Soubory se šablonami se nachází ve složce \texttt{templates/}, ve které generátor vždy očekává šablonu \texttt{index.html}. Ta se využívá jak k vykreslení úvodní kořenové stránky, tak jako základ, kterou mohou ostatní šablony rozšiřovat. Tato kořenová šablona tedy obsahuje základní strukturu celé stránky, přičemž navazující šablony jen mění určité části obsahu a nedefinují celou strukturu znovu.
Generátor v šablonách hledá vlastní řídící sekvence, které se popisují závorkami. Existují tři druhy kombinací, které lze použít:
@ -102,7 +102,7 @@ Název stránky zůstane stejný a v jejím těle přibude text \uv{Ahoj, světe
{% endblock %}
\end{lstlisting}
Šablona \texttt{section.html} se v rámci generátoru Zola implicitně využívá pro všechny existující sekce\footnote{\url{https://www.getzola.org/documentation/content/section/}}. Názvem stránky v této šabloně bude, stejně jako u hlavní šablony, název stránky z konstanty \texttt{config.title} definované v konfiguračním souboru, ale také spojovník a název dané sekce. Za pseudo-výstup lze považovat například \uv{UČITEL ONLINE -- základní a střední škola}, bude-li se uživatel nacházet v sekci pro základní a střední školy.
Šablona \texttt{section.html} se v rámci generátoru Zola implicitně využívá pro všechny existující sekce\footnote{\url{https://www.getzola.org/documentation/content/section/}}. Názvem stránky v této šabloně bude, podobně jako u hlavní šablony, název stránky z konstanty \texttt{config.title} definované v konfiguračním souboru, ale také spojovník a název dané sekce. Za modelový výstup lze považovat například \uv{UČITEL ONLINE -- základní a střední škola}, bude-li se uživatel nacházet v sekci pro základní a střední školy.
V bloku s obsahem bude původní obsah \uv{Ahoj, světe!} nahrazen za řetězec \uv{Toto je obsah kategorie}. Ten ovšem nechceme definovat přímo v šabloně, nýbrž cílem generátoru je vyplňovat obsah ze zdrojových souborů v sázecím jazyce, viz. sekce \ref{kap:princip-generatoru}. Zola pro vkládání obsahu využívá stejný princip jako v ostatních případech, tedy vypsání obsahu proměnné, v tomto případě proměnné \texttt{section.content}, která obsahuje zkompilované HTML z daného Markdown souboru. Zároveň je dobrou praktikou provést vyčištění vstupu filtrem \texttt{safe}\footnote{\url{https://tera.netlify.com/docs/\#safe}}.
@ -119,16 +119,16 @@ Z principu by žádný obsah neměl být definován přímo v šabloně, nýbrž
Obsah modelové implementace je dělen do stromové datové struktury o potenciálně nekonečné hloubce, kdy každá část větve je v rámci generátoru vlastní kategorií, nikoliv stránkou. Pro modelovou implementaci bylo zvoleno, aby navigace byla generována v návaznosti na aktivní cestu ve stromě. Ve stránce jsou dvě různé navigace, jedna hlavní a vždy vidiětelná, která obsahuje rozdělení obsahu dle škol a druhá navigace, která zobrazuje aktivní větev stromu.
Obsah modelové implementace je dělen do stromové datové struktury o potenciálně nekonečné hloubce, kdy každá část větve je v rámci generátoru vlastní kategorií, nikoliv stránkou. Pro modelovou implementaci bylo zvoleno, aby navigace byla generována v návaznosti na aktivní cestu ve stromě. Ve stránce jsou dvě různé navigace, hlavní, která je vždy viditelná a obsahuje rozdělení obsahu dle škol a vedlejší, která zobrazuje aktivní větev stromu.
\caption{Diagram průběhu generování vícevrstvé navigace}
\end{figure}
První vrstvou struktury jsou hlavní sekce, v rámci implementace pojemnované jako $L_1$, které jsou vypsány vždy ve vlastní navigaci. Pod touto navigací je zobrazen seznam všech kategorií, které vybraná položka v $L_1$ obsahuje. Pokud uživatel zvolí kteroukoliv položku v $L_2$, v navigaci se objeví další sloupec, který obsahuje všechny podkategorie vybrané položky, tedy všechny podkategorie ve vrstvě $L_3$. Takto lze stromem procházet potenciálně do nekonečna. Styly modelové šablony ovšem počítají s maximální hloubkou čtyř subkategorií.
První vrstvou struktury jsou hlavní sekce, v rámci implementace pojmenované jako $L_1$, které jsou vypsány vždy ve vlastní navigaci. Pod touto navigací je zobrazen seznam všech kategorií, které vybraná položka v $L_1$ obsahuje. Pokud uživatel zvolí kteroukoliv položku v $L_2$, v navigaci se objeví další sloupec, který obsahuje všechny podkategorie vybrané položky, tedy všechny podkategorie ve vrstvě $L_3$. Takto lze stromem procházet potenciálně do nekonečna. Styly modelové šablony ovšem počítají s maximální hloubkou čtyř subkategorií.
Tato funkcionalita je implementována pomocí tří cyklů, z níchž jeden je vložený. První cyklus (příklad \ref{lst:obsah-cyklus1}) se provádí pro všechny rodiče aktivní ktegorie vrstev $L_2,L_3,\dotsc,L_n$, kde $n$ je aktuílní vrstva. V každé iteraci se mění kontext, ve kterém generátor pracuje. Z daného kontextu generátor vypisuje pomocí vnořeného cyklem všechny subkategorie. Ve druhém cyklu (příklad \ref{lst:obsah-cyklus2}) se vypisují všichni potomci dané stránky, tedy potomci ve vrstvě $L_{n+1}$.
Tato funkcionalita je implementována pomocí tří cyklů, z nichž jeden je vložený. První cyklus (příklad \ref{lst:obsah-cyklus1}) se provádí pro všechny rodiče aktivní kategorie vrstev $L_2,L_3,\dotsc,L_n$, kde $n$ je aktuální vrstva. V každé iteraci se mění kontext, ve kterém generátor pracuje. Z daného kontextu generátor vypisuje pomocí vnořeného cyklem všechny subkategorie. Ve druhém cyklu (příklad \ref{lst:obsah-cyklus2}) se vypisují všichni potomci dané stránky, tedy potomci ve vrstvě $L_{n+1}$.
\begin{lstlisting}[label=lst:obsah-cyklus1,caption=Cyklus pro vypisování všech rodičů v dané větvi navigace]
{% if section.ancestors %}
@ -164,23 +164,23 @@ Tato funkcionalita je implementována pomocí tří cyklů, z níchž jeden je v
Ve výchozím stavu generátor neumí vkládat nic jiného, než je uvedeno ve specifikaci CommonMark, viz. sekce \ref{kap:markdown}. Dle požadavků modelového webu je nutné, aby generátor uměl vkládat videa přímo do stránky. Taková funkcionalita není soušástí specifikace CommonMark a je tedy potřeba rozšířit generátor. Nejvhodnějším způsobem přidání vlastních funkcionalit je využití filtrů, které se v rámci generátoru nazývají \uv{shortcode}.
Ve výchozím stavu generátor neumí zpracovávat nic jiného, než co je uvedeno ve specifikaci CommonMark, viz. sekce \ref{kap:markdown}. Dle požadavků modelového webu je nutné, aby generátor uměl vkládat videa přímo do stránky. Taková funkcionalita není součástí specifikace CommonMark a je tedy potřeba rozšířit generátor. Nejvhodnějším způsobem přidání vlastních funkcionalit je využití filtrů, které se v rámci generátoru nazývají \uv{shortcode}.
Principem vlastních filtrů je to, že si uživatel vytvoří vlastní šablonu, kterou lze vyvolat speciální řídící sekvencí přímo z obsahu. Každý tento shortcode může pracovat s libovolným množstvím proměnných a po zpracování vloží do místa vyvolání zkompilovaný HTML kód. Lze tedy tvrdit, že shortcode je v své podstatě imperativní funkce, která umí pracovat s parametry.
Principem vlastních filtrů je to, že si uživatel vytvoří vlastní šablonu, kterou lze vyvolat pomocí speciální řídící sekvence přímo z obsahu. Každý tento shortcode může pracovat s libovolným množstvím proměnných a po zpracování vloží do místa vyvolání zkompilovaný HTML kód. Dá se tedy říci, že shortcode je v své podstatě funkce, která umí pracovat s parametry.
Pro tvorbu těchto filtrů je v generátoru Zola určena složka \texttt{templates/shortcodes}, která obsahuje jejich HTML šablony a kód pro zpracování generátorem. Název HTML souboru definuje název vlastního filtru. Vytvoříme-li uvitř této složky soubor nazvaný \texttt{video.html}, budeme v obsahu schopni využívat vlastní filtr s názvem \texttt{video}.
Pro tvorbu těchto filtrů je v generátoru Zola určena složka \texttt{templates/shortcodes}, která obsahuje jejich HTML šablony a kód pro zpracování generátorem. Název HTML souboru definuje název vlastního filtru. Vytvoříme-li uvnitř této složky soubor nazvaný \texttt{video.html}, budeme v obsahu schopni využívat vlastní filtr s názvem \texttt{video}.
\begin{lstlisting}[label=lst:jednoduchy-filtr,caption=Příklad jednoduchého filtru s jedním atributem]
<video controls><source src="{{ src }}"></video>
\end{lstlisting}
V příkladu \ref{lst:jednoduchy-filtr} bude filtr očekávat atribut \texttt{src} a bude vracet jednoduchý HTML kód pro vložení videa do stránky. Tento filtr lze vyvolat kdekoliv v obsahu, tedy v kterémkoliv souboru s koncovkou \texttt{.md}. Za názvem filtru se do závorky uvádí parametry oddělené čárkou. U posledního parametru se čárky nevuvádí, což platí i v případě, kdy se uvádí pouze jeden parametr, jako je tomu v příkladu \ref{lst:vyvolani-filtru}.
V příkladu \ref{lst:jednoduchy-filtr} bude filtr očekávat atribut \texttt{src} a bude vracet jednoduchý HTML kód pro vložení videa do stránky. Tento filtr lze vyvolat kdekoliv v obsahu, tedy v kterémkoliv souboru s koncovkou \texttt{.md}. Za názvem filtru se do závorky uvádí parametry oddělené čárkou. U posledního parametru se čárky neuvádí, což platí i v případě, kdy se uvádí pouze jeden parametr, jako je tomu v příkladu \ref{lst:vyvolani-filtru}.
\begin{lstlisting}[label=lst:vyvolani-filtru,caption=Vyvolání vlastního filtru s jedním parametrem]
{{ video(src="video.webm") }}
\end{lstlisting}
V rámci vybraného generátoru není nutné specifikovat atributy na jeden řádek a lze je pro přehlednost vypisovat na více řádků, jako tomu je například u programu \ref{lst:formatovani-atributu}, zůstane-li dodržena koncepce oddělení atributů čárkou, tedy že poslední atribut vždy zůstane bez čárky. Výstupem této direktivy bude následující HTML kód.
V rámci vybraného generátoru není nutné specifikovat atributy na jeden řádek a lze je pro přehlednost vypisovat na více řádků, jako tomu je například u programu \ref{lst:formatovani-atributu}, zůstane-li dodržen způsob oddělování atributů čárkou, tedy že poslední atribut vždy zůstane bez čárky. Výstupem této direktivy bude následující HTML kód.
\begin{lstlisting}[caption=Výstup direktivy z příkladu \ref{lst:jednoduchy-filtr}]
<video controls><source src="video.webm"></video>
@ -200,7 +200,7 @@ Součástí požadavků pro modelový web jsou i citace přiložených souborů
{% endif %}
\end{lstlisting}
Filtr je možné opět vyvolat pomocí stejné direktivy kdekoliv v obsahu, ovšem nyní lze libovolně přidat parametry pro metadata.
Filtr je opět možné vyvolat pomocí stejné direktivy kdekoliv v obsahu, ovšem nyní lze libovolně přidávat parametry pro metadata.
\begin{lstlisting}[label=lst:formatovani-atributu,caption=Vyvolání filtru \ref{lst:filtr-s-podminkami} s formátováním na řádky]
{{ video(
@ -211,16 +211,16 @@ Filtr je možné opět vyvolat pomocí stejné direktivy kdekoliv v obsahu, ovš
) }}
\end{lstlisting}
Protože byly zadány všechny povinné i nepovinné atributy, výtupem toho filtru budou i části kódu s metadaty.
Protože byly zadány všechny povinné i nepovinné atributy, výstupem toho filtru budou i části kódu s metadaty.
\begin{lstlisting}[caption=Výstup direktivy z příkladu \ref{lst:formatovani-atributu}]
<video controls><source src="video.webm"></video>
<video controls><source src="video.webm"></video>
<div class="metadata">
Název videa (2020, Jméno autora)
</div>
\end{lstlisting}
Pro modelový web byla zvážena možnost vypisování obsahu automaticky, tedy že program zkontroluje složku s obsahem a pokud narazí na soubor se specifikovanou koncovkou, vypíše jej do obsahu podle daných pravidel. Generátor Zola umožňuje prohledávání složek a práci se soubory, v rámci Zoly takzvanými\uv{assety}. Tuto funkcionalitu lze tedy implementovat jednoduchým cyklem a filtem, které zpracují všechny případné soubory ve složce dané stránky. Zoubory lze filtrovat mnoha způsoby, z nichž je nejuniverzálnější funkce \texttt{matching()}, která dovoluje filtrovat vstup regulárními výrazy dle implementace regex v jazyce Rust\footnote{\url{https://docs.rs/regex/1.3.6/regex/}}. V následujícím příkladu je pro ilustraci této funkcionality implementován program vypisující obrázky s předem definovanými koncovkami.
Pro modelový web byla zvážena možnost vypisování obsahu automaticky, tedy že program projde složku s obsahem a pokud narazí na soubor se specifikovanou koncovkou, vypíše jej do obsahu podle daných pravidel. Generátor Zola umožňuje prohledávání složek a práci se soubory, pro které se v rámci Zoly používá termín\uv{assety}. Tuto funkcionalitu lze tedy implementovat jednoduchým cyklem a filtrem, které zpracují všechny případné soubory ve složce dané stránky. Soubory lze filtrovat mnoha způsoby, z nichž je nejuniverzálnější funkce \texttt{matching()}, která dovoluje filtrovat vstup regulárními výrazy dle jejich implementace v jazyce Rust\footnote{\url{https://docs.rs/regex/1.3.6/regex/}}. V následujícím příkladu je pro ilustraci této funkcionality implementován program vypisující obrázky s předem definovanými koncovkami.
\begin{lstlisting}[caption=Automatický výpis obrázků s pevně definovanými koncovkami]
{% if section.assets %}
@ -232,7 +232,7 @@ Protože byly zadány všechny povinné i nepovinné atributy, výtupem toho fil
{% endif %}
\end{lstlisting}
Toto řešení ovšem není ve výsledném modelu implemntováno, protože jedním z požadavků je možnost vkládání souborů na libovolné místo v obsahu. Na stejném principu je ovšem vytvořen filtr pro vládání souborů, který tento požadavek splňuje. Výhodou filtru je, že ho lze vyvolat kdekoliv v obsahu a není vázán na pevně dané místo v šabloně. Ten očekává alespoň jeden parametr uvádějící název souboru bez koncovky, prodle kterého pak filtr vyhledá všechny různé formáty s tímto názvem a ty vloží do stránky. Druhým libovolným parametrem je název souboru, který se do stránky vloží místo názvu souboru. to umožňuje uivateli volně pracovat s názvy souborů v souborvé struktuře bez ovlivnění obsahu stránky.
Toto řešení ovšem není ve výsledném modelu implementováno, protože jedním z požadavků je možnost vkládání souborů na libovolné místo v obsahu. Na stejném principu je vytvořen filtr pro vkládání souborů, který tento požadavek splňuje. Výhodou filtru je, že ho lze vyvolat kdekoliv v obsahu a není vázán na pevně dané místo v šabloně. Ten očekává alespoň jeden parametr uvádějící název souboru bez koncovky, podle kterého pak filtr vyhledá všechny různé formáty s tímto názvem a ty vloží do stránky. Druhým libovolným parametrem je název souboru, který se do stránky vloží místo názvu souboru. To umožňuje uživateli volně pracovat s názvy souborů v souborové struktuře bez ovlivnění obsahu stránky.
\begin{lstlisting}[label=lst:filtr-souboru,caption=Filtr pro výpis souborů s automatickým hledáním]
{% if section.assets and filename %}
@ -253,9 +253,9 @@ Toto řešení ovšem není ve výsledném modelu implemntováno, protože jedn
{% endif %}
\end{lstlisting}
V první části filtr zkontroluje, zda byl vyplněn parametr \texttt{title} a v přípdě že ano, nastaví ho jako název souoru v obsahu. V opačném případě využije název souboru samotného. Ve druhém kroku nastává kontrola, zda se ve složce nacházejí soubory (mimo hlavní soubor \texttt{\_index.md}) a pokud ano, přes všechny soubory se iteruje kontrola, zda soubor splňuje podmínku názvu. Kontrola této podmínky je tvořena kombinací proměnných generátoru a regulárního výrazu. Každý soubor který splňuje podmínku je poté vypsán do obahu jako přímý odkaz k jeho stažení.
V první části filtr zkontroluje, zda byl vyplněn parametr \texttt{title} a v případě, že ano, nastaví ho jako název souboru v obsahu. V opačném případě využije název souboru samotného. Ve druhém kroku nastává kontrola, zda se ve složce nacházejí soubory (mimo hlavní soubor \texttt{\_index.md}) a pokud ano, tak se iterativně zkontrolují všechny soubory, zda splňují podmínku názvu. Kontrola této podmínky je tvořena kombinací proměnných generátoru a regulárního výrazu. Každý soubor, který splňuje podmínku je poté vypsán do obsahu jako přímý odkaz k jeho stažení.
Jako text v odkazu se použije koncovka souboru, která se záskává spojením několika filtrů, tedy filtru \texttt{split(pat=".")}, který rozdělí řetězec podle znaku tečka do pole a navazující filtr \texttt{last} vrátí poslední položku v poli. Tím filtr získá samotnou koncovku souboru.
Jako text v odkazu se použije koncovka souboru, která se získává spojením několika filtrů, tedy filtru \texttt{split(pat=".")}, který rozdělí řetězec podle znaku tečka do pole a navazující filtr \texttt{last} vrátí poslední položku v poli. Tím filtr získá samotnou koncovku souboru.
Filtr lze vyvolat stejně, jako je tomu u filtru pro vkládání videa. Název filtru je opět definován názvem souboru \texttt{tmeplates/shortcodes/document.html} a bude jím tedy název \texttt{document()}.
@ -266,7 +266,7 @@ Filtr lze vyvolat stejně, jako je tomu u filtru pro vkládání videa. Název f
) }}
\end{lstlisting}
V příkladu \ref{lst:vyvolani-filtru-souboru} je definován i nepovinný atribut \texttt{title}, který kvůli přehlednosti umožňuje nastavit název. Atribut \texttt{filename} definuje název souboru ve složce bez koncovky. Všechny soubory, které chce uživatel vypsat, musí tedy mít stejný název a musí se lišit pouze koncovkou. Jsou li ve složce soubory s názvem \texttt{pracovni-list} a koncovkami \texttt{pdf}, \texttt{odt}, \texttt{djvu} a \texttt{ps}, bute výstupem filtru následující HTML.
V příkladu \ref{lst:vyvolani-filtru-souboru} je definován i nepovinný atribut \texttt{title}, který kvůli přehlednosti umožňuje nastavit název. Atribut \texttt{filename} definuje název souboru ve složce bez koncovky. Všechny soubory, které chce uživatel vypsat, musí tedy mít stejný název a musí se lišit pouze koncovkou. Jsou li ve složce soubory s názvem \texttt{pracovni-list} a koncovkami \texttt{pdf}, \texttt{odt}, \texttt{djvu} a \texttt{ps}, bude výstupem filtru následující HTML.
\begin{lstlisting}[caption=Výstup direktivy z příkladu \ref{lst:vyvolani-filtru-souboru}]
<div class="file">
@ -282,21 +282,21 @@ V příkladu \ref{lst:vyvolani-filtru-souboru} je definován i nepovinný atribu
Optimalizace modelové implementace je provedena na základě článku ze serveru \cite{calomel_optimization}, který se věnuje sestavením užitečných rad pro optimalizaci webových stránek na serverech s omezeným připojením do sítě a pro zvýšení spokojenosti uživatelů z užívání optimalizovaného webu, jak je rozebráno v sekci \ref{kap:vyhody-statickych-webovych-stranek}.
Jak se na webu Colomel píše, provozování webserveru může být hodnotná zkušenost, ale zároveň může být i zkouškou trpělivosti. Chcete svým uživatelům předávat všechny vaše stránky a obrázky, ovšem máte jen omezenou šířku pásma, pomocí které můžete data přenášet. Pokud přetížíte své pipojení, klienti nevštěvující váš web server si budou myslet, že je pomalý a neresponzivní. Je tedy třeba webový server nastavit tím nejlepším možným způsobem s cílem získat co nejvíce návštěv a zlepšit zážitek vašim návštěvníkům. Následující rady slouží ke snížení zátěže serveru, ke zrcyhlení odesílání stránek a k zastavení nechtěnného a škodlivého provozu.
Jak se na webu Colomel píše, provozování webserveru může být hodnotná zkušenost, ale zároveň může být i zkouškou trpělivosti. Chcete svým uživatelům předávat všechny vaše stránky a obrázky, ovšem máte jen omezenou šířku pásma, pomocí které můžete data přenášet. Pokud přetížíte své připojení, klienti navštěvující váš web server si budou myslet, že je pomalý a neresponzivní. Je tedy třeba webový server nastavit tím nejlepším možným způsobem s cílem získat co nejvíce návštěv a zlepšit zážitek vašim návštěvníkům. Následující rady slouží ke snížení zátěže serveru, ke zrychlení odesílání stránek a k zastavení nechtěného a škodlivého provozu.
Práce se věnuje pouze technickým optimalizacím spojených s tvorbou samotné webové stránky, nikoliv však optimalizacím sítě, web serveru a vizuálního návrhu. Nenačítá-li se stránka během několika vteřin, většina uživatelů jednoduše odejde. Cílem této sekce je provést optimalizace, které urychlí načítání modelové implementace.
\subsection{Typy a kvalita obrázků}
Fotografie a grafika využívají mnohem více dat pro přenos než běžný HTML text a je tedy nutné provést optimalizaci (kompresi) obrázků na co nejmenší možnou velikost souborů. Obrázky není třeba renderovat na více než 72 dpi a pro každý druh grafiky je třeba zvolit vhodný tofmát, tj. formát JPEG pro fotografie a formáty PNG či SVG pro jednoduchou grafiku. Rastrové obrázky mají pouze potřebné rozlišení, tedy maximálně hodnotu největšího rozlišení, které se ve stránce bude zobrazovat. Klíčové je také nevyužívat obrázky v případě, kde je lze nahradit čístým HTML a CSS.
Fotografie a grafika využívají mnohem více dat pro přenos než běžný HTML text a je tedy nutné provést optimalizaci (kompresi) obrázků na co nejmenší možnou velikost souborů. Obrázky není třeba renderovat na více než 72 dpi a pro každý druh grafiky je třeba zvolit vhodný formát, tj. formát JPEG pro fotografie a formáty PNG či SVG pro jednoduchou grafiku. Rastrové obrázky mají pouze potřebné rozlišení, tedy maximálně hodnotu největšího rozlišení, které se ve stránce bude zobrazovat. Klíčové je také nevyužívat obrázky v případě, kde je lze nahradit čistým HTML a CSS.
Obrázky ve formátu JPEG mají velice efektivní ztrátovou kompresi, pomocí které lze zredukovat velikost obrázku o značnou část. Autor článku tvrdí, že většinu obrázků lze komprimovat až o 50\% bez viditelné ztráty na kvalitě. Své obrázky dokonce zkomprimoval ze 27 kilobajtů na pouhých 8 kilobajtů s JPEG kompresí 60\%.
\subsection{Ikona \textit{favicon.ico}}
Původně je \textit{favicon.ico} výtvorem firmy Microsoft, kdy její Internet Explorer automaticky odesílal požadavek na pevnou URL \texttt{/favicon.ico} od kořene webového serveru. Jde o malou ikonku, která se dnes zobrazuje u každé záložky s webovou stránkou. Problémem je to, že se požadavkům o ní nelze vyhnout a vždy se počítá s tím, že ikona na web serveru existuje. Odesílá se vždy s každou stránkou a některé prohlížeče se po ní dotazují z neznámých důvodu dvakrát. Autor článku uvádí, že u některých serverů bylo až 30\% přenesených dat využito jen na servírování ikony.
Původně je \textit{favicon.ico} výtvorem firmy Microsoft, kdy Internet Explorer automaticky odesílal požadavek na pevnou URL \texttt{/favicon.ico} od kořene webového serveru. Jde o malou ikonku, která se dnes zobrazuje u každé záložky s webovou stránkou. Problémem je, že se požadavkům o ní nelze vyhnout a vždy se počítá s tím, že ikona na web serveru existuje. Odesílá se vždy s každou stránkou a některé prohlížeče se po ní dotazují z neznámých důvodu dvakrát. Autor článku uvádí, že u některých serverů bylo až 30\% přenesených dat využito jen na odesílání ikony.
Principem optimalizace je udržet ikonu ji co nejmenší, v nejlepším případě tak malou, že se vejde do jednoho TCP paketu, tedy do velikosti 1460 bajtů na většině systémů. Toho lze docílit tím, že ikona nebude větší než 16x16 pixelů s nízkou barevnou hloubkou, nejlépe s pouze čtyřmi barvami. Také je možné poslat pouze 1x1 pixelů veliký prázdný obrázek, nebo vracet stavový kód 204\footnote{204 No Content -- Server úspěšně zpracoval požadavek, ale nevrací žádný obsah.} a neodesílat ikonu žádnou.
Principem optimalizace je udržet ikonu co nejmenší, v nejlepším případě tak malou, že se vejde do jednoho TCP paketu, tedy do velikosti 1460 bajtů na většině systémů. Toho lze docílit tím, že ikona nebude větší než 16x16 pixelů s nízkou barevnou hloubkou, nejlépe s pouze čtyřmi barvami. Také je možné poslat pouze 1x1 pixelů veliký prázdný obrázek, nebo vracet stavový kód 204\footnote{204 No Content -- Server úspěšně zpracoval požadavek, ale nevrací žádný obsah.} a neodesílat ikonu žádnou.
\subsection{Obecné HTML optimalizace}
@ -311,13 +311,13 @@ Redukcí nepotřebných znaků v HTML lze také ušetřit značnou část přeno
\item recyklování již použitých obrázků a tlačítek.
\end{itemize}
K odstranění přebytečných mezer, zalomení řádků, HTML komentářů a prázdných řádků lze použít automatický filtr, který provede kompresi výstupu. \todo{Přesunout do návrhu pro rozšíření?}Generátor Zola provádí kompresi CSS, ovšem nemá zabudovanou funkcionalitu pro minifikaci výsledného HTML, která je ovšem v době psaní této práce vyvíjena\footnote{\url{https://github.com/getzola/zola/issues/542}}.
K odstranění přebytečných mezer, zalomení řádků, HTML komentářů a prázdných řádků lze použít automatický filtr, který provede kompresi výstupu. \todo{Přesunout do návrhu pro rozšíření?}Generátor Zola provádí kompresi CSS, ovšem nemá zabudovanou funkcionalitu pro minifikaci výsledného HTML, která je v době psaní této práce vyvíjena\footnote{\url{https://github.com/getzola/zola/issues/542}}.
Touto redukcí lze ušetřit 2\% přenosu dat oproti ručně psanému neoptimalizovanému kódu. Je-li průměrná velikost stránky sto kilobajtů, lze touto optimalizací ušetřit dva kilobajty při každém odeslání stránky. Při odeslání sta tisíce stránek za měsíc je ve výsledku ušetřeno dvě stě megabajtů dat, které jsou jinak zbytečně odesílány uživatelům, kteří je stejně nezobrazí.
Další obecné rady pro optimalizaci HTML jsou uvedeny na serveru \cite{yahoo_optimization}, kde se uvádí spousta dalších způsobů ke zrychlení načítání stránky a k nižšímu vytížení sítě.
Připojením externích CSS a JavaScript souborů je umožněno jejich ukládání do paměti cache, což snižuje HTTP požadavky vůči serveru. Je-li obsah těchto souborů přímo ve stránce, je odesílán pokaždé s novou stránkou a to vede ke zbytečnému vytěžování sítě. S tím souvísí i velikost stránek, kdy soubory větší než je daná maximální velikost se do paměti cache neukládají a je proto dobré tuto velikost nepřekračovat.
Připojením externích CSS a JavaScript souborů je umožněno jejich ukládání do paměti cache, což snižuje HTTP požadavky vůči serveru. Je-li obsah těchto souborů přímo ve stránce, je odesílán pokaždé s novou stránkou a to vede ke zbytečnému vytěžování sítě. S tím souvisí i velikost stránek, kdy soubory větší než je daná maximální velikost se do mezipaměti neukládají a je proto dobré tuto velikost nepřekračovat.
\quest[inline]{U starých zařízení jsou pevně dané velikosti, například v roce 2011 byly limity 25.6K u iOS nebo 5M u Firefoxu. Mám je zde uvádět, i když se to rychle mění, nebo to stačí takhle obecně?}
@ -325,7 +325,7 @@ Připojením externího CSS přímo do hlavičky je umožněno progresivní vykr
Je také důležité udržovat validní HTML, kdy například chybějící atribut \texttt{src=""} způsobuje odesílání nevyžádaných požadavků na server.
\quest[inline]{HTML5 už specifikuje, aby prohlížeče kvůli prázdnému \textit{src} neposílaly další požadavaek. Je tedy nutné uvádět tento příklad?}
\quest[inline]{HTML5 už specifikuje, aby prohlížeče kvůli prázdnému \textit{src} neposílaly další požadavek. Je tedy nutné uvádět tento příklad?}
\subsection{Videa a jejich vložení do stránky}
@ -333,19 +333,19 @@ Je také důležité udržovat validní HTML, kdy například chybějící atrib
\section{Správa obsahu a verzování}
Statické stránky neumožňují správu uživatelů v prámci webové aplikace, tedy že se případný editor nebo administrátor přihlásí a upravuje obsah klikáním, či psaním ve WYSIWYG\footnote{What You See Is What You Get -- Princip editoru který během psaní formátuje text tak, jak bude ve výsledku vypadat, například LibreOffice Writer atd.} editoru. Správu uživatelů lze jednoduše řešit omezením přístupu na web server, kde jen oprávnění uživatelé mohou do obsahu zasahovat. To je ovšem velmi tězkopádné řešení, protože neumožňuje práci více uživatelům najednou a neudržuje předešlé verze obsahu a historii úprav. Lepší alternativou je využití některého verzovacího systému. Pro účely modelové implementace byl vybrán distribuovaný verzovací systém Git, jak je vysvětleno v sekci \ref{kap:vyber-vhodneho-systemu-verzovani}.
Statické stránky neumožňují správu uživatelů v rámci webové aplikace, tedy, že se případný editor nebo administrátor přihlásí a upravuje obsah klikáním, či psaním ve WYSIWYG\footnote{What You See Is What You Get -- Princip editoru který během psaní formátuje text tak, jak bude ve výsledku vypadat, například LibreOffice Writer atd.} editoru. Správu uživatelů lze jednoduše řešit omezením přístupu na web server, kde jen oprávnění uživatelé mohou do obsahu zasahovat. To je ovšem velmi těžkopádné řešení, protože neumožňuje práci více uživatelům najednou a neudržuje předešlé verze obsahu a historii úprav. Lepší alternativou je využití některého verzovacího systému. Pro účely modelové implementace byl vybrán distribuovaný verzovací systém Git, jak je vysvětleno v sekci \ref{kap:vyber-vhodneho-systemu-verzovani}.
V tomto systému jsou soubory uloženy repozitářích, kde každý projekt je vlastní repozitář. V rámci repozitáře se ukládají všechny změny obsahu v takzvaných \uv{commitech}, nebo-li záznamech o provedených změnách včetně krátkého popisu a jejich autora. Tyto revize lze provádět v různých větvích repozitáře a větve je možné mezi sebou spojovat a kombinovat. Je také možné vracet se do kteréhokoliv bodu v historii v rámci každé větvě.
V tomto systému jsou soubory uloženy v repozitářích, kde každý projekt je vlastní repozitář. V rámci jednotlivých repozitářů se ukládají všechny změny obsahu prostřednictvím takzvaných \uv{commitech}, nebo-li záznamů o provedených změnách včetně jejich krátkého popisu a autora. Tyto revize lze provádět v různých větvích repozitáře a větve je možné mezi sebou spojovat a kombinovat. Je také možné vracet se do kteréhokoliv bodu v historii v rámci každé větvě.
Nastane-li konflikt při nahrávání změn, umoňujě Git jejich snadné vyřešení. Konflikt je stav, kdy například dva různí uživatelé provedli úpravy na stejném místě stejného souboru a snaží se je nahrát do repozitáře. Git v tuto chvíli druhého uživatele upozorní, že původní soubor byl změněn a je třeba tento konflikt vyřešit. Zamezuje se tedy přepsání změn prvního uživatele.
Nastane-li konflikt při nahrávání změn, umožňuje Git jejich snadné vyřešení. Konflikt je stav, kdy například dva různí uživatelé provedli úpravy na stejném místě stejného souboru a snaží se je nahrát do repozitáře. Git v tuto chvíli druhého uživatele upozorní, že původní soubor byl změněn a je třeba tento konflikt vyřešit. Zamezuje se tedy přepsání změn prvního uživatele.
K systému Git existují různé služby, které tento systém rozšiřují i webové grafické rozhraní se spoustou dalších rozšíření. Nejčastěji používanými službami jsou GitHub\footnote{\url{https://github.com/}}, GitLab\footnote{\url{https://gitlab.com/}}, nebo Bitbucket\footnote{\url{https://bitbucket.org/}}, z nichž některé lze provozovat na vlastním serveru. Snadným systémem pro vlastní provozování je také program Gitea\footnote{\url{https://gitea.com/}}, který je oproti předem zmíněným systémům zcela svobodným sotwarem a je velmi jednoduchý na instalaci a správu. Tyto systémy mají navíc integrovaný jednoduchý WYSIWYG editor pro úpravu souborů přímo z webového rozhraní a také umí renderovat soubory s obsahem napsaným v jazyce Markdown, který je popsán v sekci \ref{kap:markdown}.
K systému Git existují různé služby, které tento systém rozšiřují o webové grafické rozhraní s množstvím dalších rozšíření. Nejčastěji používanými službami jsou GitHub\footnote{\url{https://github.com/}}, GitLab\footnote{\url{https://gitlab.com/}}, nebo Bitbucket\footnote{\url{https://bitbucket.org/}}, z nichž některé lze provozovat na vlastním serveru. Snadným systémem pro vlastní provozování je také program Gitea\footnote{\url{https://gitea.com/}}, který je oproti předem zmíněným systémům zcela svobodným softwarem a je velmi jednoduchý na instalaci a správu. Tyto systémy mají navíc integrovaný jednoduchý WYSIWYG editor pro úpravu souborů přímo z webového rozhraní a také umí renderovat soubory s obsahem napsaným v jazyce Markdown, který je popsán v sekci \ref{kap:markdown}.
Tato část práce se věnuje samotné implementaci automatického generování obsahu na základě změn v repozitáři.
Jak bylo zmíněno v sekci \ref{kap:vyber-vhodneho-systemu-verzovani}, git umožňuje nastavení takzvaných \uv{hooks}, které se v určité chvíli spustí. Jak uvádí dokuemntace\footnote{\url{https://git-scm.com/docs/githooks}}, existuje spousta druhů hooků, které jsou vyvolány v různé části zpracování požadavku. V případě této implementace je nejvhodnější hook \textit{post-receive}, který je spouštěn až po nahrání a zpracování všech změn v repozitáři.
Jak bylo zmíněno v sekci \ref{kap:vyber-vhodneho-systemu-verzovani}, git umožňuje nastavení takzvaných \uv{hooks}, které se v určité chvíli spustí. Jak uvádí dokumentace\footnote{\url{https://git-scm.com/docs/githooks}}, existuje spousta druhů hooků, které jsou vyvolány v různé části zpracování požadavku. V případě této implementace je nejvhodnější hook \textit{post-receive}, který je spouštěn až po nahrání a zpracování všech změn v repozitáři.
Následující skript po vyvolání Gitem provede veškeré potřebné operace ke zpracování nového obsahu na web serveru.
Skript \ref{lst:git-hook-skript} je složen z několika částí. Jako první probíhá na řádcích 1--3 nastavení proměnných, ve kterých se ukládá odkaz na vzdálený Git repozitář, název složky, do které se obsah má klonovat a název složky do které se má kopírovat výstup, nebo-li vygenerované HTML. Dále se skript na řádku 5 přepíná do složky, ve které se sám nachází, proto aby skript fungoval vždy, ať je spuštěný ze kteréhokoliv místa v souborovém systému.
Skript \ref{lst:git-hook-skript} je složen z několika částí. Jako první probíhá na řádcích 1--3 nastavení proměnných, ve kterých se ukládá odkaz na vzdálený Git repozitář, název složky, do které se obsah má klonovat a název složky, do které se má kopírovat výstup, nebo-li vygenerované HTML. Dále se skript na řádku 5 přepíná do složky, ve které se sám nachází, proto aby skript fungoval vždy, ať je spuštěný ze kteréhokoliv místa v souborovém systému.
V další části skriptu probíhá na řádku 7 kontrola, zda již existuje složka s naklonovaným Git repozitářem. Pokud složka neexistuje, provede se naklonování vzdáleného repozitáře a tím i k vytvoření složky.
Třetí část provádí generování statického obsahu. Nejprve se skript přepne do repozitáře, v němž provede příkaz \texttt{git pull}, který do složky stáhne poslední změny ze vzdáleného repozitáře, tedy synchronizuje obsah na poslední verzi. Po synchronizaci repozitáře proběhne samotné spuštění generátoru, který z obsahu vygeneruje statické HTML, jenž vloží do složky \texttt{./public}. Poté na řádcích 12--14 probíhá kopírování nově vygenerovaného obsahu do složky \texttt{/srv/www/ucitelonline}, včetně nastavení Unixových práv na bezpečné hodnoty zvlášť pro složky a soubory.
Třetí část provádí generování statického obsahu. Nejprve se skript přepne do repozitáře, v němž provede příkaz \texttt{git pull}, který do složky stáhne poslední změny ze vzdáleného repozitáře, tedy synchronizuje obsah na poslední verzi. Po synchronizaci repozitáře proběhne samotné spuštění generátoru, který z obsahu vygeneruje statické HTML, jenž vloží do složky \texttt{./public}. Poté na řádcích 12--14 probíhá kopírování nově vygenerovaného obsahu do složky \texttt{/srv/www/ucitelonline}, včetně nastavení Unixových práv souborů na bezpečné hodnoty, které se liší pro složky a pro soubory.
Skript spoléhá na to, že systém má již předem správně nakonfigurované uživatele, uživatelské skupiny, web server, a že jsou nainstalované potřebné programy Git, Rsync, generátor Zola. Systémový uživatel, pod kterým je vyvolán Git hook, musí být ve skupině \textit{www-data}, nebo v jiné skupině společně s uživatelem, pod kterým je spuštěn web server. Zároveň musí mít uživatel práva pro zápis do cílové složky \texttt{/srv/www/ucitelonline}.
Ve světě webových stránek se setkáváme se spoustou forem a paradigmat, která se hodí pro obsažení různých druhů informací. Neexistují žádné formální zařazení druhů webových stránek do skupin, ovšem některé webové portály se pokouší určit základní druhy webů, které se na Internetu objevují. Na základě těchto portálů a jejich rozřazení do skupin\footnote{\url{http://www.xislegraphix.com/website-types.html}}\footnote{\url{https://www.hostgator.com/blog/popular-types-websites-create}}\footnote{\url{https://www.quora.com/What-are-the-different-types-of-websites}}\todo{Přesunout odkazy pod jednu položku.}, které jsou často mířené na specifický obsah, lze vytvořit tři základní paradigmata, do kterých lze tyto weby zařadit. Jsou jimi:
Ve světě webových stránek se setkáváme se spoustou forem a paradigmat, která se hodí pro zpracování různých druhů informací. Neexistuje žádné formální zařazení druhů webových stránek do skupin, ovšem některé webové portály se pokouší určit základní druhy webů, které se na Internetu objevují. Na základě těchto portálů a jejich rozřazení do skupin\footnote{\url{http://www.xislegraphix.com/website-types.html}}\footnote{\url{https://www.hostgator.com/blog/popular-types-websites-create}}\footnote{\url{https://www.quora.com/What-are-the-different-types-of-websites}}\todo{Přesunout odkazy pod jednu položku.}, které jsou často mířené na specifický obsah, lze vytvořit tři základní paradigmata, do kterých lze tyto weby zařadit. Jsou jimi:
\begin{itemize}
\item{Webová prezentace}
@ -15,11 +15,11 @@ V této práci byl ke každému z paradigmat vybrán systém vhodný pro generov
Nejbližší původním webům z dob vzniku WWW jsou webové prezentace, tedy stránky s jednoduchým obsahem, které slouží k předání informací čtenáři například formou článků. Do této skupiny lze zařadit portfolia, blog, online noviny a časopisy, firemní stránky, foto alba a podobně. Tento druh stránek se skvěle hodí ke statickému generování obsahu, který se odesílá všem uživatelům stejný a nemění se často.
Jako nejvhodnější systém pro generování webových prezentací byl vybrán software Zola. Ten je oproti jiným systémům výhodný tím, že je napsaný v jazyce Rust a je tedy snadno rozšiřitelný a mnohem rychlejší, než většina jeho alternativ \citep{benchmarks_game}. I s těmito výhodami si zachovává spousty funkcí a rysů, které lze najít v ostatních složitých systémech. Také je možné generátor zkompilovat do jednoho staticky linkovaného binárního souboru, se kterým se pracuje mnohem lépe, než se složitým frameworkem.
Jako nejvhodnější systém pro generování webových prezentací byl vybrán software Zola. Ten je oproti jiným systémům výhodný tím, že je napsaný v jazyce Rust a je tedy mnohem rychlejší a bezpečnější, než většina jeho alternativ \citep{benchmarks_game}. Kromě těchto výhod si zachovává většinu funkcí a rysů, které lze najít v ostatních složitých systémech. Také je možné generátor zkompilovat do jednoho staticky linkovaného binárního souboru, se kterým se pracuje mnohem lépe, než se složitým frameworkem.
\section{Index všeobecných informací}
Za obecného zástupce tohoto druhu stránek lze považovat Wikipiedii, která podnítila vznik spousty jiných takzvaných \uv{Wiki systémů} a stránek.
Za obecného zástupce tohoto druhu stránek lze považovat Wikipedii, která podnítila vznik spousty jiných takzvaných \uv{Wiki systémů} a stránek.
\chapter{Taxonomie požadavků pro modelový web}\label{kap:taxonomie-pozadavku}
Tato kapitola se věnuje určení základních požadavků pro modelovou implementaci. Jsou zde shrnuta obecná kritéria, která často platí pro většinu webových prezentací, a také kritéria specifická pro modelovou implementaci v rámci této práce. Dle těchto kritérií je poté samotná implementace tvořena v následující kapitole \ref{kap:modelova-implementace}.
Tato kapitola se věnuje určení základních požadavků pro modelovou implementaci. Jsou zde shrnuta obecná kritéria, která platí pro většinu webových prezentací, a také kritéria specifická pro modelovou implementaci v rámci této práce. Dle těchto kritérií je poté samotná implementace tvořena v následující kapitole \ref{kap:modelova-implementace}.
Jako modelová implementace byl zvolen web pro distribuci výukových materiálů a odkazů užitečných pro výuku. Tvorba těchto webových stránek je zadána Ústavem výzkumu a rozvoje vzdělávání Pedagogické fakulty Univerzity Karlovy za účelem usnadnění práce již aktivních učitelů v době šíření viru COVID-19. Stránky mají učitelům pomoci s přípravou distanční výuky a úkolů v době vyhlášení stavu nouze a celostátní karantény. Modelová implementace je tedy plně využívána v praxi mnoha pedagogy z celé republiky. Tuto implementaci lze ovšem použít na distribuci jakýchkoliv jiných výukových materiálů, či ke psaní a správě dokumentace.
@ -16,12 +16,12 @@ Stránky by měly být udržovatelné i po předání jinému správci a celý s
Specifická kritéria jsou vytvořena na základě požadavků autorů obsahu, tedy učitelů, ze kterých každý má své specifické požadavky na funkce a vlastnosti, které musí obsah splňovat. Následující kritéria jsou souhrnem a kompromisem mezi všemi požadavky.
Stránky musí být staticky generované a není tedy žádoucí v rámci webu řešit uživatelské účty, přihlašování apod. Hlavním požadavkem pro sturkturu stránky je možnost dělit obsah na sekce dle druhu školy (základní škola, střední škola, vysoká škola atd.) a dále pak na subsekce podle předmětů a oborů.
Stránky musí být staticky generované a není tedy žádoucí v rámci webu řešit uživatelské účty, přihlašování apod. Hlavním požadavkem pro strukturu stránky je možnost dělit obsah na sekce dle druhu školy (základní škola, střední škola, vysoká škola atd.) a dále pak na subsekce podle předmětů a oborů.
Do samotného obsahu musí být možné vkládat přílohy ke stažení v různých formátech, obrázky a videa s možností jejich ocitování, tedy uvedení autora, názvu díla apod. Všechny přiložené soubory musí být distribuovatelné přímo z webových stránek, nikoliv s externích zdrojů. Všechna videa je nutné vložit do stránky a musí je být možné přehrát v nativním přehrávači prohlížeče bez nutnosti otevírání externích webových stránek či programů. V hlavičce každé stránky musí být možné specifikovat několik metadat: autora či seznam autorů obsahu, skupinu pro kterou je obsah určen a časovou dotaci.
Do samotného obsahu musí být možné vkládat přílohy ke stažení v různých formátech, obrázky a videa s možností jejich ocitování, tedy uvedení autora, názvu díla apod. Všechny přiložené soubory musí být distribuovatelné přímo z webových stránek, nikoliv z externích zdrojů. Všechna videa je nutné vložit do stránky a musí je být možné přehrát v nativním přehrávači prohlížeče bez nutnosti otevírání externích webových stránek či programů. V hlavičce každé stránky musí být možné specifikovat metadata: autora či seznam autorů obsahu, skupinu pro kterou je obsah určen a časovou dotaci.
Obsah stránek musí být možné spravovat předem pověřenými uživateli a jeho změny musí být zaznamenávány v decentralizovaném verzovacím systému. Generování statického webu na základě změn obsahu je nutné řešit automatizovaně bez dalších zásahů správce, či manuálního nahrávání nového obsahu na webserver.
\section{Kritéria pro šablony a design}
Obsah musí být snadno čitelný a zobrazitelný na každém druhu zařízení, tedy jak na monitorech s nadstandardní velikostí, tak na mobilních zařízeních. Zároveň musí být snadno čitelný, v nejlepším případě vysokokontrastní černý text na bílém pozadí s dostatečnou velikostí. Navigace v obsahu musí být jednoduchá a intuitivní a vzhled celé stránky konzistentní. Na stránce nesmí přesahovat objem vizuálních elementů nad obsahem. Relevantní obsah by měl být na jednom místě, nikoliv rozdělený na několik různých stránek, mezi kterými musí uživatel přecházet.
Obsah musí být snadno čitelný a zobrazitelný na každém druhu zařízení, tedy jak na monitorech s nadstandardní velikostí, tak na mobilních zařízeních. Zároveň musí být snadno čitelný, v nejlepším případě vysokokontrastní černý text na bílém pozadí s dostatečnou velikostí. Navigace v obsahu musí být jednoduchá a intuitivní a vzhled celé stránky konzistentní. Na stránce nesmí přesahovat objem vizuálních elementů nad obsahem. Relevantní obsah by měl být na jednom místě, nikoliv rozdělený na několik různých stránek, mezi kterými musí uživatel přecházet.
Lukáš Hozda