Mendlova zemědělská a lesnická univerzita. Ajax komunikátor

Transkript

1 Mendlova zemědělská a lesnická univerzita Provozně ekonomická fakulta Ajax komunikátor Bakalářská práce Vedoucí práce: Ing. Roman Malo, Ph.D. Brno 2008 Ivo Štork

2

3 Prohlašuji, že jsem bakalářskou práci vyřešil samostatně s použitím literatury, kterou uvádím na konci. V Brně, dne:...

4 Rád bych poděkoval vedoucímu mé bakalářské práce Ing. Romanu Malovi, Ph.D. za inspiraci k vytvoření kvalifikační práce na téma Ajax. Dále bych rád poděkoval rodičům za jejich trpělivost a finanční podporu v době studia.

5 Abstract Štork, Ivo. Ajax communicator. Bachelor thesis. Brno, This text describes obstacles and advantages of creating web applications via Ajax. The main part of thesis solves the implementation of communicator for web users. Key words instant messenger, communicator, Ajax, web application, DHTML, asynchronous communication, Javascript, XML Abstrakt Štork, Ivo. Ajax komunikátor. Bakalářská práce. Brno, Práce se zabývá problematikou využití AJAX v rámci webových aplikací. Konkrétně je zde řešena implementace rozhraní, které umožňuje komunikaci mezi uživateli webové stánky. Klíčová slova komunikátor, Ajax, webová aplikace, DHTML, asynchronní komunikace, Javascript, XML

6 Obsah 1 ÚVOD A CÍL PRÁCE ÚVOD CÍL PRÁCE AJAX A RIA RIA APLIKACE TECHNOLOGIE TVORBY RIA APLIKACÍ AJAX JAKO POJEM XMLHTTPREQUEST ASYNCHRONNÍ PŘENOS DAT Asynchronní přenos Princip asynchronní komunikace XML, HTML a CSS PŘÍKLADY POUŽITÍ VÝHODY PŘEKÁŽKY A ÚSKALÍ VHODNÉ UMÍSTĚNÍ APLIKACE METODICKÁ VÝCHODISKA ŘEŠENÍ JAVASCRIPT KNIHOVNA POLLING FORMÁT PŘENÁŠENÝCH DAT XML JSON IMPLEMENTACE KOMUNIKÁTORU SPECIFIKACE KOMUNIKÁTORU KNIHOVNA PROTOTYPE POLLING JSON FUNKČNOST KOMUNIKÁTORU Instalace, přihlášení, odhlášení Seznam kontaktů Zprávy Táhni a pusť POROVNÁNÍ AJAX KOMUNIKÁTORU S ALTERNATIVAMI INSTANT MESSENGER MEEBO ICQ DISKUSE DISKUSE ZÁVĚR ZÁVĚR SEZNAM POUŽITÉ LITERATURY...35 PŘÍLOHY...36

7

8 1 Úvod a cíl práce 1.1 Úvod Komunitní portály 1 nabízí v dnešní době uživatelům mnoho nástrojů pro jejich vzájemnou interakci. Obecně by se tyto nástroje daly rozdělit do dvou skupin. První skupinu reprezentují klasická diskusní fóra nebo komentáře pod článkem. Tato skupina se vyznačuje tím, že komunikace mezi uživateli má značnou latenci. Uživatelé totiž nečekají u monitoru na okamžitou odpověď, protože netuší, jestli vůbec někdo na příspěvek zareaguje. Druhou skupinu tvoří komunikace, která probíhá prakticky v reálném čase. Zde mohou uživatelé komunikovat ve veřejném, případně privátním chatu. Nové přístupy k tvorbě dynamických webových aplikací, nám ovšem umožňují další alternativu tzv. real time komunikace. A sice komunikátor fungující na principu klasické desktop aplikace, jako je například icq, který je ovšem přístupný pouze uživatelům daného webu. Webová aplikace, podobná klasické desktop aplikaci icq, je dle mého názoru velmi silný nástroj sociálního portálu, který potěší stávající uživatele a zároveň může přilákat nové. Vzhledem k mému zájmu o relativně nový pojem Ajax, jsem si zvolil jako téma bakalářské práce implementaci podobného komunikátoru právě pomocí technologií, které reprezentuje pojem Ajax. 1.2 Cíl práce Cílem této práce je implementace Ajax komunikátoru a jeho srovnání se stávajícími alternativami na webu. Aplikace musí být uživatelsky přívětivá, neměla by plýtvat systémovými prostředky serveru a měla by oproti alternativám nabídnout něco nového. K úspěšnému zvládnutí stanovených problémů je nutné důkladně se seznámit s problematikou Ajax a s nasazením Ajax při tvorbě komunikátoru. Jako vzor pro srovnání s mým komunikátorem jsem si zvolil aplikaci IM

9 2 Ajax a RIA 2.1 RIA aplikace Ajax je součástí množiny aplikací se jménem RIA (Rich Internet Applications). RIA ve zkratce označuje aplikaci, která má setřít rozdíl mezi klasickou desktop aplikací a webovou aplikací. RIA aplikace se snaží vypadat jako desktop aplikace a vyvolat v uživateli pocit, že webová aplikace, se kterou pracuje, nekomunikuje se serverem. Vznik RIA aplikací byl zapříčiněn celosvětovým trendem, dělat webové stránky uživatelsky přívětivější. Čím přívětivější je naše stránka k uživatelovi (snadnost použití aplikací), tím větší má návštěvnost. RIA aplikace ovšem nemusí být pouze webovou aplikací. V současnosti se mnoho desktop programů pyšní nálepkou RIA aplikace. V tomhle případě se jedná o klasickou desktop aplikaci, která je ovšem závislá na konkrétní webové aplikaci (např. ebay Desktop 3 ). RIA aplikace se začínají uplatňovat i na mobilních zařízeních. Zde je ovšem zatím plno překážek (nutnost neustálého připojení k internetu, slabá podpora moderních technologií v mobilu), tím pádem je zde implementace RIA aplikací na samotném počátku. Pro jednodušší znázornění, jakých platforem se vlastně RIA problematika dotýká, jsem přiložil následující diagram. Obr. 1: RIA diagram 3 7

10 2.2 Technologie tvorby RIA aplikací RIA aplikace obecně rozdělujeme do dvou skupin podle použitých technologií. Aplikace je vytvořena buď pomocí Ajax, kde jsou vývojáři odkázání na schopnost webového prohlížeče interpretovat Javascript, CSS a XHTML (viz obr.1 Web/HTML), nebo je vytvořena pomocí technologie, kterou webový prohlížeč nezná a potřebuje příslušný plugin k její interpretaci (viz obr.1 Pluginy prohlížečů). Následující diagram rozděluje RIA aplikace v závislosti na použitých technologiích. Obr. 2: RIA technologie Na závěr shrnutí jakou by RIA aplikace měla mít charakteristiku (Borek, 2008): Existuje silná spojitost s webem, respektive s internetem. Například MS Word umí z webu získávat nápovědu nebo tam hledat nové šablony, ale i kdyby internet neexistoval, Word by měl svůj smysl a účel. Naproti tomu například ebay Desktop si bez internetu vůbec nelze představit, ačkoli se třeba krátkodobě bez připojení obejde. Proto MS Word RIA není, zatímco ebay Desktop je. Možnosti uživatelského rozhraní se blíží tradičním desktop aplikacím, uživatel očekává věci typu rychlá odezva, drag&drop, klávesové zkratky a podobně. To je důvod, proč se mluví o bohatých internetových aplikacích. Snadnost spuštění aplikace se blíží snadnosti navštívení webové stránky, jinými slovy instalační proces buďto vůbec neexistuje, nebo je extrémně snadný. Tento bod je důvod, proč se třeba MS Outlook za RIA nepovažuje ačkoli by předchozí dva body více méně splňoval, existence dlouhého instalačního 8

11 procesu a závislost na Windows vytváří příliš velké bariéry pro snadné spuštění kdekoli. 2.3 Ajax jako pojem Ajax může být v souvislosti s tvorbou webových aplikací často zaměněn za technologii jako takovou. Taková interpretace je ovšem nepřesná. Ajax není konkrétní technologie. Je to ve skutečnosti několik technologií, které si jdou svoji cestou, ale dohromady tvoří mocný nástroj pro tvorbu dynamických webových aplikací. (Garrett, 2005). Diskutabilní je také fakt do jaké míry lze Ajax považovat za novátorský. AJAX to je pojem, který lze v poslední době na webdesignérské scéně slyšet z mnoha stran, ale přitom to není nic nového vždyť technologie, které AJAX využívá zde jsou již asi 7 let! (Daire, 2006). Ajax je zkratka pro anglické slovní spojení Asynchronous JavaScript and XML. Využití Ajax se silně váže k následujícím technologiím: XHTML, CSS XHTML je značkovací jazyk, pomocí kterého data zobrazujeme a vložením CSS (tzv. kaskádové styly) stylu jim přiřadíme konkrétní formu. DOM (Document Object Model) jedná se o zkratku objektového modelu webové stránky, pomocí kterého můžeme stránku dynamicky měnit. Původně byl Javascript vytvořen, aby pomohl vývojářům dynamicky měnit tagy v jejich stránkách ve snaze obohatit zážitek klienta. Brzy se však ukázalo, že je možné celou stránku považovat za objekt, a tak se zrodil DOM (Document Object Model). Zpočátku byly Javascript a DOM úzce propojeny, postupně se však vyvinuly v oddělené koncepty. DOM představuje plně objektově orientovanou reprezentaci stránky, která může být modifikována skriptovacím jazykem, jako je Javascript nebo PHP. (Asleson, Schutta, 2006). XML a jeho deriváty formáty, které umožňují snadnou výměnu strukturovaných dat mezi klientem a serverem. Od svého zrodu v polovině 90. let se stal jazyk konsorcia W3C s názvem XML (extensible Markup Language derivát SGML), velmi populárním. Protože je mnohými viděný jako odpověď na většinu problémů spojených s vývojem. Dnes již máme k dispozici čtyři deriváty XML pro vytváření webových aplikací (a to 9

12 nepočítáme XHTML konsorcia W3C): XUL od Mozzily, XAMJ, open source alternativa přidávající Javu, MXML od Macromedia a XAML od Microsoftu. (Asleson, Schutta, 2006). XMLHttpRequest objekt, který zajišťuje asynchronní přenos informací mezi klientem a serverem. Mnozí se mylně domnívají, že platí rovnice Ajax = XMLHttpRequest, ale není to pravda. Zakladatel pojmu Ajax se k tomu vyjadřuje následovně. XMLHttpRequest představuje pouze část Ajax rovnice. XMLHttpRequest je technický prostředek, který umožňuje asynchronní komunikaci mezi klientem a serverem. (Garrett, 2005). Javascript, tento jazyk pracující na straně klienta, je hlavním programovacím jazykem Ajax aplikací. Pomocí Javascriptu, totiž vytváříme objekt XMLHttpRequest, bez kterého by byl asynchronní přenos dat mezi klientem a serverem nemožný. 2.4 XMLHttpRequest Zmíněný objekt XMLHttpRequest by se dal do jisté míry považovat jako rozhraní mezi klientem a serverem, pod kterým běží Ajax aplikace. V současnosti je zvykem webových vývojářů osočovat společnost Microsoft, že měla na trhu 6 let jeden webový prohlížeč a nebyla schopna v něm zajistit pořádnou interpretaci HTML kódu, dle standardů W3C konsorcia. Ironií ovšem je, že společnost Microsoft položila základy využití asynchronního přenosu dat. Abyste mohli vytvořit HTTP požadavek pro server za použití Javascriptu, potřebujete instanci třídy, která tuto funkcionalitu poskytuje. Taková instance byla původně představena v prohlížeči Internet Explorer 6 jako instance třídy ActiveX pod názvem XMLHTTP. Mozzila, Safari a ostatní prohlížeče Microsoft následovali a implementovali třídu XMLHttpRequest, která podporuje metody a proměnné použité v původním ActiveX objektu. (Richardson, 2006). 2.5 Asynchronní přenos dat Asynchronní přenos Ajax aplikace jsou prováděny pomocí asynchronního přenosu dat. Je sice možné vytvořit Ajax aplikaci pomocí synchronního přenos dat 4, ale uživatel by byl ochuzen o čas, který stráví u načítání nové stránky. 4 Vývojová prostředí (např. Protoype) nabízejí funkce, pomocí kterých je možné u tvorby Ajax požadavku nastavit synchronní přenos dat. 10

13 Model klasické webové aplikace (synchronní komunikace) funguje následujícím způsobem. Uživatel vyvolá na webové stránce nějaký požadavek, webový prohlížeč požadavek zpracuje a informuje server, který odešle klientovy zpátky původní obsah stránky s požadovanou změnou. Tento zdlouhavý proces na jedné straně zatěžuje server a na druhé straně samozřejmě zdržuje uživatele, který musí čekat než se obnoví celá stránka Princip asynchronní komunikace Zakladatel pojmu Ajax se zamyslel nad následujícím faktem. Je zřejmé, že kdybychom původně navrhovali Web za účelem poskytování aplikací, tvořili bychom je tak, aby u nich uživatel nemusel čekat. Proč by měl uživatel čekat pokaždé, když aplikace potřebuje něco nového ze serveru a přitom rozhraní aplikace je již dávno nahrané? Popravdě, proč by měl uživatel komunikaci mezi aplikaci se serverem vidět vůbec? (Garrett, 2005). Půvabem asynchronního přenosu dat totiž je, že místo aby se obnovovala celá stránka, obnovují se pouze ty její části, které chce uživatel změnit. Webový prohlížeč totiž při vzniku požadavku místo nahrání kompletní webové stránky, nahraje pouze Javascript objekt, ve kterém je informace o požadované změně. Tento objekt se potom postará o zobrazení konkrétních změn na stránce. Uživatel tak není obtěžován sledováním prázdné stránky a nekonečným čekáním na odpověď serveru. Komunikace je asynchronní z toho důvodu, že klient může výsledek požadavku 5 před zobrazením libovolně modifikovat, dokonce ho nemusí klientovi vůbec zobrazit. U synchronního přenosu klient výsledek požadavku pouze zobrazuje. Pro lepší pochopení vkládám diagramy zobrazující rozdíl mezi klasickou aplikací (synchronní komunikace) a Ajax aplikací (asynchronní komunikace). 5 Aplikace na straně klienta si může nastavit různé varianty chování, v závislosti na stavu vyřízeného požadavku, který přijala od serveru. 11

14 Obr. 3: Synchronní komunikace Obr. 4: Asynchronní komunikace XML, HTML a CSS Vzhledem k tomu, že data jsou většinou na serveru uložena v neuspořádané podobě, je vhodné je předat Javascript objektu v nějaké logické struktuře. Asynchronní komunikace je sice silný nástroj Ajax aplikace, ale bez XML 6, by měl vývojář daleko složitější práci. Skript na straně serveru vyhledá data v databázi, jejich neuspořádanou 6 Případně nový formát JSON. 12

15 formu převede do logické XML struktury a tu následně předá Javascript objektu (Ajax engine viz obr. 5). Javascript objekt si potom XML soubor takzvaně rozbalí a pomocí HTML a CSS zobrazí data klientovi tam, kde je očekává a v náležité formě. Při vyřizování http požadavku u klasické webové aplikace tenhle mezistupeň převodu dat do XML chybí, protože se zobrazuje celá stránka v původní podobě změněná jen o nová data. V následujícím diagramu je názorně popsán rozdíl mezi klasickou aplikací a Ajax aplikací. Obr. 5: Klasická aplikace a Ajax aplikace 2.6 Příklady použití Ajax začal jako první používat vyhledávač Google, když nasadil aplikaci Gmail, dalším příkladem je jeho našeptávač slov ve vyhledávacím boxu (Google Suggest). Velmi šikovná je také aplikace igoogle 7, kde je pěkně předvedeno využití drag&drop 8 u webových aplikací, uživatel zde má mimo jiné možnost nastavit si vlastní rozvržení oken. Tuzemský vyhledávač Seznam 9 nasadil podobné funkce. Bohužel využití Ajax na jeho stránce se mi už nejeví tak šikovné

16 2.7 Výhody U klasické webové aplikace se s každým požadavkem musí uživateli posílat celý kód stránky, v němž je většinou nových věcí málo. Naopak Ajax posílá jenom to, co si uživatel přeje na stránce změnit. Tahle výhoda se projeví zejména u webů s vysokým počtem uživatelů, kde server musí zpracovávat zaráz tisíce požadavků. Nabízí se i s rovnání s RIA aplikacemi běžícími jen za přítomnosti konkrétního pluginu v prohlížeči (viz obr.1 Plugin). Společné nevýhody alternativních RIA technologií vůči AJAXu jsou potom především tyto (Borek, 2008): Je potřeba plugin to je nevýhoda číslo jedna. Ať už vybereme libovolnou RIA platformu, nikdy nebude tak rozšířená jako webové prohlížeče. Relativně nejlépe je na tom Flash Player, který je dostupný na více než 95 % počítačů (záleží na verzi), ostatní platformy mají tržní podíl ještě nižší. Z uživatelského pohledu je nepříjemné, že ačkoli se například Flex aplikace tváří, že běží v prohlížeči, v mnoha věcech se jako běžná webová stránka nechová. Například nefungují klávesové zkratky prohlížeče, problematické (ale řešitelné) je tlačítko zpět, políčka pro zadání textu si nepamatují předchozí vstupy, password manager si nepamatuje hesla, Flex aplikace klidně může posílat nezašifrovaná HTTP data, ačkoli prohlížeč ve stavovém řádku hlásí, že stránka byla načtena přes HTTPS, a podobně. Většinu věcí řešit lze, ale je to náročné a nezábavné. 2.8 Překážky a úskalí Implementace Ajax aplikací přináší celou řadu atypických chování, na která nejsou uživatelé a vývojáři klasických webových aplikací zvyklí. Ajax znemožňuje použití tlačítka zpět v prohlížeči. Tento problém klidně můžeme označit za zásadní, protože většina uživatelů je na tlačítko zvyklá. V lepším případě Ajax tlačítko uživatelům zablokuje, v tom horším ho nechá aktivní, ale uživatel se po jeho stisknutí dostane do stejného stavu aplikace. Další pikantností je, že veškeré změny na stránce se provádějí pod stejným url (Uniform Resource Locator), tím pádem nejsme schopni uložit si do záložek určitý stav stránky pod pozměněným url. Tento problém samozřejmě vývojář může vyřešit 14

17 dosazováním atributů do url stránky při každé změně, je to ovšem plno práce navíc (tím pádem nákladnější pro firmu). Pro vývojáře jistě není příjemné zjištění, následujícího faktu U AJAXu není možné, aby server sám kontaktoval uživatele, když je potřeba. To se hodí např. u chatu, kde server obešle počítače účastníků chatu v momentě, kdy se objeví nová zpráva. Sice již byl vytvořen chat pomoci AJAXu, ale je založen na tom, že se stránka neustále dotazuje serveru (i když pomocí AJAXu, a tedy bez nahrání celé stránky), jestli přibyla nějaká nová zpráva, což není právě ideální. (Snížek, 2005). Vývojář se také potýká s faktem, že největší tržní podíly na poli webových prohlížečů zaujímají Mozzila Firefox a Microsoft Internet Explorer, které interpretují Javascript mnohdy rozdílně (to se ovšem dá obejít používáním kvalitního Ajax frameworku, který má již hotové Javascript funkce otestované na obou prohlížečích např. Prototype, jquery). Pro srovnání uvádím výčet výhod pluginových RIA technologií oproti AJAXu. (Borek, 2008): Protože plugin pochází od jednoho autoritativního dodavatele, odpadá ladění pro různé prohlížeče to je ohromná výhoda. Výkon je většinou lepší než u JavaScriptového interpretu prohlížeče, a to řádově. Odpadají technologická omezení HTML/CSS. Vývojová technologie byla většinou vytvořena na míru vývojářům, ne grafikům nebo autorům textů. Podpora v nástrojích je lepší (Flex nebo Silverlight mají funkční WYSIWYG, což se pro někoho, kdo přichází od HTML/CSS, může jevit skoro jako zázrak ale i jinak ve vývojářských nástrojích často nechybí kontrola syntaxe, debugging a další podobné vymoženosti, na které jsou vývojáři zvyklí z vývoje pro desktop). 2.9 Vhodné umístění aplikace Použití Ajax je do značné míry omezené. AJAX se dá ve svých možnostech použití přirovnat k Flashi ten také musíme používat obezřetně a jen ve vymezených případech, jinak nám přinese víc škody než užitku. A také už je myslím obecně přijatý 15

18 argument, že by se obsahový web neměl realizovat ve Flashi, protože to přináší mnohé nevýhody. S AJAXem je to podobné. (Snížek, 2005). Ajax je vhodný zejména pro prezentační stránky s drobnou aplikační logikou. Zde by bylo použití Adobe Flex nebo podobné technologie zbytečně nákladné (časově, tím pádem finančně). Ajax je také vhodný pro jednoduché formuláře, kde se nepřenáší velké množství dat zaráz. Vzhledem k faktu, že Ajax je nezávislý na webové platformě (webový prohlížeč musí mít pouze povolen Javascript) je vhodné u složitějších aplikací Ajax implementovat tam, kde se očekává přístup více uživatelů, například aplikace ve státní správě (E-Government). Jelikož se jedná o relativně nový přístup k tvorbě webových aplikací, vývojáři implementují Ajax často i tam, kde není potřeba nebo kde se vyloženě nehodí a brzdí provoz. Až příliš často se my, vývojáři, učíme, jak používat novou technologii nebo techniku, a nezabýváme se tím, kde jí prakticky aplikovat. (Asleson, Schutta, 2006). AJAX by se neměl používat místo klasických odkazů tzn., že např. při kliknutí v menu na jednu z položek se nepřejde na novou stránku, ale pouze se nahraje nový obsah do stávající stránky. Toto řešení přináší problémy s přístupností, SEO i správou obsahu. Proto v tomto případě lépe poslouží klasické odkazy. Ajax je dále zbytečné používat, kdybychom si například v rámci firemního intranetu chtěli navrhnout nějakou náročnou RIA aplikaci (např. Photoshop Express 10 ), zde se totiž dá zajistit, aby webové prohlížeče měli instalovaný společný plugin a tím pádem můžeme využít například Adobe Flex technologii, která je pro vytvoření aplikace vhodnější

19 3 Metodická východiska řešení 3.1 Javascript knihovna Při tvorbě nějaké složitější Ajax aplikace je rozumné zvolit si nejdříve vhodnou Javascript knihovnu, neboli vývojové prostředí. Takový pomocník totiž obsahuje objektové třídy, jejichž funkce jsou odladěné pro různé verze prohlížečů. Tyto třídy potom podstatně zjednodušují vývoj dynamických webových aplikací napříč různými prohlížeči. Další výhodou je fakt, že podobná knihovna velmi usnadňuje manipulaci s objektovým modelem dokumentu (DOM). Knihovna má většinou vytvořené funkce pro snadný přístup k existujícím elementům, pro jejich modifikaci, nebo pro snadné připojení nového elementu do již existující struktury. Pro snadnější tvorbu Ajax aplikací by knihovna, kterou si zvolíte, měla obsahovat funkce pro vytvoření objektu XMLHttpRequest. Objekt je totiž pro různé verze prohlížečů konstruován jinak a hotová funkce pro jeho vytvoření vám zjednoduší práci a zpřehlední zdrojový kód. Většina knihoven s podporou Ajax také obsahuje hotové funkce, které pomocí objektu XMLHttpRequest zajišťují přenos dat mezi klientem a serverem. Vývojář potom takové funkci pouze předá parametry, které přenos dat specifikují (co a kam poslat). Pro lepší představu uvádím výsečový graf, který zobrazuje strukturu četnosti užití knihoven při tvorbě Ajax aplikací. Obr. 6: Četnost použití Javascript knihoven za prosinec

20 3.2 Polling Jedním z problémů implementace chatu za použití Ajax je fakt, že server nemůže sám kontaktovat klienta a informovat ho o změnách v databázi. Jediný způsob, jak vytvořit takový komunikační kanál mezi klientem a serverem, je instalovat na obě strany dodatečný SW a případně upravit nastavení Firewallu na straně klienta. Kdyby ovšem komunikátor fungoval na tomhle principu, do značné míry by to zúžilo uživatelskou základnu, protože ne každý uživatel má možnost upravovat zabezpečení Firewallu nebo instalovat dodatečný plugin do prohlížeče. Tento problém se dá obejít pomocí neustálého dotazování klienta serveru, zda pro něj nemá nová data. Takový způsob komunikace se nazývá polling 11. Polling ovšem při větším počtu uživatelů může značně vytížit jak server, tak klienta. Proto se při jeho implementaci musí brát v potaz následující: objem přenášené informace mezi klientem a serverem, časová prodleva mezi jednotlivými dotazy, zajistit aby server neposílal pořád stejná data, ale jen nová, vypnutí pollingu u neaktivních klientů. Problematika použití pollingu při tvorbě Ajax chatu z úst odborníka. Ať jste již v oblasti Ajax začátečník, nebo jste zkušený programátor s bohatou praxí, při nápadu použít polling vám nejspíš vstávají vlasy na hlavě. Bohužel polling je jediné co máte. Napříč různými platformami a webovými prohlížeči totiž neexistuje jiný způsob jak vytvořit spojení zajištující nepřetržitou komunikaci mezi klientem a serverem, aniž byste na oba konce komunikace nenainstalovali dodatečný software. A nakonec i s instalovaným softwarem budete možná muset upravit konfiguraci Firewallu, aby to celé fungovalo. Takže jestli hledáte jednoduché řešení, které může použít každý, Ajax a polling je pro vás odpovědí. (Herrington, 2007). 3.3 Formát přenášených dat Vzhledem k faktu, že komunikace probíhá na principu pollingu, je třeba zvážit optimální formát přenášených dat mezi klientem a serverem. Data mohou být v Ajax aplikaci přenášena od serveru směrem ke klientovi pomocí následujících formátů. XML (extensible Markup Language), formát, který je v názvu Ajax, HTML (Hyper Text Markup Language), tzv. HTML snippet,

21 JSON (Javascript Object Notation), relativně nový formát XML Již v názvu Ajax je pro tvorbu aplikací doporučen formát XML. Vývojář by mohl klidně při implementaci komunikátoru použít HTML, ale ochudil by se o následující vlastnosti XML struktury: srozumitelnost (čitelnost), dat, metadata (data o datech), jednoduchost vyhledávání v datech. Pro lepší pochopení výhody XML uvedu krátký příklad. Představte si, že server posílá klientovi seznam zpráv od různých uživatelů, kde jsou dodatečné informace o uživatelích i o konkrétních zprávách. Taková data by samozřejmě šla poslat prostřednictvím HTML, ale museli bychom použít například tabulku, kde by každý řádek představoval konkrétního uživatele a buňky řádku by představovali jednotlivé údaje 12. Taková struktura by byla značně nepřehledná a vývojář by v ní velmi složitě třídil data a metadata. Na druhou stranu pomocí XML můžete oddělit jednotlivé uživatele, jejich zprávy a metadata do struktury, která vám vyhovuje. Například. si vytvoříte seznam elementů uživatel, kde každý element bude obsahovat další element zpráva a metadata budou atributy jednotlivých elementů. Dalším důvodem, proč je vhodné posílat data pomocí XML, je fakt, že HTML struktura byla původně navržena pro zobrazení dat, kde klient již nemusí data dále zpracovávat. V případě, že pošlete data pomocí XML, tak jednoznačně určujete následnou specializaci práce aplikace na straně serveru data posílají a aplikace na straně klienta je zpracovávají a následně zobrazují JSON Formát JSON je relativně nový. Tento formát představil v roce 2006 Douglas Crockford 13. JSON (JavaScript Object Notation) je odlehčený formát pro výměnu dat. Je jednoduše čitelný i zapisovatelný člověkem a snadno analyzovatelný i generovatelný strojově. Je založen na podmnožině programovac,ího jazyka Javascript. JSON je textový, na jazyce zcela nezávislý formát, využívající však konvence dobře známé 12 Například jméno uživatele, identifikační číslo uživatele, čas odeslané zprávy, identifikační číslo zprávy a samotný text zprávy

22 programátorům jazyků rodiny C (C, C++, C#, Java, JavaScript, Perl, Python a dalších). Díky tomu je JSON pro výměnu dat opravdu ideálním jazykem. (Crockford, 2006). JSON nabízí dvě základní struktury dat, které můžeme použít. Tyto struktury jsou univerzální a v podstatě každý moderní programovací jazyk je podporuje: objekt, který je reprezentován, jako neuspořádaná množina dvojic klíč, hodnota, tříděný seznam hodnot, který většina programovacích jazyků zná jako pole, seznam nebo vektor. Pro lepší představu o dvou základních strukturách, které můžeme použít, vkládám diagramy, které struktury názorně odlišují. Obr. 7: Objekt, který obsahuje neuspořádané dvojice Obr. 8:Pole hodnot Vývojář má tedy na výběr dvě základní možnosti jak uložit data pomocí JSON. Obecně se první přístup používá pro jednoduší strukturu dat, kde nám nezáleží na pořadí (např. neuspořádaný seznam identifikačních čísel uživatelů). Druhý přístup je vhodné použít všude tam, kde se předpokládá, že struktura bude mít nějakou hierarchii 14. Následující diagram uvádí výčet typů hodnot, které můžeme použít při tvorbě JSON struktury. 14 Například seznam relací a jejich atributů, kde každá relace zahrnuje různý počet textových zpráv od uživatelů, kteří tvoří relaci. 20

23 Obr.9: Výčet typů hodnot 21

24 4 Implementace komunikátoru 4.1 Specifikace komunikátoru Komunikátor, který jsem implementoval, poskytuje uživatelům následující funkčnost: Možnost přihlásit se do komunikátoru přes jeho vlastní rozhraní. Seznam uživatelů, kde je zřetelně odděleno, kdo je k aplikaci přihlášen a kdo ne. Možnost vybrat ze seznamu přihlášeného uživatele a napsat mu zprávu. Možnost zprávy přijímat. Odhlášení se z aplikace. 4.2 Knihovna Prototype Pro studii Ajax chatu jsem použil tutoriál 15, který využívá knihovnu Prototype, rozhodl jsem se, že pro implementaci Ajax komunikátoru využiji stejnou knihovnu. Prototype má mnoho funkcí pro zjednodušení práce s objektovým modelem dokumentu (DOM). Pro názornou ukázku uvádím v příloze srovnání dvou aplikačně stejných kódů, ve kterých se vytvoří element, přiřadí se mu styl zobrazení a nakonec se připojí ke kořenovému elementu. První kód je psaný bez vývojového prostředí a druhý pomocí Prototype (viz Příloha B). Knihovna Prototype mi velmi zjednodušila tvorbu XMLHttpRequest objektu. Pro názornou ukázku uvádím srovnání dvou aplikačně stejných kódů, kde se iniciuje HTTP požadavek a následně vytváří objekt xmlhttprequest, který získává data ze serveru a posílá je zpět klientovi. První kód je psaný bez vývojového prostředí a druhý je vytvořen pomocí Prototype (viz Příloha C). 4.3 Polling Pro lepší představu jak funguje můj komunikátor pomocí pollingu uvádím diagram. Každé zobrazení klienta A představuje jeho jeden dotaz na server, který je opakován po sekundě. Klient B potom iniciuje http požadavek na server, pouze když chce napsat někomu zprávu. U každého klienta tak mohou vzniknout zaráz až tři http požadavky 16 směrované serveru Dva vznikají automaticky a jeden vytvoří uživatel. 22

25 Obr 10: 2 druhy http požadavků V diagramu jsou dvě kategorie HTTP požadavků rozlišeny barevně. Šedý požadavek je iniciován každou sekundu bez ohledu na klienta 17. Zelený požadavek je iniciován pouze v případě vzniku události na straně klienta, v případě komunikátoru je tou událostí stisknutí tlačítka odeslat (událost onclick), pro odeslání nové zprávy. 4.4 JSON Pro přenášení strukturovaných dat by byl nejméně vhodný HTML formát. Klient by ho sice mohl před zobrazením upravit, ale bylo by to zbytečně komplikované. Musel jsem si vybrat mezi XML a JSON. JSON formát je relativní novinka. Rozhodl jsem se, že jej použiji, protože tento formát poskytuje méně objemná data než XML 18. Zde se ukazuje, že název Ajax 19 nemusí nutně diktovat abychom pro transformaci dat použily XML. Vždy totiž záleží na tom, který formát je pro danou aplikaci nejvhodnější. Zakladatel pojmu Ajax odpovídá na otázku, zda je nutné použít XML v Ajax aplikaci: Není to nutné. XML je nejvyvinutějším prostředkem jak dostat data do a z Ajax klienta, ale není zde žádný důvod, proč byste nemohli dosáhnout stejného efektu za použití technologie Javascript Object Notation nebo za použití podobné technologie k tvorbě strukturovaných dat určených pro výměnu mezi klientem a serverem. (Garrett, 2005). Pro lepší rozlišení různých formátů vkládám do přílohy zdrojové kódy (viz Příloha D). Každý kód reprezentuje stejná data 20, ale v jiných formátech. Formát zprávy je na 17 Javascript funkce, která vytvoří požadavek a každou sekundu volá sama sebe. 18 S přihlédnutím k pollingu jsou nejvhodnější taková data, která jsou nejméně objemná. 19 Asynchronnous Javascript and XML 20 Jednoduchá textová zpráva, ve které je uveden odesilatel. Komunikátor ve skutečnosti přenáší o textové zprávě více informací, než jen odesilatele. 23

26 straně serveru generovaný php skriptem a následně předáván XMLHttpRequest objektu, který zprávu pošle klientovi k dalšímu zpracování. Jak je vidět v příloze, zdrojový kód, kde je použit JSON formát je visuelně nejobjemnější, důležité je zde ovšem to, jak je objemný parametr funkce php echo. V případě JSON, php skript posílá zprávu klientovi ve formě Javascript objektu 21. V poli jsou pouze dvojice klíč, hodnota, to znamená, že zpráva ve formátu JSON je menší o uzavírající značky, které jsou v XML a HTML. Napadlo mě, že když potřebuji aby přenášená data byla co nejvíce stlačená, mohl bych je před zakódováním do JSON objektu ještě zkomprimovat. Velmi známou GNU aplikací pro kompresi dat je například gzip 22. Problém je ovšem v tom, že komunikátor funguje na principu pollingu a server by byl každou sekundu zaměstnán výpočty algoritmů pro komprimaci 23. Je velmi pravděpodobné, že by to zpomalilo procesor serveru. 4.5 Funkčnost komunikátoru Nejdříve bylo nutné umožnit propojení mezi stávající databází serveru na který bude komunikátor instalován a novými tabulkami komunikátoru, a to takovým způsobem, aby šlo později komunikátor instalovat na libovolný server, kde je použito MySQL. Funkčnost na straně serveru je řešena pomocí skriptovacího jazyku PHP. Vzhledem k výše popsané problematice pollingu bylo dále potřeba navrhnout funkční kostru klienta tak, aby při vyšším počtu uživatelů nehrozilo zahlcení serveru zbytečnými dotazy. To znamená napsat vhodný algoritmus, který by se serveru neustále dotazoval, ale pouze na nová data Instalace, přihlášení, odhlášení Komunikátor je vytvořen tak, aby byl přístupný pro stávající uživatele stránky bez dodatečné registrace. Administrátor webu pouze musí při instalaci komunikátoru vyplnit do souboru název tabulky uživatelů a konkrétních sloupců. Dodatečné tabulky komunikátoru vytvoří php skript. Tahle výhoda je ovšem limitující v případě, že jsou informace o uživatelích uloženy napříč tabulkami, protože skript komunikátoru, který se spouští při prvním přihlášení uživatele, je vytvořen tak, že se dívá na uživatelská data 21 Konkrétně asociační pole zakódované do JSON objektu S počtem uživatelů by rostl počet výpočtů. 24

27 pouze do jedné tabulky. Pro představu přikládám diagram znázorňující propojení tabulky komunikátoru a tabulky s údaji o uživatelích. Obr. 11: Stávající tabulka uživatelů a nová tabulka komunikátoru Vidíme, že v tabulce im_users (tabulka komunikátoru) nemusí být uloženi všichni stávající uživatelé webu. Uživatel webu se totiž dostane do tabulky im_users až když se pomocí rozhraní přihlásí do komunikátoru. Přihlašuje se pomocí svých přihlašovacích údajů, které používá k přihlášení na webovou stránku. Jakmile se uživatel poprvé přihlásí, jeho údaje se mu zkopírují do tabulky im_users a nastaví se mu v řádku příznak, že je online. Aby byl komunikátor schopen uživatele informovat o stavu přihlášených uživatelů z tabulky im_users, je zde samozřejmě implementovaná i funkce pro odhlášení. Tato funkce je napsaná tak, že při odhlášení uživatelovi nastaví v tabulce příznak offline. Funkce uživatele odhlásí i když omylem zavře stránku a neodhlásí se standardně pomocí tlačítka Seznam kontaktů Jak již bylo řečeno uživatel má k dispozici jednoduchý seznam, kde je uvedeno kdo je přihlášen a kdo ne. Pro tuhle aplikaci má angličtina slovní výraz buddy list, neboli seznam kontaktů. Jedná se o klasický seznam kontaktů, jaký známe třeba z icq. Teprve zde se naplno projevuje síla Ajax, jména seznamu se totiž mění, aniž by se nahrávala nová stránka, přesně jak to známe z aplikace icq. Seznam online (přihlášený uživatel) a offline (nepřihlášený uživatel) kontaktů posílá server samozřejmě pomocí formátu JSON. Vzhledem ke komplexnosti celého procesu obnovy seznamu kontaktů, přikládám diagram, který popisuje, jak se obnova dat odehrává. 24 Element body obsahuje atribut onunload u kterého je nastavena odhlašovací funkce. 25

28 Obr. 12: Přenos seznamu kontaktů a jeho zobrazení Jak jsem se již zmínil na začátku, při pollingu je ideální ptát se pouze na nová data. Bohužel jsem, ale nepřišel na vhodný způsob jak zjistit, jestli se současný seznam kontaktů změnil oproti o sekundu novějšímu seznamu v databázi. Jde o problém, že uživatelé se jednoznačně identifikují podle jejich id. Přímo se nabízí možnost porovnávat dvě množiny čísel při každém požadavku, ale takové srovnání není při pollingu zrovna vhodné 25. Klient tak každou sekundu přepisuje seznam kontaktů seznamem, který získá od serveru, bez jakéhokoli testování. V příloze uvádím php skript, který generuje JSON objekt a Javascript funkci, která objekt rozbalí a zobrazí seznam kontaktů (viz Příloha E) Zprávy Hlavní uživatelskou funkcí komunikátoru je samozřejmě možnost zaslání zprávy jinému uživatelovi. Princip přenosu zprávy 26 směrem od serveru ke klientovi je podobný jako u seznamu kontaktů. Ukládání jednotlivých uživatelských relací a jejich zpráv je provedeno pomocí dvou tabulek. Diagram níže popisuje všechny tabulky, které jsou součástí komunikátoru. 25 S narůstajícím počtem uživatelů by rostl i seznam kontaktů, který by aplikace musela porovnávat s novým stavem v databázi. 26 Formát zprávy je opět JSON. 26

29 Obr. 13: ERD komunikátoru Z diagramu je patrné, že každý uživatel webové stránky může být součástí libovolného počtu relací, které obsahují libovolný počet zpráv. Tento databázový systém je pateří veškeré interakce, která probíhá mezi uživateli. U seznamu kontaktů jsem se zmiňoval o tom, že se mi nepovedlo funkci optimalizovat tak, aby na straně klienta zobrazovala pouze nové informace. Tato optimalizace se mi ovšem zdařila u funkce, která se stará o příjem a zobrazení zpráv uživatelům. Funkce pro příjem zpráv, je taky nejkomplexnější funkcí v systému (viz Příloha F). Při návrhu aplikace jsem zohlednil skutečnost, že každá poslaná zpráva, která se ukládá do tabulku im_messages, má jedinečné id, které je vyšší než id poslední uložené zprávy. Aplikace na straně klienta si pamatuje id poslední zobrazené zprávy u poslední relace (zpráva v poslední relaci má jednoznačně nejvyšší id, naopak čísla relací jsou stále stejná) a tuto informaci posílá serveru. Server potom prohledává všechny relace, které se vztahují k uživatelovi a kontroluje, jestli v nich není zpráva, která má vyšší id, než id co poslal klient. Když server najde zprávy s vyšším id, pošle je klientovi jako JSON objekt, jestli server nové zprávy nenajde, klientovi posílá prázdný JSON objekt, který se jenom rozbalí a na obrazovku se nic nevypíše. Ovládání zasílání zpráv je zcela intuitivní, stejně jako u klasického icq. Uživatel dvakrát klikne na kontakt, který je online a zobrazí se mu okno 27 rozdělené na zobrazovací plochu a na pole pro vložení textu. Zprávu odešle po stisknutí tlačítka Posli. Má li uživatel na ploše více oken, může jedním kliknutím na kontakt v seznamu umístit dané okno do popředí před ostatní okna. Pro představu vkládám obrázek okna pro posílání zpráv. 27 Blokový element div, který je vytvořen z dalších elementů. 27

30 Obr. 14: Komunikační okno Táhni a pusť Obě dvě komponenty Ajax komunikátoru tzn. seznam kontaktů a okno pro posílání zprávy jsou plně přesunovatelné po stránce. Tahle vlastnost je dnes součástí téměř každé Ajax aplikace, kde je její uplatnění vhodné a očekává se. Javascript knihovna Prototype bohužel nenabízí jednu funkci, která by jako parametr převzala komponentu a udělala ji přesunovatelnou. Vývojář si ovšem podobnou funkci může pomoci Prototype knihovny vytvořit. Já zvolil jinou možnost a vybral si jednu z mnoha knihoven, které výše zmíněnou funkci nabízejí. Konkrétně Javascript knihovnu dom-drag.js 28. Otázkou zůstává do jaké míry je tato knihovní funkce dobře napsaná v porovnání s jinými funkcemi ke stažení. Komponenty se totiž při přesouvání trochu trhaně vykreslují. Ale je klidně možné, že to je způsobené špatně zvolenou strukturou elementů, které tvoří komponentu

31 5 Porovnání Ajax komunikátoru s alternativami 5.1 Instant Messenger Na začátku tohoto projektu jsem si stanovil, že bych se rád přiblížil k podobné aplikaci, s názvem IM (Instant Messenger). Na první pohled je zřejmé, že aplikaci netvoří jeden nadšenec, ale tým profesionálů, dobrovolníků (IM je na stránce umístěn ke stáhnutí zdarma, vývojáři žádají pouze o dobrovolný poplatek). Aplikace má velké množství funkcí a je kompatibilní se všemi novými prohlížeči. Tento komunikátor je dle mého názoru co do funkčnosti plně srovnatelný s klasickou desktop aplikací icq. Zde se nabízí otázka do jaké míry by podobná aplikace mohla být icq konkurentem. IM je vytvořen pomocí stejné Javascript knihovny, kterou jsem použil já (Prototype). Vzhledem k omezení Ajax je samozřejmě i zde řešena komunikace mezi klientem a serverem na principu pollingu. Nejvíce mě zde inspiroval formát přenášených zpráv, jedná se samozřejmě o JSON. Tento formát je v současné době pro podobné aplikace, řešené pomocí Ajax optimální. Komunikace je v IM uskutečněna pomocí osmi tabulek. Já jsem použil sice jenom tři tabulky, ale na rozdíl od IM jsem neimplementoval např. diskusní skupiny nebo chatové místnosti. Pro kritické srovnání s podobnou aplikací jsem musel svůj projekt naimplementovat tak, aby nabídnul něco, co IM nemá. IM má totiž tu nevýhodu, že když ho správce webu instaluje na svoje stránky, tak jsou jeho tabulky kompletně odděleny od tabulek s údaji o stávajících uživatelích. Uživatel webu, který chce IM používat, se potom musí zvlášť registrovat a IM mu následně vytvoří účet. Tenhle nedostatek je možná na první pohled nepatrný. Komunitní weby jsou ale postaveny na tom, že každý uživatel si na nich buduje svoji virtuální identitu pod jedinečnou přezdívkou. S nasazením IM aplikace na portál vzniká riziko, že vám někdo přezdívku ukradne, zaregistruje se pod ní v IM a bude se vydávat za vás. Faktem také je, že zpřístupnit novou aplikaci pro uživatele, pod podmínkou nové registrace není zrovna ideální. Komunikátor, který jsem vytvořil tímhle nedostatkem netrpí. Při jeho instalaci totiž správce webu vyplní údaje o tabulce, ve které jsou uživatelé. Komunikátor potom při prvním přihlášení uživatele, provede ověření jeho údajů pomocí zmíněné tabulky a při positivním výsledku zkopíruje uživatele do své tabulky. Tahle výhoda mého komunikátoru je ovšem do jisté míry omezená. Skript komunikátoru je totiž navržen 29

32 tak, že si konkrétní uživatelovi údaje ověřuje 29 a kopíruje 30 pouze z jedné tabulky. Pokud by se jednalo o nějaký složitější databázový systém, kde jsou uživatelovi údaje uloženy napříč tabulkami, komunikátor by nebylo možné bez dodatečných úprav na web implementovat. Ovšem pro jednoduché weby je implementace komunikátoru bezproblémová. 5.2 Meebo Možnou alternativou je aplikace s názvem Meebo 31. Jedná se o aplikaci, která umožňuje uživatelům různých sítí (ICQ, AIM, Gogole Talk, MSM, Jabber) vzájemnou komunikaci. Aplikace je samozřejmě funkční napříč různými prohlížeči. Ajax komunikátor také nerozlišuje uživatele, ale pouze do jisté míry. Mohou ho použít pouze uživatelé konkrétního portálu, na kterém je instalován. Komunikátor totiž nesjednocuje uživatele napříč internetem, ale pouze uživatele jednoho portálu. 5.3 ICQ V úvodu této kapitoly jsem nastínil otázku, do jaké míry je Ajax komunikátor konkurencí například pro klasické icq. V globálním měřítku nemůže Ajax komunikátor co do užívání icq nikdy vytlačit, vzhledem k faktu, že komunikátor nemá instalovaný uživatel na svém počítači, ale provozovatel komunitního portálu na serveru poskytovatele. Na druhou stranu v určitých oblastech by mohl komunikátor icq zastoupit. Komunitní web je jednou z těch oblastí. Pro návštěvníky webu je komunikátor vlastně takový společný komunikační protokol. Uživatel zde jistě pro nahodilou konverzaci na dané téma, upřednostní komunikátor, před icq, kde by si musel uživatele složitě dohledávat a přidávat ho do seznamu kontaktů. Komunikátor totiž může být upraven tak, aby zobrazoval jen účastníky konkrétní diskusní skupiny, nebo například seznam lidí, kteří si přečetli určitý článek. Záleží totiž na administrátorovi webu, jakou tabulku uživatelů pro komunikátor nastaví. Další oblastí, ve které by komunikátor mohl nahradit icq aplikaci, je E-commerce. Komunikátor se může implementovat například do firemního intranetu. Taková komunikace je potom bezpečnější než například komunikace pomocí běžného icq. 29 Uživatelské jméno a heslo. 30 Uživatelské jméno a identifikační číslo uživatele

33 Odposlech takové komunikace by zde byl totiž problematičtější. Případný útočník by se musel nabourat do vnitřní sítě firmy. Ajax komunikátor najde také uplatnění například v e-shopu. Pro registrované uživatele je to nejrychlejší způsob jak kontaktovat prodejce a zeptat se ho na zboží. Prodejce má zároveň přehled o tom, kdo všechno je přihlášen v e-shopu a může tak operativně řešit problém s konkrétním zákazníkem. Faktem ovšem zůstává, že takové vylepšení by si vyžádalo dodatečné náklady na personál, který by odpovídal na dotazy. Autor článku, ve kterém popisuje tvorbu chatu za použití Ajax, se zmiňuje o následujícím: Když vývojáři mluví o pojmu Web 2.0, většinou o něm mluví v souvislosti s komunitním webem. Možná si myslíte, že pojem Web 2.0 je pouze nový reklamní trik, ale nemůžete pominout fakt, že okamžité zapojení čtenářů do konverzace na dané téma, nebo zákazníků do konverzace ohledně konkrétního produktu, je velmi chytrý marketingový tah. (Herrington, 2007). 31

34 6 Diskuse 6.1 Diskuse Na začátku projektu jsem si stanovil, aby webová aplikace byla uživatelsky přívětivá, zbytečně nezatěžovala klienta a neplýtvala systémovými prostředky serveru. Myslím, že do jisté míry 32 se mi to podařilo splnit. Server posílá klientovi data v úsporném formátu JSON a funkce zajištující zobrazení příchozích zpráv jsou vytvořeny tak, že klient přijímá pouze nové zprávy. Dále jsem si předsevzal, aby komunikátor nabídnul něco nového oproti Ajax aplikaci IM. Zde jsem využil faktu, že instalovaný IM není schopen komunikovat s existující tabulkou uživatelů. Můj komunikátor je vytvořen tak, že se napojí na tabulku s existujícími uživateli a kopíruje z ní data do své tabulky. Ve stávající aplikaci je samozřejmě celá řada věcí, které by šly vylepšit. Vzhledem k faktu, že komunikace probíhá na principu pollingu, by bylo vhodné více se zaměřit na latenci mezi vznikajícími HTTP požadavky a objem dat, které přenáší. Ideální by bylo naimplementovat hlavní funkci, která by v určitém intervalu kontrolovala čas poslední modifikaci databáze 33 a jestli by čas byl vyšší, než poslední uložený, tak by tato funkce vytvořila konkrétní HTTP požadavek. Funkce by například kontrolovala čas poslední modifikace tabulky im_users a kdyby zjistila vyšší číslo, než které má uložené, tak by iniciovala požadavek k obnově seznamu kontaktů, podobně u zobrazování nových zpráv. Neodpadla by tak sice neustálá komunikace klienta se serverem, ale výrazně by se snížil objem přenášených dat a počet provedených SQL dotazů nad databází. Taky bych mohl implementovat funkci, která by kontrolovala čas poslední aktivity uživatele a v případě dlouhodobé nečinnosti by u něho vypnula polling, což by představovalo další úsporu pro procesor serveru, tím pádem možné zrychlení aplikace pro ostatní uživatele 34. Chybí zde hodně vylepšení, kterými bych chtěl komunikátor ještě obohatit. V prvé řadě grafická úprava komunikátoru je velmi strohá. Velkým nedostatkem je také fakt, že komunikátor uživatele nijak neupozorňuje na příchozí zprávu. Tenhle nedostatek by šel sice vyřešit vyskakující alert zprávou, ale mnohem efektivnější by byl například svévolný pohyb okna, ve kterém je nová zpráva, který by přestal, až když uživatel 32 Vyjma funkce, která zobrazuje seznam kontaktů způsobem, který při pollingu není ideální. 33 V lepším případě stav poslední modifikace konkrétní tabulky. 34 Jednou z nevýhod u podobných aplikací je, že se jejich nedostatky projeví až s větším počtem uživatelů. 32

35 klikne kurzorem do textového pole. Všiml jsem si, že IM nenabízí v okně se zprávou upozornění, když vám druhá strana píše zprávu. Tohle vylepšení bych také mohl aplikovat. Velkým nedostatkem je také skutečnost, že uživatel nemá možnost sám rozhodovat o tom, kdo bude v jeho seznamu kontaktů. Pro uživatele by byl jistě zajímavý veřejný, případně privátní chat 35. Dále zde chybí možnost vytvářet si v seznamu kontaktů konkrétní skupiny uživatelů, nebo například dodatečný seznam kontaktů, ve kterém bychom nastavili, kdo nás má vidět jako nepřihlášeného. Zmíněná chybějící vylepšení zatím degradují aplikaci jen na průměrný nástroj k real time komunikaci. Ale po implementaci dodatečných funkcí by se mohl z komunikátoru stát důstojný konkurent k webové aplikaci IM, případně k podobným aplikacím, které teprve vznikají. 35 Možnost uživatele vytvořit si vlastní chat místnost a pozvat do ní další uživatele. 33

36 7 Závěr 7.1 Závěr Cílem této práce byla implementace funkčního komunikátoru za použití technologií, které vymezuje pojem Ajax. Samozřejmě, že k tvorbě podobné aplikace jsem musel použít i technologie na straně serveru, které v názvu Ajax uvedeny nejsou 36, ale jejich znalost se při tvorbě dynamických webových aplikací předpokládá. Vzhledem k rychlému vývoji informačních technologií je otázkou, za použití jakých technologií se bude Ajax komunikátor implementovat třeba za dva roky. Je klidně možné, že odpadne nutnost použít polling a formát přenášených zpráv bude mnohem úspornější než JSON. Na druhou stranu není ani vyloučeno, že Ajax ustoupí do pozadí oproti alternativním RIA technologiím, které v současnosti nabízí více možností. Budoucnost RIA aplikací je dnes formována dvěma technologickými tábory. Na jedné straně stojí nekomerční Ajax (veškeré potřebné nástroje jsou přístupné zdarma), za který se postavila společnost Google, která Ajax využívá zejména pro jeho nezávislost na webové platformě 37. Na druhé straně komerční technologie, které ovšem vyžadují dodatečný plugin v prohlížeči. V současnosti je nejpoužívanější Adobe Flex, protože plugin Flash Player je mezi prohlížeči nejvíce rozšířený. Jinými slovy proti sobě stojí slabě se rozvíjející Javascript 38 a výkonný Actionscript (v současnosti Actionscript 3) ve spojení s Flash technologií. Ať již první místo obsadí kdokoliv, jasné je, že klasické aplikace pomalu, ale jistě ustupují do pozadí, oproti bohatým aplikacím, které vytvářejí tzv. WEB 2.0 a vývojáři společně s uživateli z toho mohou v budoucnu pouze profitovat. 36 Skriptovací jazyk PHP ve spojení s MySQL příkazy. 37 Společnost Google má v současnosti největší podíl na poli internetových vyhledávačů. 38 V současnosti se už čeká na Javascript 2, který se hodně inspiruje současným Actionscript. 34

37 8 Seznam použité literatury [1] ASLESON, R. AJAX. Vytváříme vysoce interaktivní webové aplikace. 1.vyd. Brno: Computer Press, s. ISBN [2] BOREK, B. Rich Internet Application v roce 2008 [online]. 2008, poslední aktualizace [cit ]. Dostupné z WWW: < [3] CROCKFORD, D. Představení JSON [online]. 2006, poslední aktualizace [cit ]. Dostupné z WWW: < [4] DAIRE, C. AJAX a PHP: tvoříme interaktivní webové aplikace profesionálně. 1. vyd. Brno: Zoner Press, s. Encyklopedie webdesignera. ISBN [5] GARRETT, J. J. Ajax: A New Approach to Web Applications. [online]. 2005, poslední aktualizace [cit ]. Dostupné z WWW: < [6] HERRINGTON, D. J. Ajax and XML: Ajax for chat [online]. 2007, poslední aktualizace [cit ]. Dostupné z WWW: < [7] RICHARDSON, D. Asynchronous Javascript and XML (AJAX) [online]. 2007, poslední aktualizace [cit ]. Dostupné z WWW: < [8] SNÍŽEK, M. Ajax: Kde jsou hranice? [online]. 2005, poslední aktualizace [cit ]. Dostupné z WWW: < 35