Možnosti správy souborů v prostředí aplikace TEXonWeb

Mendelova univerzita v Brně Provozně ekonomická fakulta Možnosti správy souborů v prostředí aplikace TEXonWeb Bakalářská práce Vedoucí práce: Ing. Jan Přichystal, Ph.D. Jan Vavruša Brno 2013

Rád bych poděkoval Ing. Janu Přichystalovi, Ph.D., za vhodné připomínky, náměty a cenné rady během tvorby.

Prohlašuji, že jsem tuto bakalářskou práci vyřešil samostatně s použitím literatury, kterou uvádím v seznamu. V Brně, 20. května 2013...

4 Abstract Vavruša, J. File management options for TEXonWeb application. Bachelor thesis. Brno, 2013. This bachelor thesis is doing a research about file management on the web and suggests one of the possible options for the implementation to TEXonWeb application, based on a previous analysis. The program module has been implemented with HTML, JavaScript and CSS languages, using Google Drive application programming interface. Abstrakt Vavruša, J. Možnosti správy souborů v prostředí aplikace TEXonWeb. Bakalářská práce. Brno, 2013. Bakalářská práce zkoumá problematiku správy souborů na webu a na základě analýzy navrhuje jedno z možných řešení implementace do aplikace pro sazbu dokumentů TEXonWeb. Programový modul je implementován v jazycích HTML, JavaScript a CSS, s využitím rozhraní Google Drive.

OBSAH 5 Obsah 1 Úvod a cíl práce 7 1.1 Úvod.................................... 7 1.2 Cíl práce.................................. 7 2 Současný stav 8 2.1 Typografický systém TEX........................ 8 2.1.1 Stručná charakteristika..................... 8 2.1.2 Výhody a nevýhody....................... 8 2.2 2.1.3 L A TEX............................... 9 TEXonWeb................................. 9 2.2.1 Stručná charakteristika..................... 9 2.2.2 Správa souborů.......................... 10 2.3 Cloud computing............................. 10 2.3.1 Výhody.............................. 10 2.3.2 Nevýhody............................. 10 2.3.3 Model nasazení.......................... 11 2.3.4 Distribuční model........................ 11 2.4 Možnosti integrace cloudových úložišť.................. 12 2.4.1 Google Drive........................... 12 2.4.2 Dropbox.............................. 13 2.4.3 SkyDrive............................. 13 2.4.4 Box................................ 14 2.4.5 Capsa.cz.............................. 15 2.5 Google Drive API............................. 15 2.5.1 Google APIs Console....................... 15 2.5.2 Autentizace a Autorizace..................... 16 2.5.3 HTTP požadavky........................ 16 2.5.4 MIME typy............................ 17 3 Metodika a postup práce 18 3.1 Výběr cloudového úložiště........................ 18 3.2 Výběr programovacího jazyka...................... 18 3.3 Implementace vlastní aplikace...................... 19 3.4 Integrace do prostředí TEXonWeb.................... 19 4 Vlastní práce 21 4.1 Grafické rozhraní aplikace........................ 21 4.1.1 Interakce............................. 21 4.1.2 Okno správce........................... 22 4.1.3 Dialogová okna.......................... 23 4.2 Zprovoznění přístupu k API....................... 23 4.2.1 Zaregistrování aplikace...................... 23

OBSAH 6 4.2.2 Obdržení přístupového klíče................... 23 4.2.3 Odeslání klíče do API...................... 24 4.2.4 Obnovení přístupu........................ 24 4.3 Práce se soubory............................. 24 4.3.1 Kontextová nabídka....................... 25 4.3.2 Výpis souborů.......................... 26 4.3.3 Práce se složkami......................... 27 4.3.4 Nahrávání souborů........................ 27 4.3.5 Kopírování a přesouvání souborů................ 28 4.3.6 Mazání souborů.......................... 29 4.3.7 Přejmenovávání souborů..................... 29 4.3.8 Stahování souborů na disk.................... 29 4.3.9 Otevírání souborů........................ 30 4.3.10 Ukládání souborů......................... 30 5 Diskuze 32 5.1 Zhodnocení přínosu navrženého řešení................. 32 5.2 Nedostatky navrženého řešení...................... 32 5.3 Možnosti rozšíření vytvořené práce................... 33 6 Závěr 34 7 Literatura 35 Přílohy 37 A MIME typy v Google Drive API 38 B Seznam jquery událostí 39

1 ÚVOD A CÍL PRÁCE 7 1 Úvod a cíl práce 1.1 Úvod S příchodem výpočetní techniky se začala převážná část dokumentů sázet počítačem. Desktop Publishing (zkráceně DTP) vznikl již v 80. letech 20. století. Tehdejší společnost Aldus uvedla na trh program pro elektronickou sazbu dokumentů PageMaker, také byly představeny první osobní počítače Macintosh od firmy Apple a později vznikaly další programy jako např. Adobe InDesign, QuarkXpress nebo volně dostupný TEX. Program TEX vyvinul profesor Donald Knuth a jeho cílem bylo především nabídnout lidem možnost kvalitní sazby dokumentů a knih při minimálním úsilí. Od té doby prošel tento software řadou změn, nicméně samotný nástroj TEX se později ukázal jako uživatelsky nepřívětivý a tak začaly vznikat nástavbové programy využívající jeho funkce pomocí jednoduchých maker 1. Díky rostoucí komunitě získal tento software podporu nejrůznějších operačních systémů v podobě nových odvozenin. Mezi ty nejznámější dnes patří např. TEX Live (Linux), MiKTEX (Windows), či MacTEX (Mac OS X). (wikipedia.org, 2004; tug.org, 2011) Po desktopových aplikacích se díky internetu a rozvoji v oblasti webových aplikací začaly objevovat také první webové alternativy. Jednou z nich je také webový DTP systém TEXonWeb, vyvinutý pod záštitou Ústavu informatiky na Mendelově univerzitě v Brně. S příchodem cloudových úložišť se však vývojářům webových aplikací otevírají nové možnosti, a to především při práci se soubory a využití alternativních úložných prostor. 1.2 Cíl práce Cílem této práce je integrovat možnosti cloudových úložišť do prostředí TEXonWeb. Toto řešení je výhodné jak pro uživatele aplikace, tak pro majitele serveru, na kterém jsou uskladněna veškerá data. Pro uživatele využívající cloudové úložiště je hlavní výhodou především možnost mít své soubory na jednom místě a přístupné odkudkoliv. V důsledku toho jsou tedy lokální, v našem případě školní, servery méně zatěžovány a tím odpadá také veškerá zodpovědnost za smazaná uživatelská data. 1 Makra jsou předdefinované posloupnosti znaků, procesů apod.

2 SOUČASNÝ STAV 8 2 Současný stav 2.1 Typografický systém TEX 2.1.1 Stručná charakteristika TEX je systém pro sázení dokumentů, navržený a z velké části vyvinutý Donaldem Knuthem. Systém je dostupný zcela zdarma napříč různými operačními systémy a zahrnuje rozsáhlou komunitu lidí, která se stará o jeho vývoj i nadále. Nejdůležitější části a jádrem systému je překladač, který převádí jednoduchý text na vysázený dokument. Namísto WYSIWYG 2 formátování je totiž zdrojový text nejprve doplněn o příkazy a poté přeložen do publikovatelného formátu (např. PDF). Systém se nejvíce používá v akademické sféře a to převážně v matematice, výpočetní technice, ekonomii, inženýrství, fyzice, statistice nebo psychologii. (wikipedia.org, 2004; tug.org, 2011) 2.1.2 Výhody a nevýhody Oddělení výsledného dokumentu od zdrojového textu s sebou nese řadu výhod i nevýhod a vždy záleží především na osobních preferencích. Jak uvádí publikace (Kočička Blažek, 2004), Grafik, potřebující neustále kontrolovat výsledek své práce, nemá rád prodlevy mezi návrhem a výsledkem. Také ho příliš nebaví programování, které je u většiny programu systému TEX potřeba. Důležitým aspektem je také konkrétní druh dokumentu, který sázíme. Pro sázení reklamních materiálů a letáků je například vhodnější upravovat výsledný návrh, zatímco u sázení knih a dokumentů požadujeme především spolehlivost a přesnost výstupu. Shrňme si však objektivní výhody a nevýhody toho systému v několika bodech. Těmi nejzásadnějšími výhodami mohou být například: preciznost a vysoká kvalita výstupu, přenositelný formát ve formě prostého textu, možnosti zefektivnění a zrychlení práce pomocí maker. Za nevýhody lze pak považovat kupříkladu: velké množství příkazů, které je třeba znát a vědět, kdy který použít, absence WYSIWYG, bez kterého nevidíme výsledek okamžitě (řešením může být aplikace LyX), složitější instalace sazebních nástrojů (řešením může být webový nástroj TEXonWeb). 2 What You See Is What You Get - co vidíš, to dostaneš

2.2 TEXonWeb 9 2.1.3 L A TEX Program L A TEX je postaven na jazyce systému TEX a jeho první verzi vyvinul v roce 1985 Leslie Lamport. Nyní program spravuje a vyvíjí tým lidí jako projekt s názvem L A TEX3, dostupný opět zcela zdarma a financovaný formou dobrovolných příspěvků. Systém je opět oblíbený zejména v akademické sféře, ale využívá se například také při zobrazení matematických vzorců na webu Wikipedia. (latex-project.org, 2010) Mezi hlavní výhody programu L A TEXmůžeme zařadit následující body: sazební systém pro psaní článků, technických zpráv, knih a prezentací, přehled nad rozsáhlými dokumenty s kapitolami, křížovými odkazy, tabulkami a poznámkami, sázení složitých matematických vzorců, automatické generování bibliografie a indexů, sázení vícejazyčného textu, vkládání grafických prvků do dokumentu, využití PostScriptu a Metafont písem. 2.2 TEXonWeb 2.2.1 Stručná charakteristika Aplikace TEXonWeb je nástroj pro zpracování textových dokumentů využívající systém TEX bez nutnosti instalace. Jak autor uvádí ve své dokumentaci (Přichystal, 2006), projekt TEXonWeb je založen na TEX Live 2011 z distribuce Linux CentOS 5.2. Jádro aplikace je napsáno v jazyce Perl a uživatelské rozhraní v jazycích HTML, CSS a JavaScript s knihovnou jquery. Jedním z důvodu vytvoření tohoto nástroje byla možnost nabídnout uživatelům, nejen studentům, snadný a rychlý přístup k systému TEXbez nutnosti jeho instalace, uvádí Přichystal ve svém článku (Přichystal, 2008). Systém prochází neustálým vývojem a pro začínající uživatele je poměrně rozsáhle zdokumentován. Základním prvkem aplikace je editor, který se skládá z textového pole (HTML prvek <textarea>) a panelu nástrojů. Mezi nástroje patří nespočet formátovacích funkcí, maker a speciálních znaků. Součástí editoru je také například program vlna, doplňující nezlomitelné mezery do textu, nebo automatická kontrola pravopisu. K dispozici je také několik šablon s předdefinovaným vzhledem. Jedná se o různé typy dokumentů, se kterými se uživatel může běžně setkat a je zbytečné aby si jej definoval sám. Na příkladu těchto dokumentů se také mohou začínající uživatelé seznámit s definicí vlastních příkazů a stylových souborů., jak je uvedeno v dokumentaci. (Přichystal, 2006) Mezi šablonami lze najít například záverečnou

2.3 Cloud computing 10 práci, dopis, kalendář, životopis a další. Dokumentace také obsahuje podrobnější popis a návod ke každé z nich. Systém nabízí různé překladače (CSL A TEX, L A TEX, XƎL A TEX ) s možností více průchodů a výstup je generován ve formátech PostScript nebo PDF. 2.2.2 Správa souborů Současný správce souborů nabízí možnost práce se soubory uloženými na školním serveru. Rozhraní nabízí kromě standardního výpisu souborů a složek navíc také základní operace nad soubory, např. přejmenovávání či mazání. Nechybí ani nahrávání souborů z lokálního disku nebo vytváření nových složek. Aplikace se otevírá v samostatném dialogovém okně a tudíž při jejím spuštění není potřeba opouštět rozpracovaný dokument. Pokud bychom měli najít nějaké nedostatky, které by se daly v této části aplikace zlepšit, bylo by to kromě absence cloudových řešení také poměrně nepraktické uspořádání grafického rozhraní. 2.3 Cloud computing Myšlenka cloud computingu vznikla již před více než padesáti lety. Tehdejší univerzitní profesor na americké MIT John McCarthy přišel s myšlenkou sdílení počítačových technologií podobně jako je šířena například elektrická energie. V dnešní době cloud computing znamená uskladnění dat na internetu a přístup k nim skrze webové aplikace. Termín cloud (v překladu mrak ) je tedy metaforou pro internet jakožto datové médium. V obchodní sféře má však lehce odlišný význam a rozlišujeme jej podle dvou hledisek - jak je poskytován a jaké služby poskytuje. (wikipedia.org, 2012) 2.3.1 Výhody Kapacita a škálovatelnost minimální finanční a časové náklady na novou infrastrukturu. Zálohování a obnova dat většina poskytovatelů cloudu nabízí kompletní zálohu dat a jejich obnovu při ztrátě. Mobilita přístup do cloudu prakticky odkudkoliv díky internetu. Efektivní výdaje minimalizace nákladů na služby, školení zaměstnanců, energii a další. 2.3.2 Nevýhody Kontrola a spolehlivost nevýhodu lze nalézt i v jeho největší výhodě. Díky tomu, že se nemusíme starat o personální a technický provoz úložiště, při řešení případného problému nelze fyzicky operovat.

2.3 Cloud computing 11 Bezpečnost a soukromí při vkládání soukromých dat (např. o zakázkách či zákaznících) do cloudu nelze nikdy garantovat 100% zabezpečení, i přestože jej většina společností slibuje. Kompatibilita veškerá zařízení, nástroje a programy musí být kompatibilní s webovými službami, platformou nebo infrastrukturou. Neočekávané výdaje přestože lze ušetřit na technickém vybavení, pracovní síle a podobně, výdaje na restrukturalizaci dat a pronájem cloudu se mohou výrazně zvýšit. Nelze tedy cenu považovat za jednoznačnou výhodu. (cloudcomputinginsights.com, 2012) 2.3.3 Model nasazení Tento model kategorizuje cloud podle toho jak je poskytován uživatelům a dělí ho na čtyři typy. Veřejný (public) cloud a data v něm uložená jsou, jak název napovídá, k dispozici široké veřejnosti poskytovatelem služby. Tyto služby bývají zpravidla zdarma nebo za poplatek podle konkrétní spotřeby. Obecně řečeno, poskytovatelé veřejného cloudu, jako jsou společnosti Amazon, Microsoft nebo Google, vlastní a spravují infrastrukturu kterou dále nabízejí přes internet. Přesným opakem je soukromý (private) cloud, jehož infrastrukturu společnost využívá pouze pro své vlastní účely. Zavedení takovéhoto cloudu náročnější, ale dokáže výrazně zlepšit ekonomiku firmy. Komunitní (community) cloud sdílí infrastrukturu mezi několika organizacemi, řešící společné problémy jako je bezpečnost, jurisdikce a podobně. Cena je tedy rozdělena mezi více uživatelů. Kombinaci těchto tří typů nazýváme hybridním (hybrid) cloudem. Tento typ využívá výhod každého z nich. 2.3.4 Distribuční model Některé společnosti implementují takzvaný Software-as-a-Service (SaaS), který funguje na principu předplácení licencí pro užívání softwaru. Obvykle se jedná o systémy pro řízení vztahů se zákazníky, elektronickou poštu, virtuální plochy, komunikační prvky nebo hry. Mezi nejznámnější SaaS aplikace patří například Google Apps nebo Microsoft Office 365. Dalším typem je Platform-as-a-Service (PaaS), díky kterému lze vytvářet vlastní aplikace a distribuovat je v rámci společnosti. Do platforem řadíme například běhové prostředí programů (runtime), databáze, webové servery, vývojové nástroje a podobně. Představiteli jsou například OpenShift, Windows Azure nebo Google App Engine. Třetím typem je Infrastructure-as-a-Service (IaaS), který umožňuje pronájem hotové infrastruktury velkých společností jako je Amazon, Google, Rackspace nebo HP. Typicky jsou to například virtuální stroje, servery, úložiště nebo síťové prvky.

2.4 Možnosti integrace cloudových úložišť 12 Obrázek 1: Logické schéma cloud computingu (wikipedia.org, 2012) V dnešní době je hranice mezi lokálním a cloudovým úložištěm velmi úzká. Hybridní služby, jako je Google Drive, Dropbox a další, jsou charakterizované jako pracující v cloudu, protože ukládají osobní soubory na internetu, ale většina z nich zároveň synchronizuje tyto soubory s těmi na lokálním úložišti. Synchronizace dat, která jsou přístupná z jakéhokoliv zařízení, je základním kamenem cloud computingu, ikdyž práce se soubory probíhá lokálně. (wikipedia.org, 2012; Griffith, 2013) 2.4 Možnosti integrace cloudových úložišť V rámci této práce se zaměřme pouze na současně nejpoužívanější webová úložiště, která jsou dostupná zdarma a jejichž API je vývojářům volně k dispozici. Každá z vybraných služeb využívá bezpečnostního protokolu OAuth pro autentizaci uživatele (viz kapitola 4.2). 2.4.1 Google Drive Společnost Google, jedním z největších hráčů v oblasti webových aplikací. Začala experimentovat s elektronickými dokumenty na webu ve svých původních aplikacích Writely a Google Spreadsheets počínaje rokem 2007, posléze sjednocených do online kancelářského balíku Google Docs.

2.4 Možnosti integrace cloudových úložišť 13 Ačkoliv bylo ze začátku, vzhledem k problematickému a ne zcela kompletnímu API, poměrně nepohodlné s těmito nástroji vyvíjet, s postupem času vznikla spousta změn a vylepšení v podobě nové aplikace s názvem Google Drive a jeho API ve verzi 2. Zdarma nabízí 5 GB prostoru pro data mimo nativní formáty Google dokumentů, které se do této kvóty nezapočítávají. Samozřejmostí je desktopový klient pro operační systémy Windows a Mac OS X, který umožňuje synchronizaci souborů a složek pomocí dedikovaného adresáře na disku. S Linuxovými systémy však služba v současné době nepočítá. Nechybí však podpora mobilních zařízení se systémy Android a ios. Kromě vlastní synchronizace lze data sdílet s dalšími uživateli s Google účtem. (wikipedia.org, 2009) Tabulka 1: Shrnutí základních parametrů úložiště Google Drive (Kvapil, 2012) Parametr Hodnota Volný prostor zdarma 5 GB Maximální velikost souboru 10 GB Rychlost datového přenosu (download, upload) 1000 kb/s, 600 kb/s Česká lokalizace ano API Java,.NET, PHP, Python, Ruby, JavaScript, Go, Objective-C 2.4.2 Dropbox Dropbox jako jeden z prvních zaujal jednoduchým řešením, možností synchronizace lokálních složek a úložným prostorem 2 GB, poskytnutých zdarma ihned po založení účtu. Volný prostor o této kapacitě se jeví jako velká nevýhoda vůči ostatním službám a rozdíl u některých z nich je více než trojnásobný. Dropbox však na rozdíl od svých konkurentů nabízí další způsoby, jak získat zdarma volnou kapacitu navíc. Desktopová aplikace je k dispozici ve verzi pro operační systém Windows, OS X a některé linuxové distribuce. Mobilní verze podporují systémy Android a ios. Dropbox API nabízí vývojářům návody pro programovací jazyky Ruby, Python a Java. Možností je také vývoj mobilních aplikací pro platformy OS X, ios či Android. Data lze sdílet ve specifikovaných složkách pomocí přístupové adresy zaslané e-mailem a zajímavostí je sdílení fotografických alb, které si uživatel může prohlédnout bez nutnosti přihlášení do služby. 2.4.3 SkyDrive I Microsoft nabídnul ve svém portfoliu služeb vlastní řešení, a to již v roce 2007, kdy přišel na trh s novou službou s názvem Windows Live Folders. Postupem času byla přejmenována na Windows Live SkyDrive a dočkala se mnoha podstatných vylepšení. SkyDrive nabízí uživatelům 7 GB volného prostoru zdarma, což je jedna

2.4 Možnosti integrace cloudových úložišť 14 Tabulka 2: Shrnutí základních parametrů úložiště Dropbox (Kvapil, 2012) Parametr Hodnota Volný prostor zdarma 2 GB Maximální velikost souboru neomezená Rychlost datového přenosu (download, upload) 250 kb/s, 430 kb/s Česká lokalizace ne API Ruby a Python, Java, OS X, ios, Android z největších kapacit v současné nabídce. Výhodou může být, podobně jako u Google Drive, přihlášení pomocí jednotného Live účtu, za předpokladu používání více produktů od firmy Microsoft. Dále umožňuje streamování 3 médií, synchronizaci složek a použití skrze aplikace pro Windows, OS X, Windows Phone, ios či Android. Tabulka 3: Shrnutí základních parametrů úložiště SkyDrive (Kvapil, 2012) Parametr Hodnota Volný prostor zdarma 7 GB Maximální velikost souboru 2 GB Rychlost datového přenosu (download, upload) 500 kb/s, 700 kb/s Česká lokalizace ano API JavaScript, C, Objective-C, Java 2.4.4 Box Úložiště Box je orientované svými benefity spíše na firemní zákazníky, avšak i běžnému uživateli poskytne 5 GB bezplatného prostoru pro nahraná data a veřejné API s poměrně přehlednou dokumentací. Programovat aplikace pro Box lze v sedmi jazycích a oficiální klient je k dispozici pro Windows, OS X, ios či Android. Tabulka 4: Shrnutí základních parametrů úložiště Box (Kvapil, 2012) Parametr Hodnota Volný prostor zdarma 5 GB Maximální velikost souboru 100 MB Rychlost datového přenosu (download, upload) 500 kb/s, 700 kb/s Česká lokalizace ne API Python, Ruby, Java, PHP, C, Objective-C, JavaScript 3 nepřetržitý přenos mezi zdrojem a klientem

2.5 Google Drive API 15 2.4.5 Capsa.cz Zajímavostí v této oblasti je cloudové úložiště Capsa.cz, jakožto úspěšný český projekt, který vznikl teprve počátkem letošního roku. Capsa.cz se svými vlastnostmi zaměřuje primárně na zálohování osobních dat a jednou z výhod je např. velký prostor ve svém základu zdarma. Pouze zajímavostí však tato služba také zůstává, jelikož v současné době nenabízí veřejné API a nelze ji tedy využít pro vlastní aplikace. (Tuhý, 2013) Tabulka 5: Shrnutí základních parametrů úložiště Capsa.cz (Kvapil, 2012) Parametr Hodnota Volný prostor zdarma 11 GB Maximální velikost souboru 200 MB Rychlost datového přenosu (download, upload) 1200 kb/s, 750 kb/s Česká lokalizace ano API chybí 2.5 Google Drive API API neboli Application Programming Interface je sada procedur, funkcí a tříd, které má programátor k dispozici pro vývoj aplikací. Google Drive API je velice obsáhle zdokumentováno a nabízí velké množství metod, které lze v aplikacích využít. Výběr programovacích jazyků je na rozdíl od jiných rozhraní velmi široký a výjimkou nejsou ani jazyky pro vývoj mobilních aplikací. Pro vlastní práci jsem zvolil metody pro jazyk JavaScript, ve kterém je prostředí aplikace TEXonWeb implementováno. (wikipedia.org, 2004; developers.google.com, 2013) 2.5.1 Google APIs Console Google APIs Console je grafické rozhraní, které slouží k aktivaci a správě Google API, z nichž každé patří k jednomu či více projektů zároveň. Projekt zahrnuje informace o aplikaci, jako jsou např. autentizační údaje, seznam API, které aplikace využívá, a podobně. (developers.google.com, 2013) Console umožňuje správu těchto informací: Aktivované API základní informace o projektu. Provoz zaznamenávají se informace o návštěvnosti aktivovaných API. Platební údaje v případě enormního zatížení API a překročení lhůty pro návštěvnost je možné ji rozšířit za určitý poplatek. Klíče každý projekt je identifikován pomocí API klíče nebo autentizačního klíče.

2.5 Google Drive API 16 Členové týmu je možné specifikovat jednotlivé členy týmu a opravňovat je k přístupu do Console. 2.5.2 Autentizace a Autorizace Google API používá pro autentizaci a autorizaci protokol OAuth verze 2.0 a nabízí několik postupů zahrnujících desktopové aplikace, přenosná zařízení, webové servery i aplikace na straně klienta psané v JavaScriptu. Protokol OAuth 2.0 je i přes svou složitost relativně jednoduchý na integraci a nastavení. (developers.google.com, 2013) Implementace autentizačního a autorizačního procesu je specifikovaná několika druhy vyvíjených aplikací: 1. Serverové aplikace autorizační server podporuje aplikace psané v jazycích PHP, Java, Python, Ruby, ASP.NET a další. Sekvence začíná přesměrováním prohlížeče na specifikovanou adresu se zadanými parametry, které indikují typ přístupu Google API. Výměnou za autorizační kód aplikace obdrží potřebné klíče. 2. Klientské aplikace jedná se o aplikace psané v JavaScriptu, které běží v prohlížeči. Výstupem sekvence je přístupový klíč, který je následně ověřen. 3. Instalované aplikace ať už desktopové či mobilní, pro systém Windows, Mac OS X, ios nebo Android. I zde probíhá přesměrování pomocí prohlížeče, ať už vnořeného či systémového. Aplikace však musí být při registraci specifikována jako instalovaná pro obdržení speciálních parametrů. 4. Aplikace pro jiná zařízení autorizovat lze také aplikace na zařízeních, jako jsou herní konzole, videokamery, tiskárny a podobně. V tomto případě musí zařízení komunikovat s počítačem, přes který předává potřebné klíče. 2.5.3 HTTP požadavky Protokol HTTP se používá pro komunikaci mezi webovým serverem a prohlížečem. Princip této komunikace spočívá v odeslání požadavku ze strany klienta, tedy prohlížeče, který následně obdrží odpověď ze strany serveru (Kosek, 1999; wikipedia.org, 2011). Google API podporuje tyto HTTP metody: GET získává pouze data ze specifikovaného zdroje. HEAD žádá o stejnou odpověď jako metoda GET, ovšem bez těla zprávy. POST odesílá data na server pomocí formuláře. Používá se pro odesílání většího objemu dat a narozdíl od metody GET nezobrazuje požadavek v URL 4. 4 Uniform Resource Locator - řetězec znaků, který se používá ke specifikaci umístění zdroje informací na internetu

2.5 Google Drive API 17 Obrázek 2: Princip autentizace a autorizace klientské aplikace podle protokolu OAuth 2.0 (developers.google.com, 2013) PUT nahrává data na server, objektem je název souboru. DELETE maže specifikovaný zdroj. TRACE funguje jako zpětná vazba pro klienta, jehož odeslaný požadavek je mu poslán nazpět. OPTIONS odesílá dotaz na server ohledně dostupných metod. CONNECT provádí spojení s objektem. PATCH aplikuje částečné změny na specifikovaném zdroji. 2.5.4 MIME typy Během přenosu souboru je kromě vlastních dat zapotřebí předat také informace o jeho typu, např. že se jedná o textový dokument ve formátu DOC. MIME typ takový soubor specifikuje, a to ve dvou úrovních: typ a podtyp. (Peterka, 2011) Kompletní rozdělení MIME typů, které používá Google Drive API, je kvůli jeho rozsahu umístěno v příloze.

3 METODIKA A POSTUP PRÁCE 18 3 Metodika a postup práce 3.1 Výběr cloudového úložiště Výběr vhodného úložiště je ovlivněn hned několika faktory. Prvním z nich je dostupné API v programovacím jazyce, ve kterém je aplikace implementována. Po stručné analýze jednotlivých řešení zjistíme, že u některých z nich je výběr jazyků značně omezen. Druhým faktorem při výběru je míra použití mezi uživateli, jakožto potencionálními klienty budoucí aplikace. Obrovský boom na poli cloudových služeb s sebou přinesl nepřeberné množství produktů pro osobní použití i firemní klientelu, v různých cenových relacích či zcela zdarma. Podle analýzy americké společnosti IHS isuppli z roku 2012 (storagenewsletter.com, 2012) lze v následujících letech očekávat plynulý nárůst uživatelů cloudových úložišť, a to ve stovkách milionů ročně. Obrázek 3: Předpokládaný nárůst celosvětového počtu uživatelů osobních cloudových úložišť (v milionech) (storagenewsletter.com, 2012) Výhodou Google Drive na rozdíl od ostatních úložišť je velké procento uživatelů e-mailové služby Gmail, kteří Drive získávají automaticky a v základu zdarma. Jejich počet v loňském roce překročil hranici 500 milionů a Gmail se tak stal lídrem mezi poskytovateli e-mailu. Podobným číslem se může chlubit pouze služba Hotmail společnosti Microsoft. Hotmail se začátkem roku 2012 propadl na druhé místo s více než 400 miliony uživatelů. I to je však pro službu SkyDrive nezanedbatelné číslo. Na závěr však nutno podotknout, že statistické údaje (viz Obrázek 4) nezahrnují některé domény, jako např. live.com nebo outlook.com. Také se do nich nezapočítávají uživatelé Google Apps s vlastní doménou. 3.2 Výběr programovacího jazyka Vzhledem k tomu, že rozhraní aplikace TEXonWeb je napsáno v jazycích HTML, CSS a JavaScript s knihovnou jquery, je více než vhodné pokračovat ve vývoji právě v těchto jazycích.

3.3 Implementace vlastní aplikace 19 Obrázek 4: Srovnání největších poskytovatelů e-mailu v počtu uživatelů během období červenec 2011 červenec 2012 (blog.mailchimp.com, 2012) 3.3 Implementace vlastní aplikace Počáteční fázi vývoje rozhraní a funkcí aplikace lze řešit zcela odděleně a nezávisle na hlavním programu. Nejprve je nutné vytvořit jeho základní strukturu a grafické rozhraní v jazycích HTML a CSS. Poté je vhodné implementovat interaktivní prvky (dialogová okna, kontextové nabídky ) v JavaScriptu. Následuje zprovoznění přístupu k API Google Drive, které zahrnuje: obdržení přístupového klíče, odeslání klíče do API, obnovení přístupu. Posledním krokem před samotnou integrací do systému je implementace potřebných metod pro práci se soubory na úložišti Google Drive. 3.4 Integrace do prostředí TEXonWeb Druhou fází v rámci této práce je nasazení vlastního programu do aplikace TEXonWeb. Řešení lze pojmout jako zásuvný modul a v této fázi by měl být tedy funkční, nejen z hlediska vlastní přidané hodnoty, ale také v souvislosti s původní

3.4 Integrace do prostředí TEXonWeb 20 aplikací, se kterou by měl být již plně kompatibilní. Integrace modulu zahrnuje několik kroků: 1. Implementaci interakce s textovým polem editoru. Soubory z cloudového úložiště by mělo jít otevírat v editoru a ukládat nazpět. 2. Zakomponování grafického rozhraní do okna správce. Uživatel bude mít možnost využít obě úložiště v jednom okně. 3. Přizpůsobení grafického stylu současného rozhraní. Obrázek 5: Schéma integrace cloudového úložiště do prostředí TEXonWeb

4 VLASTNÍ PRÁCE 21 4 Vlastní práce 4.1 Grafické rozhraní aplikace Rozhraní aplikace je vytvořeno v jazyce HTML, jehož základní struktura se podobá struktuře běžných webových stránek. Inspiraci při návrhu grafických prvků lze najít v současných souborových manažerech jednotlivých úložišť, jakou jsou např. Google Drive, Dropbox a další. Jedním z hlavních uživatelských požadavků na webovou aplikaci je dobrá použitelnost. Je tedy důležité dbát při vývoji nejen na funkční požadavky aplikace, ale také na způsob interakce s uživatelem. V této práci se nebudeme příliš zaobírat problematikou grafického ztvárnění aplikace, přesto je dobré dbát alespoň na její základní grafickou úpravu. 4.1.1 Interakce Interakce zajišťují události (anglicky Events ), které jsou součástí knihovny jquery. Události jsou veškeré akce, které detekuje webová aplikace, jako je například kliknutí tlačítka na myši, načtení stránky, odeslání formuláře a podobně. Každé události lze tedy přiřadit jakoukoliv akci, která se provede při jejím spuštění. Tato funkce se nazývá event handler. Ke každé události je přiřazen HTML prvek, ke kterému se vztahuje. Přiřazení lze v jquery zapsat dvěma způsoby. Tím prvním je použití funkce bind(), která prostřednictvím svých parametrů spojuje událost s určitou funkcí: $( # idprvku ). bind ( n á z e v U d á l o s t i, f u n c t i o n ( ) { kód funkce } ) ; Druhým způsobem je nahrazení funkce bind() za funkci live(). V takovém případě jsou události přiřazeny také prvkům, které byly vytvořeny po načtení stránky. To je vhodné zejména pro dynamické webové aplikace, kde funkce bind() nemusí fungovat. (Holzner, 2003; Holzner, 2007; api.jquery.com, 2013) Pro správný chod interakcí a funkcí v JavaScriptu v aplikaci bylo využito několik potřebných knihoven a skriptů: jquery.js - javascriptová knihovna, používá CSS selektory k přístupu a manipulaci prvků HTML. Také nabízí vlastní prvky uživatelského rozhraní a různé doplňky jsapi - Google Drive API v online verzi dostupné na webu. client.js - knihovna pro autorizaci a autentizaci aplikace. rfc3339date.js - externí skript pro převod data z formátu ISO 8601 na RFC 3339 a naopak.

4.1 Grafické rozhraní aplikace 22 4.1.2 Okno správce Hlavním požadavkem při navrhování uživatelského rozhraní bylo zahrnout do stávajícího rozhraní správce souborů novou službu v podobě sekundárního úložiště. Řešení by však nemělo příliš vybočovat ze stávajícího grafického stylu aplikace a bylo tedy zapotřebí jej zakomponovat s ohledem na dobrou použitelnost při práci se soubory. Rozhraní hlavního okna správce souborů se skládá ze tří hlavních části. V záhlaví okna je umístěno přepínání mezi úložišti a tlačítka pro nahrávání souborů a vytváření nových složek, která jsou u obou úložišť na pohled identická. Pod záhlavím je umístěna kontextová nabídka pro práci se soubory, společně s výpisem souborů do tabulky. Z hlediska implementace je přepínání mezi úložišti vyřešeno pomocí CSS a jquery a princip spočívá ve skrývání a odkrývání specifikovaných prvků na stránce. Každý prvek, který má být zobrazen, má vlastnost display: block (v opačném případě display: none ) zapsanou v kaskádových stylech. (Staníček, 2003) Zápis příkazu pro modifikaci této vlastnosti v jquery bude vypadat následovně: $ ( u l#top menu ). c s s ( d i s p l a y, none ) ; Obrázek 6: Drátěný model grafického rozhraní správce souborů

4.2 Zprovoznění přístupu k API 23 4.1.3 Dialogová okna Práci s okny lze pojmout podobně jako u současných operačních systémů, kde je každý podprogram zobrazen v samostatné vrstvě. Díky tomu uživatel nemusí opouštět aktuální prostředí aplikace a případně rozpracovanou práci. Toto řešení lze vidět také u současných cloudových úložišt. Zobrazování oken je řešeno stejným způsobem, jakým se zobrazují prvky v hlavním okně správce (viz předchozí kapitola). Všechna dialogová okna jsou při spuštění aplikace skryta a zobrazují se podle typu metody, která je volána. Rozlišujeme je podle těchto metod: nahrávání souborů, mazání souborů, kopírování a přesouvání souborů, přejmenovávání souborů, vytváření složek. 4.2 Zprovoznění přístupu k API 4.2.1 Zaregistrování aplikace Všechny aplikace, které přistupují ke Google API, musí být zaregistrovány v APIs Console. Výsledkem registračního procesu je několik hodnot, potřebných pro API i samotnou aplikaci. Jedná se především o hodnoty client_id, client_secret, JavaScript origins, redirect_uri, nicméně konkrétní výběr se liší podle typu vyvíjené aplikace. Aplikace v JavaScriptu například nevyžaduje hodnotu client_secret. Obrázek 7: Obdržení přístupových hodnot potřebných pro komunikaci aplikace s Google API (developers.google.com, 2013) 4.2.2 Obdržení přístupového klíče Před samotným přístupem k API musí aplikace obdržet přístupový klíč, který jí dodá potřebná oprávnění. Jeden takový klíč lze použít k oprávnění přístupu k několika API současně. Veškeré operace s API jsou kontrolovány během žádosti o přístupový klíč pomocí parametru scope, jež může být během tohoto procesu několik.

4.3 Práce se soubory 24 Typů přístupových žádostí je více a opět závisí na typu aplikace. Aplikace psaná v JavaScriptu obdrží přístupový klíč po přesměrování internetového prohlížeče na server Google, zatímco desktopová aplikace bez prohlížeče využívá webových služeb. Při žádosti je potřeba přihlášení uživatele pod svým Google účtem, po kterém je požádán o povolení pro práci s daty. Z pohledu uživatele probíhá autentizace pomocí standardizovaného dialogového okna. Pokud uživatel udělí toto povolení, do aplikace je odeslán přístupový klíč a autorizační kód. 4.2.3 Odeslání klíče do API Po obdržení přístupového klíče může aplikace zasílat požadavky na Google API. Přístupové klíče jsou použitelné pouze pro vybrané operace a prostředky, specifikované v požadavku. To znamená, že například při požadavku na Google+ 5 API nelze žádat o povolení přístupu do Google Contacts 6 API, a podobně. 4.2.4 Obnovení přístupu Každý přístupový klíč je časově omezen a v některých případech je nutné přistupovat k API v delším časovém úseku. V takovém případě aplikace obdrží takzvaný refresh token, který povolí aplikaci získat nový klíč. (developers.google.com, 2013) 4.3 Práce se soubory V této kapitole se budeme zabývat implementací dílčích funkcí aplikace, potřebných pro práci se soubory z Google Drive. Google Drive API obsahuje rozsáhlé množství metod, které lze využít, a jimiž se budeme podrobněji zabývat v následujících podkapitolách. Tyto úkony lze provádět, jak na jednotlivých souborech, tak i na více souborech zároveň pro zrychlení práce. Výběr více souborů pomocí klávesy Ctrl popisuje následující funkce, kde třída selected označuje vybrané položky, a proměnná s názvem poc udává jejich počet. $ ( div#l i s t t a b l e t r : not(# r o o t ) ). l i v e ( c l i c k, f u n c t i o n ( e ){ i f ( e. c t r l K e y ) { i f ( $ ( t h i s ). h a s C l a s s ( s e l e c t e d ) ) { poc ;} e l s e { poc++;} } e l s e { $ ( div#l i s t t a b l e t r ). removeclass ( s e l e c t e d ) ; poc = 1 ; } ; $ ( t h i s ). t o g g l e C l a s s ( s e l e c t e d ) ; } ) ; 5 Internetová sociální síť pro sdílení obsahu. 6 Nástroj pro správu kontaktů.

4.3 Práce se soubory 25 Tato hodnota je důležitá pro funkce, jako je přesouvání, kopírování a mazání, které při splnění podmínky poc > 1 proběhnou cyklicky a právě v tolika cyklech, kolik je vybráno souborů. K souborům obecně přistupujeme pomocí metod, které nabízí Google Drive API. Výpis těchto metod obsahuje následující tabulka: Tabulka 6: Metody přístupu k souborům pomocí Google Drive API (developers.google.com, 2013) Metoda Popis Get získává metadata souboru pomocí jeho ID Insert vytváří nový soubor Patch aktualizuje metadata souboru Update aktualizuje metadata souboru nebo jeho obsahu Copy vytvoří kopii specifikovaného souboru Delete natrvalo vymaže soubor podle jeho ID List vytvoří seznam souborů ve složce Touch nastaví čas poslední změny souboru na aktuální Trash přesune soubor do koše Untrash obnoví soubor z koše 4.3.1 Kontextová nabídka Kontextová nabídka, stejně jako u desktopových aplikací, umožňuje rychlou a intuitivní práci se soubory. Po kliknutí na pravé tlačítko myši nad souborem se zobrazí dialogové okno s úkony, které lze nad souborem provést. Při výběru více souborů najednou se kontextová nabídka automaticky zobrazí v horní liště. Nabídka je graficky přizpůsobena vzhledu aplikace pomocí kaskádových stylů. Při zobrazení nabídky je nutné, aby její pozice odpovídala pozici kliknutí myši na stránce. Ukažme si tedy, jak lze tento problém řešit pomocí jquery a CSS. Mějme HTML prvek nečíslovaného seznamu <ul> s identifikátorem menu. Tento prvek bude reprezentovat okno s nabídkou, v němž budou obsaženy odkazy na jednotlivé metody. Nejprve je potřeba přidat seznamu vlastnosti, které mu umožní správné napozicovaní: position: absolute - absolutní pozice prvku, width: 150px - pevná šířka o velikosti 150 pixelů 7. Takto nastylovaný prvek nyní napozicujme v jquery. Absolutní pozice je v kaskádových stylech specifikována vždy dvěma rozměry udávanými v pixelech: 1. top - vzdálenost od horního okraje okna prohlížeče, 7 Bezrozměrná jednotka rastrové grafiky, reprezentující obrazový bod.

4.3 Práce se soubory 26 Obrázek 8: Grafické rozhraní kontextové nabídky 2. left - vzdálenost od levého okraje okna prohlížeče. Dalším krokem je přiřazení události contextmenu pomocí funkce live() (viz kapitola 4.1.1). Jako akční parametr události (event handler) nakonec implementujme funkci showmenu, která modifikuje styl seznamu: f u n c t i o n ( showmenu ) { $ ( u l#menu ). c s s ({ top : showmenu. pagey 10+ px, l e f t : showmenu. pagex 10+ px } ). show ( ) ; r e t u r n f a l s e ; } ; Funkce pagex a pagey zde představují pozici kurzoru po kliknutí myší na horizontální a vertikální ose. Hodnoty jsou udány opět v pixelech. 4.3.2 Výpis souborů Výstup s veškerými informacemi o souborech zajišťují dvě metody. První v pořadí je metoda get. Funkce pracující s touto metodou převezme identifikátor složky (tj. souboru), která má být otevřena, formou parametru fileid. Následuje metoda list, která má na starost výpis souborů na výstup a je specifikována těmito parametry: q - identifikátor složky, maxresults - maximální počet zobrazených výsledků. Výstupem je množina tabulkových řádků <tr>, naplněných údaji o souborech, jako je název, velikost a datum poslední změny. Seznam souborů lze libovolně uzpůsobovat

4.3 Práce se soubory 27 a omezovat podle jejich atributů. Pro účely této práce jsou ve výpisu ponechány pouze soubory, které nejsou skryté, zamknuté, ani umístěné v koši. 4.3.3 Práce se složkami Složky v aplikaci Google Drive jsou ve skutečnosti soubory s MIME typem application/vnd.google-apps.folder a bez koncovky. Pracujeme s nimi tedy obdobně. Každá složka je identifikována pomocí názvu (title), rodičovských adresářů (parents) a samotného MIME typu (mimetype). Díky těmto parametrům lze využít stávající funkci vypisující soubory (viz předchozí kapitola) a nahradit její parametry za tyto. (developers.google.com, 2013) Obsah každé složky je doplněn o odkaz, díky kterému se lze vrátit zpět, o úroveň výše v adresářové struktuře. Funkce pro výpis zůstává v tomto případě nezměněna a mění se pouze parametr, kterým je identifikační kód otevřené složky, uložený do proměnné last_folder. Funkční sekvence po kliknutí na odkaz pak vypadá následovně: $ ( t r#r o o t td a ). l i v e ( c l i c k, f u n c t i o n ( ) { r e t r i e v e A l l F i l e s I n F o l d e r ( l a s t _ f o l d e r ) ; p r i n t P a r e n t s ( l a s t _ f o l d e r ) ; a c t i v e _ f o l d e r = l a s t _ f o l d e r ; } ) ; 4.3.4 Nahrávání souborů Google Drive API umožňuje nahrávat binární data nebo multimediální soubory. Pro větší kontrolu nahrávaných dat lze přidat do specifikace následující kritéria: maximální velikost souboru, podporované MIME typy souboru. Samotná metoda pro nahrávání odesílá požadavek metodou POST a má tři různé typy, specifikované parametrem uploadtype. První metodou je jednoduché nahrávání (specifikace uploadtype=media), která zvládá rychlý přenos menších souborů o velikosti 5 MB a méně. Další metodou je takzvané mnohonásobné nahrávání (specifikace uploadtype=multipart) pro nahrávání menších souborů, společně s metadaty v jednom požadavku. Třetí možností je obnovitelné nahrávání, které lze kdykoliv pozastavit. Tato varianta je vhodná především pro větší soubory, kdy spolehlivý přenos je pro uživatele prioritou. Velikost nahraného souboru nesmí překročit 10 GB. (developers.google.com, 2013) Následuje ukázka části funkce pro nahrávání, kde je tento typ metody specifikován: var r e q u e s t = gapi. c l i e n t. r e q u e s t ({ path : / upload / d r i v e /v2/ f i l e s,

4.3 Práce se soubory 28 method : POST, params : { uploadtype : multipart }, headers : { Content Type : m u l t i p a r t /mixed ; boundary = + boundary + }, body : multipartrequestbody } ) ; 4.3.5 Kopírování a přesouvání souborů Prvním krokem při kopírování souborů je výběr cílového adresáře. Dialogové okno pro kopírování obsahuje seznam existujících složek na vzdáleném úložišti, vložený do prvku <select> pro rychlý výběr. Implementace seznamu položek je podobná funkci pro výpis souborů (viz. kapitola 4.3.2) a liší se pouze v omezení na výstupu, jímž jsou pouze složky. Funkce využívá metodu copy a odesílá HTTP požadavek metodou POST. Jejími parametry jsou: fileid - identifikátor souboru, count - pořadí vybraného souboru, pocet - počet vybraných souborů. f u n c t i o n c o p y F i l e ( f i l e I d, count, pocet ) { var f o l d e r I d = $( # f o l d e r t r e e ). v a l ( ) ; var r e q u e s t = gapi. c l i e n t. d r i v e. f i l e s. copy ({ f i l e I d : f i l e I d, method : POST, r e s o u r c e : { parents : [ { id : f o l d e r I d } ] } } ) ; r e q u e s t. e x e c u t e ( f u n c t i o n ( r e s p ) { i f ( count+1 == pocet ){ r e t r i e v e A l l F i l e s I n F o l d e r ( a c t i v e _ f o l d e r ) ; } ; } ) ; } Ačkoliv se kopírování a přesouvání jeví jako dva různé procesy, ve skutečnosti se jedná o jeden. Google Drive API prakticky nenabízí samostatnou metodu pro přesun souboru. Její implementace je tedy řešena stejně jako u kopírovací funkce, pouze s tím rozdílem, že původní soubor je po dokončení procesu smazán metodou delete.

4.3 Práce se soubory 29 4.3.6 Mazání souborů Aby nedošlo k úplně ztrátě souborů po jejich nechtěnému smazání, je vhodnější implementovat metodu trash namísto delete, která soubory pouze přesouvá do koše. Funkce pro mazání napsaná v jazyce JavaScript potom vypadá následovně: f u n c t i o n t r a s h F i l e ( f i l e I d, count, pocet ) { var r e q u e s t = gapi. c l i e n t. d r i v e. f i l e s. t r a s h ({ f i l e I d : f i l e I d } ) ; r e q u e s t. e x e c u t e ( f u n c t i o n ( r e s p ) { i f ( count+1 == pocet ){ r e t r i e v e A l l F i l e s I n F o l d e r ( a c t i v e _ f o l d e r ) ; } ; } ) ; } 4.3.7 Přejmenovávání souborů Pro přejmenování souborů využijme metodu patch, která se používá pro aktualizaci metadat. Tato metoda je vhodná při aktualizaci pouze částečného množství polí. Oproti metodě update, která aktualizuje vždy celý soubor, tak může pomoci zrychlit a zefektivnit přenos dat. Funkce přebírá v parametrech identifikátor fileid a nový název souboru newtitle: f u n c t i o n renamefile ( f i l e I d, newtitle ) { var r e q u e s t = gapi. c l i e n t. d r i v e. f i l e s. patch ({ f i l e I d : f i l e I d, r e s o u r c e : { t i t l e : newtitle } } ) ; r e q u e s t. e x e c u t e ( f u n c t i o n ( r e s p ) { r e t r i e v e A l l F i l e s I n F o l d e r ( a c t i v e _ f o l d e r ) ; } ) ; } 4.3.8 Stahování souborů na disk Kromě dokumentů na Google Drive lze stahovat veškerá data, která jsou zde uložena. Funkce přebírá parametr fileid a následně odesílá dva HTTP GET požadavky: 1. Získat URL adresu, obsaženou v metadatech souboru. 2. Pomocí této adresy získat obsah souboru. Google API v závislosti na typu stažení rozlišuje tři URL adresy (developers.google.com, 2013): 1. Stažení souboru získáním adresy downloadurl. Tuto adresu lze získat z metadat souboru pomocí metody get nebo list.

4.3 Práce se soubory 30 2. Součástí souboru je URL adresa exportlinks pro různé konverzní formáty Google Documents. 3. Soubor mohou stahovat i neautorizovaní uživatelé pomocí webového prohlížeče a bez použití API skrze URL adresu webcontentlink. 4.3.9 Otevírání souborů Nejdříve je potřeba nalézt prvek <textarea>, do kterého se vkládají data ze souboru. Formulářový prvek <textarea> je víceřádkové textové pole, které může obsahovat pouze prostý text. Pro práci s TEX dokumenty je však zapotřebí plnohodnotný editor, proto je součástí aplikace TEXonWeb plnohodnotný textový editor s možnostmi formátování, maker a dalších funkcí. Implementací takového editoru je prvek <textarea>, který je vnořen do plovoucího rámce <iframe>. Při použití skriptů v jquery na straně prohlížeče ovšem vzniká problém s vložením obsahu do takto vnořeného textového pole, jelikož jeho standardní metody pro dosazení hodnoty text() či html() v tomto případě selžou. Sestavme tedy funkci, která takovéto pole dokáže rozpoznat. Funkce bude pracovat s dvěma proměnnými, které pojmenujme iframe a iframebody. Do první proměnné dosaďme prvek na stránce, který má identifikátor s názvem iframe. Nyní je potřeba najít prvek s názvem body. Tentokrát však nepracujme s celou stránkou, ale pouze s obsahem prvku <iframe>, který jsme dosadili do první proměnné. Nalezený prvek dosadíme do druhé proměnné s názvem iframebody a tím jsme našli tělo rámce, ve kterém by se měl nacházet námi hledaný prvek <textarea>. Na závěr jeho obsah vypišme pomocí standardní jquery metody innerhtml(). Celá funkce pak bude vypadat takto: f u n c t i o n t e x t a r e a ( ) { var iframe = document. getelementbyid ( iframe ) ; var iframebody = iframe. contentdocument. getelementsbytagname ( body ) [ 0 ] ; r e t u r n iframebody. innerhtml ; } Nyní, když máme přístup k obsahu textového pole, využijme těchto příkazů ve funkci, která získá data ze souboru uloženém na Google Drive. Funkce použije metodu get s parametrem fileid, podle kterého je soubor specifikován. Získaná data touto metodou nyní dosaďme do těla rámce, neboli proměnné s názvem iframe- Body. 4.3.10 Ukládání souborů Při ukládání souborů na Google Drive je potřeba rozlišovat dva různé způsoby: První možností je uložení dat, převzatých z textového editoru, do nového souboru, který je zároveň potřeba vytvořit. V tomto případě použijeme metodu insert, která odešle požadavek metodou POST. Její implementace se podobá

4.3 Práce se soubory 31 metodě pro nahrávání souborů, rozdíl je však v naplnění souboru konkrétními daty. Při takovémto vytvoření souboru tedy dojde k nahrání souboru, jehož název je definován uživatelem, obsah hodnotou textového pole editoru a ostatní metadata jsou předdefinována samotným programem. Druhým způsobem je zápis do již existujícího souboru. V takovém případě je vhodná metoda update, která pomocí HTTP požadavku metodou PUT aktualizuje metadata či obsah souboru. Opět se jedná o nahrávací funkci, identifikátor a název souboru se ale tentokrát přebírá z parametru.

5 DISKUZE 32 5 Diskuze 5.1 Zhodnocení přínosu navrženého řešení Hlavní výhody a nevýhody cloud computingu byly zmíněny již v úvodu, v rámci této práce se však zaměřme především na praktický přínos výsledné aplikace. Největším přínosem pro uživatele je rozšíření možností pro ukládání a práci se soubory. Uživatelé, kteří mají vlastní Google účet, tak mohou své soubory například sdílet s ostatními. Výhodu mohou najít i uživatelé, kteří využívají služby Google Drive jako vzdálený disk pro svá data, kde mohou mít všechny dokumenty pohromadě. Úložiště nabízí prostor o kapacitě 5 GB zdarma a velikost nahraného souboru je omezena na 10 GB (2 MB na současném úložišti), který lze využít například při práci s fotkami a většími obrázky. Na trhu existuje spousta nástrojů pro ukládání a synchronizaci dat v cloudu, téměř žádný z nich však nenabízí čistě webové řešení. Srovnejme tedy vlastní řešení s nástroji, které jsou v současné době k dispozici: Otixo - webová aplikace pro správu souborů, spojující více cloudových úložišť pod jedním uživatelským účtem. Výhodami jsou např. vyhledávání souborů, zobrazování náhledů a kopírování mezi jednotlivými úložišti. Mezi podporované služby patří např. Dropbox, Box, SkyDrive, Google Drive, SugarSync, Picasa, CX, Amazon S3 a spousta dalších. Tato služba je zpoplatněna formou měsíčního či ročního předplatného, a zdarma je pouze po zkušební dobu 14 dní. Příjemnou vlastností je jednoduché a uživatelsky přívětivé grafické rozhraní. Primadesk - podobně, jako služba Otixo, podporuje většinu současných úložišť a nabízí také vlastní úložný prostor pro data. Narozdíl od ní je však nabídnuta v omezené verzi zdarma, která poskytuje prostor o kapacitě 100 MB a možnost přidat až 5 libovolných úložišť. Grafické rozhraní aplikace je ovšem poněkud nepřehledné. 5.2 Nedostatky navrženého řešení Několik nedostatků vyšlo najevo již při implementaci některých funkcí. Google Drive API nabízí rozsáhlou a poměrně přehlednou dokumentaci, možnosti práce se soubory v něm však nejsou neomezené. Při výpisu souborů například nelze pracovat s atributem pro kódování textového souboru, jelikož takový zde nenajdeme. Poměrně výrazným nedostatkem se také v určitých situacích může jevit rychlost aplikace a načítání dat z Google Drive, což by vyžadovalo hlubší optimalizaci a zefektivnění kódu. Druhotným nedostatkem je na pohled zřejmá grafická nesourodost některých prvků, vzhledem k tomu, že práce nebyla primárně zaměřena na grafickou úpravu aplikace.