Framework pro dynamick´a rozhran´ı webov´ych aplikac´ı, emuluj´ıc´ı desktopov´e programov´an´ı

Framework pro dynamick´ a rozhran´ı webov´ ych aplikac´ı, emuluj´ıc´ı desktopov´ e

programov´ an´ı

Diplomov´ a pr´ ace

Studijn´ı program: N2612 – Elektrotechnika a informatika Studijn´ı obor: 1802T007 – Informaˇcn´ı technologie Autor pr´ace: Bc. Jakub Petrˇz´ılka

Vedouc´ı pr´ace: prof. Ing. Zdenˇek Pl´ıva, Ph.D.

Framework for dynamical web interfaces enabling traditional approach for

developement of desktop applications

Diploma thesis

Study programme: N2612 – Electrical Engineering and Informatics Study branch: 1802T007 – Information Technology

Author: Bc. Jakub Petrˇz´ılka

Supervisor: prof. Ing. Zdenˇek Pl´ıva, Ph.D.

Prohl´ aˇ sen´ı

Byl jsem sezn´amen s t´ım, ˇze na mou diplomovou pr´aci se plnˇe vztahuje z´akon ˇc. 121/2000 Sb., o pr´avu autorsk´em, zejm´ena § 60 – ˇskoln´ı d´ılo.

Beru na vˇedom´ı, ˇze Technick´a univerzita v Liberci (TUL) nezasahuje do m´ych au- torsk´ych pr´av uˇzit´ım m´e diplomov´e pr´ace pro vnitˇrn´ı potˇrebu TUL.

Uˇziji-li diplomovou pr´aci nebo poskytnu-li licenci k jej´ımu vyuˇzit´ı, jsem si vˇedom povinnosti informovat o t´eto skuteˇcnosti TUL; v tomto pˇr´ıpadˇe m´a TUL pr´avo ode mne poˇzadovat ´uhradu n´aklad˚u, kter´e vynaloˇzila na vytvoˇren´ı d´ıla, aˇz do jejich skuteˇcn´e v´yˇse.

Diplomovou pr´aci jsem vypracoval samostatnˇe s pouˇzit´ım uveden´e literatury a na z´akladˇe konzultac´ı s vedouc´ım m´e diplomov´e pr´ace a konzultantem.

Souˇcasnˇe ˇcestnˇe prohlaˇsuji, ˇze tiˇstˇen´a verze pr´ace se shoduje s elektronickou verz´ı, vloˇzenou do IS STAG.

Datum:

Podpis:

Podˇ ekov´ an´ı

Dˇekuji ing. Jiˇr´ımu Jen´ıˇckovi, Ph.D., Bc. Jiˇr´ımu Veselkovi a Bc. Martinu Peˇsovi za poskytov´an´ı konzultac´ı a sd´ılen´ı zkuˇsenost´ı. D´ale bych chtˇel podˇekovat Bc. Petru Vejvodovi za nemal´y pod´ıl na v´yvoji frameworku Phem a Bc. Janu Petˇrvalsk´emu za pomoc pˇri ´upravˇe form´aln´ı str´anky t´eto pr´ace. V neposledn´ı ˇradˇe patˇr´ı podˇekov´an´ı tak´e komunitˇe kolem serveru Stackoverflow.com, kde jsem vˇzdy obdrˇzel cenn´e rady a urgentn´ı pomoc.

Abstrakt

Pr´ace se zab´yv´a realizac´ı PHP frameworku pro tvorbu dynamick´ych webov´ych apli- kac´ı, navrˇzen´ym s d˚urazem na vysok´y v´ykon, pˇrenositelnost a snadn´e nasazen´ı i ve sloˇzitˇejˇs´ıch pˇr´ıpadech uˇzit´ı. Tento framework disponuje moˇznostmi a funkcemi, vhodn´ymi zejm´ena pro tvorbu administraˇcn´ıch rozhran´ı, vyˇzaduj´ıc´ıch paraleln´ı ˇci ko- operativn´ı ´uˇcast uˇzivatel˚u. Umoˇzˇnuje t´eˇz vyuˇzit´ı tradiˇcn´ıho deklarativn´ıho pˇr´ıstupu, zn´am´eho napˇr´ıklad z Windows Forms ˇci jin´ych desktopov´ych v´yvojov´ych platforem.

Prvn´ı ˇc´ast pr´ace vˇenuje pozornost zejm´ena v´ybˇeru technologi´ı (HHMV, WebSocket, React, ZeroMQ, Ajax Comet a dalˇs´ı) a doporuˇcen´e konfiguraci bˇehov´e platformy.

D´ale je popisov´ana struktura frameworku, jeho komponenty a zaˇclenˇen´ı vyuˇzit´ych knihoven a n´astroj˚u tˇret´ıch stran (napˇr´ıklad Twig, Doctrine 2 ORM, Composer, Ratchet, JQuery, Twitter Bootstrap a dalˇs´ı). Posledn´ı ˇc´ast pr´ace pak zahrnuje po- drobn´y popis kl´ıˇcov´ych komponent a implementaˇcn´ıch detail˚u. Nˇekolik kapitol je zde t´eˇz vˇenov´ano v´ykonnostn´ımu porovn´an´ı r˚uzn´ych konfigurac´ı.

Kl´ıˇcov´a slova: PHP framework, HHVM, WebSocket, realtime, push technologie, Ajax, dynamick´y web, PHP Forms, PHP MVC

Abstract

This thesis is dedicated to realization of PHP framework for developement of dyna- mical web applications focused to high throughput performance, portability and easy use even in more sophisticated use cases. It features a collection of tools and functi- ons suitable mainly for developement of administration interfaces which requests either concurent or cooperative participation of many users at the same time. It also enables the traditional declarative approach known for example from Windows Forms and many other platforms for desktop developement. The first part of thesis is focused to selection of technologies (such as HHVM, WebSocket, React, ZeroMQ, Ajax Comet, etc.) and to recommanded configuration of the runtime platform. In the further section, the structure of the Framework is described, together with it’s com- ponents and inclusion of third party tools and libraries such as for example Twig, Doctrine 2 ORM, Composer, Ratchet etc. The final part of the thesis is focused on detailed description of essential components and implementation details. Several chapters are also dedicated to a performance comparation of various configurations.

Keywords: PHP framework, HHVM, WebSocket, realtime, push technology, Ajax, dynamic web, PHP Forms, PHP MVC

Obsah

Obsah . . . 8

Seznam pouˇzit´ych zkratek . . . 11

Seznam ilustrac´ı a graf˚u . . . 12

Seznam tabulek . . . 12

Seznam zdrojov´ych k´od˚u . . . 13

Konvence v sazbˇe . . . 13

Uvod´ 14 1 Anal´yza a zp˚usob realizace 17 1.1 Dostupn´e frameworky a n´astroje . . . 18

1.1.1 Symfony . . . 19

1.1.2 Larvel . . . 20

1.1.3 Kohana . . . 21

1.1.4 Phem . . . 22

1.1.5 Vyhodnocen´ı . . . 23

1.2 Koncept uˇzivatelsk´eho rozhran´ı . . . 23

1.3 Ukl´ad´an´ı aplikaˇcn´ıch promˇenn´ych . . . 24

1.4 V´ymˇena zpr´av a notifikace . . . 25

1.4.1 Flash RTMP . . . 25

1.4.2 Comet a dlouh´e dotazov´an´ı . . . 25

1.4.3 XHRStreaming . . . 26

1.4.4 WebSocket . . . 26

1.5 Technologie HHVM a jej´ı podpora . . . 26

2 Pˇredstaven´ı frameworku Phem 28

2.2 Rozˇs´ıˇritelnost . . . 30

2.3 Zahrnut´e knihovny tˇret´ıch stran . . . 30

2.4 Dalˇs´ı funkcionalita a kl´ıˇcov´e komponenty . . . 30

2.4.1 Z´akladn´ı controllery . . . 31

2.4.2 Generov´an´ı odkaz˚u . . . 31

2.4.3 Instantn´ı formul´aˇre . . . 32

2.4.4 XML import a export . . . 32

2.4.5 Spr´ava uˇzivatel˚u a opr´avnˇen´ı . . . 32

3 Realizovan´e komponenty 33 3.1 Komponenta Dispatcher . . . 34

3.1.1 Princip ˇcinnosti . . . 34

3.1.2 Pˇrihlaˇsov´an´ı uˇzivatel˚u . . . 36

3.2 Komponenta ResourceLoading . . . 36

3.2.1 Prohled´avan´a um´ıstˇen´ı a typy zdroj˚u . . . 37

3.2.2 Knihovny a zdroje tˇret´ıch stran . . . 38

3.2.3 ResourceManager . . . 39

3.2.4 Automatick´a minifikace . . . 39

3.3 Komponenta MessageBus . . . 40

3.3.1 Bˇehov´e reˇzimy . . . 40

3.3.2 Adresace . . . 43

3.3.3 Vytvoˇren´ı a odesl´an´ı zpr´avy . . . 44

3.3.4 Argumenty zpr´av . . . 45

3.4 Komponenta UI . . . 46

3.4.1 WorkspaceViewController . . . 47

3.4.2 Vizu´aln´ı komponenty . . . 47

3.4.3 Ukl´ad´an´ı a sd´ılen´ı instanc´ı . . . 48

3.4.4 Oˇsetˇrov´an´ı ud´alost´ı . . . 50

3.4.5 Princip aktualizace uˇzivatelsk´ych rozhran´ı . . . 52

4 Demonstraˇcn´ı aplikace 54

5 N´amˇety pro dalˇs´ı rozˇs´ıˇren´ı 56

5.1 Znaˇckovac´ı jazyk pro UI . . . 56

5.2 Zamyk´an´ı vizu´aln´ıch komponent . . . 56

5.3 Propagace ud´alost´ı pˇres socketov´e spojen´ı . . . 57

5.4 UI komponenta pro instantn´ı formul´aˇr . . . 57

6 Bˇehov´a platforma 58 6.1 Doporuˇcen´a konfigurace serveru . . . 58

6.2 Kompatibilita . . . 60

6.3 V´ykon . . . 60

Z´avˇer 62

Pouˇzit´a literatura 63

Pˇr´ıloha A - Obsah pˇriloˇzen´eho CD 66

Seznam pouˇ zit´ ych zkratek

TCP Transmission Control Protocol, protokol pro pˇrenos dat v internetu, se zaruˇcen´ym doruˇcen´ım datagram˚u

HTTP HyperText Trasnport Protokol, protokol aplikaˇcn´ı vrstvy pouˇz´ıvan´y pro pˇrenos obsahu webov´ych str´anek v internetu

PHP Rekurzivn´ı zkratka, PHP Hypertext Preprocesor, skriptovac´ı programo- vac´ı jazyk

HHVM HipHop Virtual Machine, bˇehov´a platforma transformuj´ıc´ı PHP skripty na pˇredkompilovan´y k´od

CGI Common Gateway Interface, rozhran´ı pro propojen´ı extern´ıch aplikac´ı s webov´ym serverem

FPM FastCGI Process Manager

ZMQ ZeroMQ, Zero Message Queue, knihovna pro v´ymˇenu zpr´av prostˇrednictv´ım fronty

JSON JavaScript Object Notation, zaˇckovac´ı jazyk pro reprezentaci (nejen) javascriptov´ych objekt˚u

XML eXtensible Markup Language, obecn´y rozˇs´ıˇriteln´y znaˇckovac´ı jazyk W3C World Wide Web Consortium, konsorcium spravuj´ıc´ı webov´e standarty MVC Model Wiew Controller, n´avrhov´y vzor softwarov´e architektury

WS Web Socket, protokol pro pˇrenos dat na pozad´ı str´anek

CSS Cascading Style Sheets, kask´adov´e styly pro ´upravu vizu´aln´ı podoby webov´ych str´anek

JS JavaScript, skriptovac´ı jazyk pouˇz´ıvan´y ve webov´ych prohl´ıˇzeˇc´ıch DOM Document Object Model, objektov´a reprezentace HTML dokumentu OOP Object Oriented Pprogramming, objektovˇe orientovan´e programov´an´ı UI User Interface, uˇzivatelsk´e rozhran´ı

ORM Object Relational Mapping, technika pro automatickou konverzi mezi relaˇcn´ı datab´az´ı a aplikaˇcn´ımi objekty

Seznam ilustrac´ı a graf˚ u

1 Diagram zp˚usobu zaˇclenˇen´ı nov´ych komponent do frameworku Phem 33

2 V´yvojov´y diagram funkce dispatchRequest . . . 35

3 Struktura zaˇclenˇen´e knihovny Twitter Bootstrap . . . 38

4 Pˇr´ılad v´ypisu aktivn´ıch uˇzivatel˚u, sezen´ı a spojen´ı . . . 44

5 Pˇrehled z´akldn´ıch tˇr´ıd vizu´aln´ıch komponent . . . 48

6 Uvodn´ı str´´ anka demonstraˇcn´ı aplikace . . . 54

7 Formul´aˇrov´a okna z demonstraˇcn´ı aplikace . . . 55

8 Pˇrehledov´e sch´ema doporuˇcen´e platformy . . . 59

9 V´ykonnostn´ı srovn´an´ı bˇehov´ych platforem . . . 61

Seznam tabulek

2 Pˇrehled um´ıstˇen´ı soubr˚u se zdroji pro klientskou stranu . . . 37

3 Pˇr´ıpustn´e hodnoty pro MESSAGEBUS MODE . . . 40

4 Pˇr´ıpustn´e hodnoty pro WEBSOCKET PULLER MODE . . . 42

5 Varianty metody notify pro r˚uzn´e typy adresace . . . 44

6 Pˇrehled anotac´ı pro mapov´an´ı vlastnost´ı vizu´aln´ıch komponent . . . . 52

7 Typy aktualizac´ı uˇzivatelsk´eho rozhran´ı . . . 53

Seznam zdrojov´ ych k´ od˚ u

1 Pˇr´ıklad implementace zavadˇeˇce knihovny zdroj˚u . . . 39

2 Pˇr´ıklad vytvoˇren´ı a odesl´an´ı zpr´avy . . . 45

3 Inicializace workspacu s nastaven´ım rozsahu platnosti . . . 50

4 Oˇsetˇren´ı ud´alosti OnChange komponenty TextBox . . . 50

Konvence v sazbˇ e

• Barevnˇe, neproporcion´aln´ım p´ısmem jsou ps´any n´azvy tˇr´ıd a jmenn´ych prostor

• kurz´ıvou jsou ps´any n´azvy funkc´ı a atribut˚u

• neproporcion´aln´ım jsou zv´yraznˇeny cesty a URL adresy a tak´e uk´azky k´odu (v ohraniˇcen´ych segmentech)

• KAPIT ´ALKAMI S PODTRˇZ´ITKY m´ısto mezer a bez diakritiky jsou ps´any konfiguraˇcn´ı konstanty

• ”kurz´ıvou v anglick´ych uvozovk´ach” jsou ps´any ˇretˇezcov´e hodnoty

Uvod ´

Od okamˇziku, kdy Tim Berners-Lee spustil historicky prvn´ı webov´y server s prvn´ımi webov´ymi str´ankami, napsan´ymi ve znaˇckovac´ım jazyce HTML, uplyne letos ˇctyˇriadvacet let. Bˇehem t´eto doby uˇcinili technologie pro v´yvoj a provoz webov´ych str´anek nesm´ırn´y pokrok. Zat´ımco v poˇc´atc´ıch se jednalo pouze o prost´y text pro- pojen´y hypertextov´ymi odkazy, dnes vˇetˇsina web˚u nab´ız´ı pestr´y multimedi´alnˇe in- teraktivn´ı obsah, generovan´y a obsluhovan´y robustn´ımi aplikacemi. Tuto promˇenu doprov´azela cel´a ˇrada v´yznamn´ych miln´ık˚u. V n´asleduj´ıc´ıch ˇctyˇrech odstavc´ıch pˇribl´ıˇz´ım ˇctyˇri nejv´yznamnˇejˇs´ı.

Jedn´ım z prvn´ıch z´asadn´ıch nedostatk˚u webov´ych str´anek, kter´y zaˇcali jejich tv˚urci ˇreˇsit, byla nutnost stahovat cel´y obsah pˇri pr˚uchodu str´ankami znovu i pˇres to, ˇze zmˇena obsahu byla nepatrn´a. Tato skuteˇcnost byla nepˇr´ıjemn´a zejm´ena v dobˇe kdy se rychlost bˇeˇzn´eho uˇzivatelsk´eho pˇripojen´ı k internetu pohybovala pouze v ˇr´adech jednotek kilobyt˚u za sekundu. S ˇreˇsen´ım pˇriˇsla spoleˇcnost Netscape, kter´a v roce 1996 zavedla a prosadila podporu r´amc˚u (frames), pomoc´ı kter´ych bylo moˇzn´e str´anky rozdˇelovat na segmenty a v kaˇzd´em z nich zobrazovat jin´y dokument. Pˇri navigaci str´ankami pak staˇcilo napˇr´ıklad aktualizovat obsah pouze vybran´eho seg- mentu.

Pozdˇeji se uk´azalo, ˇze r´amce nejsou ide´aln´ım ˇreˇsen´ım z hlediska indexov´an´ı vy- hled´avac´ımi roboty, bezpeˇcnostn´ıch rizik, ˇci skriptov´an´ı na stranˇe prohl´ıˇzeˇce. Asyn- chronn´ı aktualizace str´anek se zaˇcala ˇreˇsit pomoc´ı r˚uzn´ych z´asuvn´ych modul˚u tˇret´ıch stran, jako napˇr´ıklad Java applety poskytuj´ıc´ı rozhran´ı pro javascriptov´e funkce nebo Flash embed objekty. Pˇrevratn´y zlom v tomto ohledu nastal aˇz zaˇc´atkem roku 2006, kdy vˇetˇsina majoritnˇe pouˇz´ıvan´ych prohl´ıˇzeˇc˚u jiˇz implementovala XMLHtt-

kter´a umoˇzˇnuje jednoduch´ym zp˚usobem dynamicky naˇc´ıtat souˇc´asti str´anky ze ser- veru pomoc´ı HTTP poˇzadavk˚u prov´adˇen´ych na pozad´ı.

Dalˇs´ı v´yzvou se stala ot´azka, jak efektivnˇe aktualizovat obsah str´anky v oknˇe prohl´ıˇzeˇce, na z´akladˇe ud´alost´ı na serveru. Nedlouho pot´e, co se ujala technologie Ajax, koncem roku 2006 se objevila ˇrada web˚u, vˇcetnˇe Meebo, Gmailu ˇci Facebooku, kter´a zaˇcala vyuˇz´ıvat Ajax poˇzadavky vyˇck´avaj´ıc´ı na serveru na relevantn´ı ud´alost.

Server odpov´ıd´a vˇzdy aˇz v okamˇzik, kdy m´a potˇrebu informovat klienta o nov´e ud´alosti nebo zmˇenˇe. Tento princip se zaˇcal oznaˇcovat jako Comet, Ajax push ˇci reverse Ajax.

Aˇckoliv se Comet princip vyuˇz´ıv´a dodnes, s nar˚ustaj´ıc´ım objemem takto pˇren´aˇsen´ych informac´ı se v´yvoj´aˇri zaˇcali zab´yvat ot´azkou reˇzie HTTP proto- kolu. Postupnˇe byla do prohl´ıˇzeˇc˚u implementov´ana podpora pro technologii Web- Socket, kter´a umoˇzˇnuje vytvoˇrit permanentn´ı spojen´ı mezi klientem a serverem a prostˇrednictv´ım tohoto spojen´ı pˇred´avat zpr´avy o veˇsker´ych zmˇen´ach na obou stran´ach. WebSocket byl standardizov´an konsorciem W3C v roce 2011, jeho pod- pora prohl´ıˇzeˇci vˇsak dodnes nen´ı stoprocentn´ı.

Pˇredmˇetem t´eto pr´ace je tvorba frameworku pro dynamick´a rozhran´ı webov´ych apli- kac´ı, emuluj´ıc´ı desktopov´e programov´an´ı. Pojmem dynamick´e rozhran´ı webov´e apli- kace se rozum´ı takov´e aplikaˇcn´ı rozhran´ı, kter´e klade vysok´e poˇzadavky na soubˇeˇzn´y pˇr´ıstup v´ıce uˇzivatel˚u ve stejn´y okamˇzik a na asynchronn´ı aktualizaci zobrazovan´ych dat v re´aln´em ˇcase. Tyto aktualizace jsou zpravidla vyvol´av´any jin´ymi uˇzivateli, ˇci ud´alostmi na serveru, proto je zde nutn´e pouˇz´ıt nˇekterou z technologi´ı uveden´ych v pˇredchoz´ıch dvou odstavc´ıch. Desktopov´e programov´an´ı je pak pouˇzito jako sou- hrnn´e oznaˇcen´ı pro v´yvojov´e techniky pouˇz´ıvan´e pˇri programov´an´ı desktopov´ych aplikac´ı, kde je moˇzn´e jednoduch´ym zp˚usobem definovat ovl´adac´ı prvky a pˇriˇradit jim obsluˇzn´e metody pro r˚uzn´e typy ud´alost´ı.

V desktopov´em programov´an´ı narozd´ıl od webov´eho nen´ı nutn´e pouˇz´ıvat kromˇe prim´arn´ıho v´yvojov´eho jazyka ˇz´adn´y dalˇs´ı znaˇckovac´ı jazyk, skripty pro stranu prohl´ıˇzeˇce, kask´adov´e styly ani napˇr´ıklad soubory s ˇsablonami. Vˇse je soustˇredˇeno na jedno m´ısto. Pˇr´ıkladem platformy pro desktopov´e programov´an´ı m˚uˇze b´yt napˇr´ıklad Windows Forms nebo QT API.

Jazyk˚u a platforem pro tvorbu webov´ych aplikac´ı je dnes nepˇrebern´e mnoˇzstv´ı. Jazyk PHP byl pro realizaci t´eto pr´ace zad´an pˇredevˇs´ım pro jeho rozˇs´ıˇrenost a obl´ıbenost mezi v´yvoj´aˇri. Napˇr´ıklad server W3Techs.com uv´ad´ı, ˇze k poˇc´atku roku 2014 t´emˇeˇr 82% webov´ych str´anek pouˇz´ıvalo pr´avˇe jazyk PHP.

1 Anal´ yza a zp˚ usob realizace

Zad´an´ı pr´ace zahrnuje pomˇernˇe obecn´e z´asady pro vypracov´an´ı. Jak jiˇz bylo zm´ınˇeno, jej´ım hlavn´ım c´ılem bylo realizovat komponenty specializovan´eho fra- meworku pro jazyk PHP, umoˇzˇnuj´ıc´ı vyv´yjet webov´e aplikace s komfortem desk- topov´eho programov´an´ı. Vzhledem k n´avaznosti na komerˇcn´ı projekt a pˇredeˇsl´ym zkuˇsenostem vˇsak bylo ´uvodn´ı snahou vytyˇcit podrobnˇejˇs´ı a pˇr´ısnˇejˇs´ı poˇzadavky na realizaci, aby se stal v´ysledek pr´ace skuteˇcnˇe pˇr´ınosn´ym a mohl b´yt d´ale v praxi vyuˇzit. V t´eto kapitole budou, vyjma pˇredstaven´ı stanoven´ych poˇzadavk˚u, d´ale pops´any veˇsker´e zvaˇzovan´e koncepty a myˇslenky t´ykaj´ıc´ı se realizace. Podstatn´a ˇc´ast je zde tak´e vˇenov´ana v´ysledk˚um ´uvodn´ı reˇserˇse a popisu dostupn´ych techno- logi´ı, kter´e pro realizaci pˇrich´azeli v ´uvahu.

Pˇri sestavov´an´ı podrobnˇejˇs´ıch poˇzadavk˚u pro realizaci vyplynulo, ˇze framework, pouˇzit´y v realizovan´em ˇreˇsen´ı, by mˇel m´ıt zejm´ena tyto vlastnoti:

• Modularita a snadn´a rozˇs´ıˇritelnost

• Pˇrizp˚usobitelnost a pˇredefinovatelnost funkcionality jednotliv´ych souˇc´ast´ı

• Pˇrehledn´a struktura a jednotn´e konvence

• Vysok´y v´ykon a propustnost

• Podpora r˚uzn´ych bˇehov´ych platforem a kompatibilita s HHVM

V r´amci sv´e podnikatelsk´e ˇcinnosti jsem koncem roku 2012 inicioval v´yvoj nov´eho frameworku pro makl´eˇrskou spoleˇcnost Credit & Hypo Consult, kter´a provozuje internetov´e srovn´avaˇce produkt˚u z oblasti pojiˇst’ovnictv´ı. Framework vznikal v r´amci rozs´ahl´eho projektu a postupnˇe se pro nˇej vˇzil n´azev Phem. Hlavn´ı motivac´ı pro jeho vznik byla snaha vybrat to nejlepˇs´ı z jiˇz existuj´ıc´ıch framework˚u a n´astroj˚u, dostupn´ych pod licenc´ı permisivn´ıho typu a d´ale doplnit nˇekter´e souˇc´asti, pro kter´e v PHP neexistovala uspokojiv´a implementace. Nav´ıc bylo pˇri jeho v´yvoji db´ano na

dodrˇzen´ı v´yˇse zm´ınˇen´ych vlastnost´ı. Framework Phem se tedy jevil jako vhodn´y z´aklad pro realizaci komponent, jeˇz jsou pˇredmˇetem t´eto pr´ace, nakonec byl pro realizaci i vybr´an. Nicm´enˇe, jak bylo nast´ınˇeno v ´uvodu, v´yvoj technologi´ı pro tvorbu webov´ych str´anek postupuje velmi rychle, a proto byla zvaˇzov´ana i moˇznost pouˇzit jako z´aklad jin´y modern´ı framework, nebo zaˇc´ıt ´uplnˇe od z´akladu. Podrobnˇejˇs´ımu pr˚uzkumu a srovn´an´ı framework˚u je vˇenov´ana sekce 1.1. Pˇredstaven´ı frameworku Phem je vˇenov´ana samostatn´a kapitola 2.

Bezprostˇrednˇe po v´ybˇeru z´akladov´eho frameworku bylo nutn´e vytvoˇrit koncept cel´e architektury nov´ych frameworkov´ych souˇc´ast´ı, kter´e umoˇzn´ı v´yvoj obdobn´ym zp˚usobem jako v pˇr´ıpadˇe desktopov´ych aplikac´ı a kter´e umoˇzn´ı sd´ılen´ı definovan´ych vizu´aln´ıch komponent mezi v´ıce uˇzivateli. Vytvoˇren´y koncept je pops´an v sekci 1.2.

Z tohoto konceptu ihned vyvstalo nˇekolik dalˇs´ıch ot´azek, kter´e bylo nutn´e pˇred sa- motnou realizac´ı vyˇreˇsit. Prvn´ı z nich se t´ykala persistence vytvoˇren´ych instanc´ı vizu´aln´ıch komponent, kter´e je nutn´e ukl´adat do ´uloˇziˇstˇe spoleˇcn´eho pro vˇsechny uˇzivatele. Dalˇs´ı ot´azka byla spjata s moˇzn´ymi zp˚usoby, jak efektivnˇe vymˇeˇnovat zpr´avy a upozorˇnovat uˇzivatele o zmˇen´ach vyvolan´ych jin´ymi uˇzivateli. Jin´ymi slovy, kter´a z push technologi´ı by mˇela b´yt pouˇzita. Posledn´ı z´asadn´ı ot´azkou pak byla rychlost a propustnost a s t´ım spjat´a moˇznost vyuˇzit´ı technologie HHVM. Vˇsechny tyto zm´ınˇen´e ot´azky jsou podrobnˇeji ˇreˇseny ve tˇrech odpov´ıdaj´ıc´ıch podsekc´ıch na konci t´eto kapitoly.

1.1 Dostupn´ e frameworky a n´ astroje

Z nepˇrebern´eho mnoˇzstv´ı dostupn´ych PHP framework˚u bylo v r´amci reˇserˇse vybr´ano a podrobnˇeji prozkoum´ano pouze nˇekolik takov´ych, kter´e jsou v posledn´ı dobˇe mezi v´yvoj´aˇri velmi obl´ıben´e a sv´ymi vlastnostmi se pˇribliˇzuj´ı poˇzadavk˚um, stanoven´ym v t´eto pr´aci. Kaˇzd´emu z nich byly za kaˇzdou poˇzadovanou vlastnost udˇeleny body v rozsahu 1-5 za to, do jak´e m´ıry byly shled´any v dan´em smˇeru vyhovuj´ıc´ımi.

1.1.1 Symfony

Symfony je framework vyv´ıjen´y ˇc´asteˇcnˇe komerˇcn´ı firmou SensioLabs a ˇc´asteˇcnˇe komunitou, distribuovan´y pod MIT licenc´ı. Symfony (dnes jiˇz ve verzi 2.4) je jedn´ım z nejobl´ıbenˇejˇs´ıch PHP framework˚u a d´ıky tomu je dobˇre dokumentov´an a ˇsiroce podporov´an komunitou.

Modularita a snadn´a rozˇsiˇritelnost: Jelikoˇz Symfony samotn´e m´a architekturu jako stavebnice, lze pouˇz´ıt jen vybran´e moduly v libovoln´e kombinaci, tak i moduly Sym- fony frameworku jsou navrˇzeny velmi obecnˇe. V podstatˇe se jedn´a o samostatn´e apli- kace, protoˇze z principu Symfony nemaj´ı ˇz´adnou jistotu s ˇc´ım budou spolupracovat.

Proto je moˇzn´e je snadno vyuˇz´ıt i v jin´ych php frameworc´ıch. Zisk bod˚u: 4/5.

Prizp˚usobitelnost a pˇredefinovatelnost funkcionality jednotliv´ych souˇc´ast´ı: Symfony k tomuto probl´emu pˇristupuje sv´ym zp˚usobem a to tak ˇze pokud nˇejak´y modul nevyhovuje potˇreb´am, prostˇe se vymˇen´ı za jin´y. Pˇr´ıpadnˇe je moˇzn´e st´avaj´ıc´ı moduly pˇrepsat nebo doplnit, jelikoˇz licence Symfony to umoˇzˇnuje. Zisk bod˚u: 3/5.

Pˇrehledn´a struktura a jednotn´e konvence: Symfony jako tradiˇcn´ı framework m´a uˇz ust´alen´e konvence a kv˚uli samostatn´ym a dobˇre dokumentovan´ym komponent´am jsou jasn´e jejich zodpovˇednosti. Na druhou stranu stavebnicov´a struktura Symfony znamen´a, ˇze v´yvoj´aˇri nemaj´ı k dispozici vˇzdy jednoznaˇcn´y z´aklad, protoˇze se mezi projekty struktura frameworku liˇs´ı. Zisk bod˚u: 4/5.

Vysok´y v´ykon a propustnost: Symfony je pomˇernˇe mohutn´y framework ale ve sv´e dlouh´e historii proˇsel nˇekolika optimalizaˇcn´ımi vlnami, naposledy mezi verzemi 1.4 a 2, takˇze dnes patˇr´ı k tˇem rychlejˇs´ım PHP framework˚um. Ovˇsem kv˚uli zp˚usobu, jak´ym toho dociluje – bytecode cache – bude tento n´askok z vˇetˇs´ı ˇc´asti negov´an pˇri pouˇzit´ı HHVM. Zisk bod˚u: 2/5.

Podpora r˚uzn´ych bˇehov´ych platforem a kompatibilita s HHVM: Podpora HHVM v Symfony kupodivu jeˇstˇe nen´ı perfektn´ı, podle posledn´ıch dat 98.9%. 3/5

1.1.2 Larvel

Pravdˇepodobnˇe nejmladˇs´ı a v posledn´ı dobˇe t´emˇeˇr nejrozˇs´ıˇrenˇejˇs´ı PHP framwork je Larvel, kter´y byl vyvinut Taylorem Otwellem a je vyd´avan´y pod MIT licenc´ı. Je zaloˇzen´y na Symfony a jeho aktu´aln´ı k´od je dostupn´y na serveru GitHub.

Modularita a snadn´a rozˇsiˇritelnost: Larvel obsahuje bal´ıˇckovac´ı syst´em Bundles, kter´y umoˇzˇnuje pˇridat do projektu nespoˇcet jiˇz hotov´ych komponent. Jeho pouˇzit´ı je velmi jednoduch´e a intuitivn´ı. Zisk bod˚u: 5/5.

Pˇrizp˚usobitelnost a pˇredefinovatelnost funkcionality jednotliv´ych souˇc´ast´ı:

Pˇrizp˚usobitelnost souˇc´ast´ı je v Larvelu velmi obt´ıˇzn´a, avˇsak za norm´aln´ıch okolnost´ı se s n´ı zde nepoˇc´ıt´a, jelikoˇz 99% cel´eho frameworku je um´ıstˇeno mezi dalˇs´ımi z´avislostmi ve sloˇzce vendor. Pokud je u nˇekter´e funkce ˇci komponenty poˇzadov´ana jin´a funkcionalita, neˇz v´ychoz´ı, je pravdˇepodobnˇe lepˇs´ı vyuˇz´ıt jin´y dostupn´y bundle. Zisk bod˚u: 4/5.

Pˇrehledn´a struktura a jednotn´e konvence: Struktura adres´aˇr˚u novˇe vytvoˇren´eho projektu v Larvelu je pomˇernˇe chaotick´a a zabere hodnˇe ˇcasu se v n´ı zoriento- vat. Nepˇrehledn´e je i uspoˇr´ad´an´ı konfiguraˇcn´ıch soubor˚u v nov´em projektu. ˇC´asti aplikace se v Larvelu p´ıˇs´ı mimo jak´ykoliv jmenn´y prostor Zisk bod˚u: 3/5.

Vysok´y v´ykon a propustnost: Ve srovn´an´ı s ostatn´ımi frameworky dosahuje ve vˇetˇsinˇe test˚u pˇri provozu na bˇeˇzn´ych PHP interpretrech pr˚umˇern´ych v´ysledk˚u. Toto vˇsak nepˇredstavuje velk´y probl´em. vzhledem k plnˇe kompatibilitˇe ze strany HHVM.

Zisk bod˚u: 4/5.

Podpora r˚uzn´ych bˇehov´ych platforem a kompatibilita s HHVM: Dle posledn´ıch v´ysledk˚u unit test˚u toho frameworku pro HHVM bylo dosaˇzeno 100% kompatibility.

Zisk bod˚u: 5/5.

1.1.3 Kohana

Kohana je komunitou vyv´ıjen´y framework vyd´avan´y pod BSD Licenc´ı, vytvoˇren´y pˇredevˇs´ım pro jiˇz zkuˇsen´e PHP v´yvoj´aˇre, kter´ym nab´ız´ı vyˇsˇs´ı flexibilitu neˇz jin´e frameworky zejm´ena kv˚uli atypick´emu struktur´aln´ımu n´avrhu, kter´emu ˇr´ık´a

”casca- ding filesystem”(´uzce souvis´ı s modularitou a pˇredefinovatelnost´ı, bude vysvˇetleno d´ale), ale i napˇr´ıklad kv˚uli pokroˇcil´emu routingu.

Modularita a snadn´a rozˇsiˇritelnost: Modularita je kl´ıˇcovou vlastnost´ı Kohany. Vzhle- dem k tomu ˇze moduly mohou pracovat s ˇc´ımkoliv jako vlastn´ı aplikace a dokonce i na ´urovni j´adra je obvykl´y model alespoˇn 90% k´odu i specifick´ych aplikac´ı pˇresouvat do modul˚u. Pro nˇekter´e typick´e pˇr´ıpady se ovˇsem hod´ı pevnˇeji definovan´a, ud´alostmi ˇr´ızen´a modularizace, kterou Kohana nepodporuje. Zisk bod˚u: 4/5.

Pˇrizp˚usobitelnost a pˇredefinovatelnost funkcionality jednotliv´ych souˇc´ast´ı: Kohana pˇristupuje ke vztahu j´adro-moduly-aplikace nekonvenˇcnˇe. Na rozd´ıl od tradiˇcn´ıch framework˚u kter´e pro kaˇzd´y z tˇechto prvk˚u definuj´ı specifickou strukturu a pevn´a pravidla pro interakci, Kohana ve vˇsech kop´ıruje stejnou strukturu a pro v´ysledn´e chov´an´ı se jejich obsah zkombinuje. V pˇr´ıpadˇe konflikt˚u maj´ı soubory z aplikace nejvyˇsˇs´ı prioritu, d´ale pak moduly a nakonec syst´em. Tento koncept se v Kohanˇe naz´yv´a

”cascading filesystem”a umoˇzˇnuje z modul˚u nebo aplikace libovolnˇe zmˇenit fungov´an´ı j´adra bez jeho pˇr´ım´eho pˇreps´an´ı. Zisk bod˚u: 5/5.

Pˇrehledn´a struktura a jednotn´e konvence: Kohana kv˚uli c´ılen´ı na pokroˇcil´e v´yvoj´aˇre nevynucuje pˇr´ıliˇs konvenc´ı. Pˇrestoˇze je architektura pr˚uzraˇcn´a, snadno se stane nepˇrehlednou. Pˇredevˇs´ım kv˚uli tomu, ˇze moduly nejsou explicitnˇe rozdˇelen´e podle zodpovˇednost´ı – jak´ykoliv modul m˚uˇze obsahovat cokoliv. Zisk bod˚u: 1/5.

Vysok´y v´ykon a propustnost: Kohana sama o sobˇe je extr´emnˇe odlehˇcen´a a proto i rychl´a, ale z´avis´ı na spr´avnˇe pouˇzit´e modularizaci. Zisk bod˚u: 4/5.

Podpora r˚uzn´ych bˇehov´ych platforem a kompatibilita s HHVM: Podpora HHVM v Kohanˇe se postupnˇe zlepˇsuje. Dˇr´ıve bylo nutn´e pouˇz´ıt HHVM modul, nyn´ı je

kompatibilita Kohany s HHVM 99.19% kde posledn´ı probl´emy jsou s cachingem, takˇze Kohana je pod HHVM pouˇziteln´a. Zisk bod˚u: 4/5.

1.1.4 Phem

Framework Phem, rozˇsiˇrovan´y v r´amci t´eto pr´ace, je pomˇernˇe podrobnˇe pops´an v kapitole 2, proto nen´ı tˇreba jej zde popisovat pˇr´ıliˇs detailnˇe. Jeho pˇrednost´ı je jednoduchost, pˇrehlednost a snaha ˇreˇsit vˇeci jin´ym zp˚usobem, podobaj´ıc´ım se sp´ıˇse ˇreˇsen´ım z platforem Java a Microsoft .NET. Z´aroveˇn je z velk´e ˇc´asti inspirovan´y frameworky Symfony2 a Nette.

Modularita a snadn´a rozˇs´ıˇritelnost: K dispozici jsou dvˇe moˇznosti rozˇsiˇrov´an´ı fra- meworku - pomoc´ı vlastn´ı implementace BootStrapperu ˇci prostˇrednictv´ım Com- poseru. Moduly tˇret´ıch stran, zahrnut´e ve v´ychoz´ı instalaci, lze nav´ıc v pˇr´ıpadˇe potˇreby snadno odebrat. Zisk bod˚u: 5/5.

Pˇrizp˚usobitelnost a pˇredefinovatelnost funkcionality jednotliv´ych souˇc´ast´ı: Pod- statn´e souˇc´asti lze pˇredefinovat vlastn´ı implementac´ı abstraktn´ıch tˇr´ıd nebo roz- hran´ı. Z´aroveˇn jsou do konfiguraˇcn´ıch soubor˚u aplikace a frameworku zaneseny veˇsker´e relativn´ı cesty, sufixy, n´azvy v´ychoz´ıch implementac´ı apod. Souˇc´asti vˇsak nelze pˇrepisovat maskov´an´ım tak snadno jako napˇr´ıklad v Kohanˇe. Zisk bod˚u: 3/5.

Pˇrehledn´a struktura a jednotn´e konvence: Struktura frameworku je pˇrehledn´a, nepˇr´ıliˇs hlubok´a a logicky uspoˇr´adan´a. Jmenn´e konvence pro n´azvy tˇr´ıd a jmenn´ych prostor odpov´ıdaj´ı adres´aˇrov´e struktuˇre. Zisk bod˚u: 5/5.

Vysok´y v´ykon a propustnost: Z´akladn´ı kostra frameworku je velmi v´ykonn´a. Proble- matick´e mohou b´yt nˇekter´e komponenty vyuˇz´ıvaj´ıc´ı reflexi. Vzhledem k moˇznosti cachov´an´ı a podpory HHVM to vˇsak nen´ı tak z´asadn´ı nedostatek. Zisk bod˚u: 4/5.

Podpora r˚uzn´ych bˇehov´ych platforem a kompatibilita s HHVM: V Bˇreznu 2014 v´yvoj´aˇri HHVM ozn´amili, ˇze na t´eto platformˇe jiˇz proch´azej´ı vˇsechny unit testy Doctrine2 a Twig. T´ım p´adem by mˇel b´yt s HHVM z kompatibiln´ı i framework Phem, jelikoˇz toto byly jedin´e dvˇe souˇc´asti, kter´e kompatibilitu omezovaly. Zisk bod˚u: 5/5.

1.1.5 Vyhodnocen´ı

Vˇsechny testovan´e frameworky nab´ızej´ı v z´akladn´ı funkcionalitˇe velmi podobn´e moˇznosti. Frameworku Phem byl nakonec upˇrednostnˇen zejm´ena kv˚uli dobr´ym zkuˇsenostem a zahrnut´ı nˇekter´ych komponent, kter´e by mohly b´yt uˇziteˇcn´e pro rea- lizaci t´eto pr´ace. Vyjma nˇej se jako nejperspektivnˇejˇs´ı jevil Larvel. Tabulka 1 zobra- zuje podrobn´e v´ysledky srovn´an´ı vybran´ych framework˚u, vˇcetnˇe celkov´eho z´ıskan´eho poˇctu bod˚u.

Tabulka 1: Srovn´an´ı vybran´ych framework˚u

N´azev Modul. Pˇrizp˚us. Strukt. V´ykon Kompat. Celkem

Symfony 4 3 4 2 3 16

Larvel 5 4 3 4 5 21

Kohana 4 5 1 4 4 18

Phem 5 3 5 4 5 22

1.2 Koncept uˇ zivatelsk´ eho rozhran´ı

Navrˇzeno bylo rozhran´ı, kter´e sest´av´a ze tˇr´ı z´akladn´ıch typ˚u vizu´aln´ıch komponent.

Prvn´ım z nich je pracovn´ı plocha (workspace), kter´a sm´ı obsahovat libovoln´y poˇcet statick´ych ˇci pohybliv´ych oken (window). Tato okna tvoˇr´ı druh´y typ vizu´aln´ıch kom- ponent. Posledn´ım typem jsou pak ovl´adac´ı prvky (control), kter´e mohou b´yt v libo- voln´em poˇctu obsaˇzeny v oknech. K dispozici by mˇela b´yt z´akladn´ı sada ovl´adac´ıch

prvk˚u a dalˇs´ı by mˇely b´yt snadno doplniteln´e pomoc´ı rozˇs´ıˇren´ı jiˇz existuj´ıc´ıch ˇci jejich abstraktn´ıho pˇredka.

Veˇsker´e vytvoˇren´e instance pracovn´ıch ploch ˇci samostatn´ych oken by mˇely b´yt uloˇzeny v ´uloˇziˇsti aplikaˇcn´ıch promˇenn´ych a mˇela by existovat moˇznost sd´ılen´ı na tˇrech r˚uzn´ych ´urovn´ıch (mezi r˚uzn´ymi aktivn´ımi spojen´ımi, mezi sezen´ımi a mezi uˇzivateli). Veˇsker´e ud´alosti v oknˇe prohl´ıˇzeˇce by mˇely b´yt okamˇzitˇe propagov´any na server, kde se zapracuj´ı do modelov´ych dat konkr´etn´ı instance okna ˇci pracovn´ı plochy. Pokud je dan´e okno ˇci pracovn´ı plocha ve stejnou chv´ıli v r´amci sd´ılen´ı zobrazen´a i z jin´eho spojen´ı, toto by mˇelo b´yt neprodlenˇe notifikov´ano o nastal´e ud´alosti a zmˇen´ach.

1.3 Ukl´ ad´ an´ı aplikaˇ cn´ıch promˇ enn´ ych

Ukl´ad´an´ı promˇenn´ych, platn´ych v rozsahu cel´e aplikace lze v PHP realizovat mnoha zp˚usoby. Mezi nejbˇeˇznˇeji pouˇz´ıvan´e implementace ´uloˇziˇstˇe aplikaˇcn´ıch promˇenn´ych patˇr´ı:

• APC

• XCache

• Wincache

• Sd´ılen´a pamˇet’

• Relaˇcn´ı datab´aze

• Souborov´y syst´em

Vˇetˇsina modern´ıch framework˚u podporuje alespoˇn nˇekterou z v´yˇse uveden´ych im- plementac´ı. Prvn´ı tˇri z nich slouˇz´ı prim´arnˇe jako cache pro v´ystupy skript˚u, kter´e jsou vol´any opakovanˇe a nab´ızej´ı ˇradu funkc´ı pro snadnou manipulaci s ukl´adan´ymi a naˇc´ıtan´ymi daty. Posledn´ı tˇri implementace jsou sp´ıˇse m´enˇe vhodn´e. Ukl´ad´an´ı pˇr´ımo do sd´ılen´e pamˇeti vyˇzaduje obt´ıˇznou ´udrˇzbu, datab´aze je pˇr´ıliˇs robustn´ı a

souˇc´ast´ı kter´e je i jednoduch´e administraˇcn´ı rozhran´ı. Framework Phem aktu´alnˇe podporuje APC a XCache, coˇz se jev´ı jako dostateˇcn´a moˇznost volby.

1.4 V´ ymˇ ena zpr´ av a notifikace

V ´uvodu byly nast´ınˇeny dva zp˚usoby pro notifikaci okna prohl´ıˇzeˇce ze strany ser- veru. Tyto dva zp˚usoby byly jako nejˇcastˇeji pouˇz´ıvan´e nakonec tak´e zapracov´any do komponenty MessageBus. Pro ´uplnost jsou v t´eto sekci pops´any hlavn´ı dostupn´e technologie slouˇz´ıc´ı pro tento ´uˇcel. Jejich detailnˇejˇs´ı popis lze nal´ezt napˇr´ıklad v ka- pitole 2.3 kvalifikaˇcn´ı pr´ace Push-teknik p˚a webben (Bruks˚as et al., 2010).

1.4.1 Flash RTMP

Platforma Flash podporuje push metodu prostˇrednictv´ım protokolu Real Time Messaging (RTMP), kter´y je pouˇz´ıv´an pro pˇrenos dat mezi serverem a Flash klien- tem. RTMP komunikuje pˇres TCP/IP, ale m˚uˇze b´yt nahrazen du´aln´ım pˇripojen´ım pˇres HTTP. Jednou z nev´yhod RTMP je to, ˇze vyˇzaduje instalaci Flash pluginu do prohl´ıˇzeˇce.

1.4.2 Comet a dlouh´ e dotazov´ an´ı

V roce 1995 pˇredstavila spoleˇcnost Netscape techniku pro odes´ıl´an´ı webov´ych str´anek po v´ıce ˇc´astech vyuˇzit´ım MIME typu multipart/x-mixed-replace. Pozdˇeji na toto nav´azali modernˇejˇs´ı webov´e prohl´ıˇzeˇce, kter´e pomoc´ı XmlHttpRequest ob- jektu spolu s dalˇs´ım obsluˇzn´ym javascriptem vyuˇz´ıvat moˇznosti asynchronnˇe ak- tualizovat ˇc´asti str´anek. Tato technologie zaˇcala b´yt pozdˇeji naz´yv´ana jako AJAX (Asynchronous Javascript And XML) ˇci tak´e Ajax. Ajax Comet ˇci Ajax Push je pak oznaˇcov´ana jeˇstˇe modernˇejˇs´ı technika zaloˇzen´a na poˇzadavc´ıch tohoto typu. V tomto pˇr´ıpadˇe je vˇsak poˇzadavek umˇele zdrˇzov´an na serveru a vyˇck´av´a do doby kdy jsou dostupn´a relevantn´ı data pro odpovˇed’. Jakmile je odpovˇed’ doruˇcena spojen´ı se ukonˇc´ı, ale okamˇzitˇe se nav´aˇze nov´e.

1.4.3 XHRStreaming

Technologie XmlHttpRequestStreaming (XHRStreaming), obˇcas t´eˇze naz´yvan´a jako HTTP streaming, funguje velice podobnˇe jako dlouh´e dotazov´an´ı, s t´ım rozd´ılem, ˇze spojen´ı se udrˇzuje aktivn´ı po celou dobu zobrazen´ı str´anky. Toho je dosaˇzeno tak, ˇze server odpov´ıd´a po ˇc´astech bloky javascriptov´eho k´odu. V´yhodou tohoto ˇreˇsen´ı oproti pˇredchoz´ımu je menˇs´ı reˇzie pˇrenesen´ych dat a vyˇsˇs´ı v´ykon. Nev´yhodou je ˇsak podpora pouze prohl´ıˇzeˇci zaloˇzen´ymi na j´adrech Gecko a Webkit.

1.4.4 WebSocket

WebSocket je nov´y standard zahrnut´y v HTML5. Umoˇzˇnuje otevˇr´ıt obousmˇern´e spojen´ı mezi prohl´ıˇzeˇcem a serverem, zaloˇzen´e na TCP socketu. ˇCasto je oznaˇcov´an za ”skuteˇcn´y”push, pro odliˇsen´ı od simulace pomoc´ı dlouh´eho dotazov´an´ı a jin´ych technik. Po standardizaci konsorciem W3C je pravdˇepodobn´e, ˇze se WebSocket brzy stane prim´arn´ım zp˚usobem pro implementaci push techniky. V souˇcasn´e dobˇe vˇsak z˚ust´av´a probl´emem kompatibilita se starˇs´ımi prohl´ıˇzeˇci, proto b´yv´a WebSocket ˇcasto doplnˇen o nˇejakou rezervn´ı alternativu v pˇr´ıpadˇe, ˇze nen´ı dan´ym prohl´ıˇzeˇcem pod- porov´an.

1.5 Technologie HHVM a jej´ı podpora

Jak je ps´ano napˇr´ıklad v jednom z ned´avno vydan´ych ˇcl´ank˚u o HHVM (Berchet, 2014), historie t´eto technologie, jej´ıˇz pln´y n´azev zn´ı HipHop Virtual Machine (t´eˇz HipHop for PHP), se zaˇcala ps´at aˇz v roce 2008. V t´e dobˇe na jej´ım v´yvoji zaˇcala pra- covat spoleˇcnost Facebook. HHVM by mˇelo ˇreˇsit jeden z nejz´asadnˇejˇs´ıch probl´emu PHP, kter´ym je rychlost. PHP je skriptovac´ı jazyk, kter´y je nutn´e interpretovat pˇri kaˇzd´em poˇzadavku. V nˇekter´ych pˇr´ıpadech lze sice vyuˇzit´ım cache v´ysledky nˇekter´ych frekventovan´ych dotaz˚u ukl´adat a pouˇz´ıvat opakovanˇe, nicm´enˇe PHP svou rychlost´ı nikdy nebylo schopn´e pˇrekonat konkurenˇcn´ı platformy jako ASP.NET ˇci

Princip ˇcinnosti HHVM spoˇc´ıv´a v lexik´aln´ı anal´yze a transformaci PHP skript˚u do vysoko´urovˇnov´eho byte k´odu. Tento k´od je n´aslednˇe za bˇehu pomoc´ı just-in- time (JIT) kompil´atoru pˇrekl´ad´an do nativn´ıho k´odu dan´e poˇc´ıtaˇcov´e architektury.

HHVM se tedy v tomto ohledu chov´a podobnˇe jako .NET nebo JRE. Pro zv´yˇsen´ı efektivity a komfortu v´yvoje byl nav´ıc pro HHVM vyvinut jazyk Hack, kter´y m´a t´emˇeˇr stejnou syntaxi jako PHP a zav´ad´ı do jazyka silnou typovost, generick´e tˇr´ıdy, lambda v´yrazy a dalˇs´ı prvky modern´ıch vysoko´urovˇnov´ych jazyk˚u. V´yhodou je, ˇze Hack a PHP lze v r´amci jednoho projektu kombinovat. Pˇri pouˇzit´ı Hacku je vˇsak tˇreba poˇc´ıtat, ˇze danou aplikaci nebude moˇzn´e provozovat napˇr. na jin´em serveru s bˇeˇzn´ym PHP interpretrem.

Jelikoˇz jde o technologickou novinku, kter´a se vˇetˇs´ıho rozˇs´ıˇren´ı a pouˇzitelnosti doˇckala aˇz poˇc´atkem roku 2014, existuje st´ale ˇrada knihoven a n´astroj˚u, kter´e nejsou s HHVM stoprocentnˇe kompatibiln´ı. Podrobnosti o kompatibilitˇe jsou zm´ınˇeny v z´avˇeru t´eto pr´ace, v kapitole 6.

2 Pˇ redstaven´ı frameworku Phem

Jak jiˇz bylo naznaˇceno v pˇredchoz´ı kapitole, framework Phem vznikl jako souˇc´ast rozs´ahl´eho komerˇcn´ıho projektu a zat´ım nebyl zveˇrejnˇen ˇsirok´e veˇrejnosti. Je vˇsak velice pravdˇepodobn´e, ˇze tak bude v dohledn´e dobˇe uˇcinˇeno. Klasifikovat by se dal jako framework postaven´y na klasick´e MVC architektuˇre typu push. Zpracov´av´an´ı poˇzadavku tedy zaˇc´ın´a v nˇekter´e z akc´ı definovan´ych dostupn´ymi controllery. Bˇehem zpracov´an´ı se pak vytvoˇr´ı datov´y model, kter´y se vloˇz´ı do v´ysledn´eho pohledu a ten je n´aslednˇe vykreslen a odesl´an jako tˇelo odpovˇedi. Podrobnˇe se princip˚um MVC vˇenuje napˇr´ıklad publikace Pro PHP MVC (Chris, 2012).

2.1 Z´ akladn´ı struktura

V adres´aˇri s webem, zaloˇzen´ym na tomto frameworku, se vˇzdy nach´azej´ı adres´aˇre Application a Framework a soubory application.conf.php, framework.conf.php, index.php a init.php. Tato struktura zajiˇst’uje striktn´ı oddˇelen´ı frameworku od konkr´etn´ı aplikace. Struktura adres´aˇre Framework bude pˇribl´ıˇzena v n´asleduj´ıc´ım odstavci. Struktura adres´aˇre s aplikac´ı je zcela voliteln´a, vhodn´e je vˇsak dodrˇzovat obdobnou strukturu jako v pˇr´ıpadˇe frameworku. Soubory application.conf.php a framework.conf.php obsahuj´ı veˇsker´e konfiguraˇcn´ı konstanty pro danou aplikaci i framework, kter´ymi lze ovlivnit v´ychoz´ı chov´an´ı a nastaven´ı cest, pˇr´ıstup˚u do datab´aze apod. Ve vˇetˇsinˇe pˇr´ıpad˚u vˇsak staˇc´ı upravovat soubor application.conf.php, do kter´eho je vhodn´e pˇrid´avat i veˇsker´e uˇzivatelem definovan´e konstanty. Soubor framwork.conf.php je nutn´e upravovat pouze ve v´yjimeˇcn´ych pˇr´ıpadech, napˇr´ıklad pokud je framework zahrnut do jin´e aplikace jako podadres´aˇr. Soubor index.php je vstupn´ım bodem a init.php slouˇz´ı k inicializaci

Struktura adres´aˇre Framework sest´av´a z n´asleduj´ıc´ıch poloˇzek:

• 3rdParty – Knihovny a z´avislosti tˇret´ıch stran

• ClassLoading – Automatick´e naˇc´ıt´an´ı tˇr´ıd

• Controllers – Z´akladn´ı univerz´aln´ı controllery

• Core – J´adro, obsahuj´ıc´ı prapˇredka – typ Object, kolekce, v´yjimky ˇci z´amky

• Environment – Prostˇred´ı, obsahuj´ıc´ı statick´e factory tˇr´ıdy, zejm´ena EnvironmentManager a Application

• Libraries – Vlastn´ı knihovny frameworku

• Resources – ˇSablony a zdroje pro stranu prohl´ıˇzeˇce – kask´adov´e styly, ja- vascripty, obr´azky a dalˇs´ı typy zdroj˚u

• Views – Univerz´aln´ı pohledy – napˇr´ıklad SimpleView pracuj´ıc´ı s ˇsablonami

Srdce frameworku tvor´ı automatick´e zavadˇeˇce tˇr´ıd (ClassLoadery), kter´e zajiˇst’uj´ı automatick´e naˇc´ıt´an´ı tˇr´ıd pomoc´ı PHP autoload funkc´ı. Vyjma nejsvrchnˇejˇs´ıch ad- res´aˇr˚u Framework resp. Application, kter´ym je pˇriˇrazen jmenn´y prostor (name- space)Phem resp. n´azev aplikace, je napˇr´ıˇc cel´ym frameworkem dodrˇzena konvence, ˇze kaˇzd´a tˇr´ıda je um´ıstˇena v samostatn´em souboru, v takov´em relativn´ım um´ıstˇen´ı, v jak´em se nach´az´ı jmenn´em prostoru. Nav´ıc soubor se tˇr´ıdou je vˇzdy, aˇz na pˇr´ıponu

”.php”, pojmenov´an stejnˇe jako dan´a tˇr´ıda. K dispozici jsou tˇri z´akladn´ı imple- mentace ClassLoader˚u, jedna pro naˇc´ıt´an´ı tˇr´ıd frameworku, dalˇs´ı pro naˇc´ıt´an´ı tˇr´ıd aplikace a posledn´ı pro naˇc´ıt´an´ı z´avislost´ı tˇret´ıch stran. Ta je o nˇeco kompliko- vanˇejˇs´ı, proto je pops´ana v samostatn´e sekci 2.2. Zavadˇeˇc tˇr´ıd pro aplikaci poˇc´ıt´a s dodrˇzen´ım stejn´e konvence, jak´a je dodrˇzena ve frameworku. V pˇr´ıpadˇe ˇze v´yvoj´aˇr aplikace hodl´a pouˇz´ıt konvence jin´e, je potˇreba aby si vytvoˇril vlastn´ı implementaci ClassLoaderu, odvozen´ım abstraktn´ı tˇr´ıdy Phem\ClassLoading\Loader a zajistil jej´ı aktivaci v inicializaˇcn´ım souboru aplikace, kter´y je tˇreba vˇzdy um´ıstit do sloˇzky s aplikac´ı. Tento soubor mus´ı b´yt pojmenov´an stejnˇe jako je pojmenov´ana dan´a aplikace v konfiguraˇcn´ım souboru, s extenz´ı

”*Boot.php”.

2.2 Rozˇ s´ıˇ ritelnost

Framework Phem lze snadno rozˇs´ıˇrit, vytvoˇren´ım komponenty tˇret´ı strany. Staˇc´ı vytvoˇrit podsloˇzku v um´ıstˇen´ı Framework/3rdParty a do n´ı kromˇe vlastn´ıho k´odu um´ıstit takzvan´y bootstrapper, kter´y zajist´ı jej´ı spr´avn´e naˇc´ıt´an´ı. Bootstrapper mus´ı dˇedit od abstraktn´ı tˇr´ıdyPhem\ClassLoading\Bootstrapping\Bootstrapper a mus´ı b´yt pojmenov´an stejnˇe jako vytvoˇren´a sloˇzka s extenz´ı

”*Boot.php”. V r´amci tohoto bootstraperu je nutn´e implementovat abstraktn´ı metodu load, ve kter´e lze napˇr´ıklad zaregistrovat vlastn´ı autoloader nebo ˇcistˇe staticky naˇc´ıst potˇrebn´e sou- bory pomoc´ı funkc´ı include ˇci require.

Jinou moˇznost´ı pro pˇripojen´ı knihoven tˇret´ıch stran je pouˇzit´ı Composeru, kter´y je jiˇz v´yˇse uveden´ym zp˚usobem zahrnut. Pokud v´yvoj´aˇr aplikace um´ı n´astroj Com- poser pouˇz´ıvat, staˇc´ı pouze upravit soubor composer.json v jeho adres´aˇri a nechat aktualizovat strom z´avislost´ı.

2.3 Zahrnut´ e knihovny tˇ ret´ıch stran

Prostˇrednictv´ım dvou princip˚u, popsan´ych v pˇredchoz´ı sekci (komponent tˇret´ıch stran ˇci Composeru) jsou do frameworku jiˇz v z´akladu pˇripojeny nˇekter´e element´arn´ı knihovny. Mezi tyto knihovny patˇr´ı zejm´ena Doctrine 2 ORM – objektovˇe relaˇcn´ı mapovac´ı n´astroj pro jednoduchou pr´aci s relaˇcn´ı datab´az´ı, ˇsablonovac´ı syst´em Twig ˇci knihovny pro import a export a konverzi soubor˚u (TFPDF, h2t, a dalˇs´ı).

2.4 Dalˇ s´ı funkcionalita a kl´ıˇ cov´ e komponenty

V t´eto sekci jsou pˇredstaveny ty nejpodstatnˇejˇs´ı funkce a vlastn´ı knihovny a kompo- nenty frameworku Phem. ´Uˇcelem zde nen´ı podrobn´a dokumentace vˇsech dostupn´ych tˇr´ıd a metod, ale pouze ilustrativn´ı pˇredstaven´ı.

2.4.1 Z´ akladn´ı controllery

Controllery a jednotliv´e ´ulohy (akce) lze definovat velmi snadn´ym zp˚usobem.

Kaˇzd´y controller by mˇel rozˇsiˇrovat tˇr´ıduPhem\Controllers\Controller, t´ım z´ısk´a z´akladn´ı schopnosti jako napˇr´ıklad automatick´e dosazov´an´ı argument˚u akc´ı, vyex- trahovan´ych z argument˚u HTTP poˇzadavku (GET a POST) dle jmenn´e konvence.

V pr˚ubˇehu zpracov´av´an´ı kter´ekoliv akce lze kdykoliv poˇzadavek pˇresmˇerovat do jin´e akce a to bud’ okamˇzitˇe a nebo ho napl´anovat, aby byl vykon´an po dokonˇcen´ı souˇcasn´e akce. Bˇehem pˇresmˇerov´an´ı lze pˇred´avat argumenty vnˇejˇskem (pˇres klient- skou stranu) i vnitˇrkem (pˇres doˇcasn´e ´uloˇziˇstˇe).

V pˇr´ıpadˇe, ˇze je pro nˇekter´y controller pouˇzita jako rodiˇcovsk´a tˇr´ıda Phem\Controllers\SimpleViewController, je v´yvoj´aˇri nab´ıdnuta dalˇs´ı implicitn´ı konvence, kter´a zajiˇst’uje jednoduch´e p´arov´an´ı akc´ı s v´ystupn´ı pohledy, realizo- van´ymi pomoc´ı Twig ˇsablon. Pokud je napˇr´ıklad nˇejak´y controller pojmenov´an DummyController a v nˇem je nadefinov´ana akce makelove, staˇc´ı ve sloˇzce se ˇsablonami (cesta lze nastavit v konfiguraci) vytvoˇrit podsloˇzku Dummy a v n´ı ˇsablonov´y soubor makelove.twig.SimpleViewControllerpo dokonˇcen´ı dan´e akce na z´akladˇe t´eto konvence zajist´ı automatick´e pˇred´an´ı modelu, pˇripraven´eho v r´amci akce, spr´avn´e ˇsablonˇe pohledu. Tuto ˇsablonu lze nav´ıc definovat jako rozˇs´ıˇren´ı nˇekter´eho z pˇreddefinovan´ych rozvrˇzen´ı.

2.4.2 Generov´ an´ı odkaz˚ u

K vytv´aˇren´ı odkaz˚u na jin´e str´anky (akce) t´ehoˇz webu lze pouˇz´ıt LinkBuilder.

Obsahuje nˇekolik metod, kter´ym se jako argument pˇred´av´a asociativn´ı pole, ko- lekce nebo ˇretˇezec ve form´atu JSON ˇci CSV. T´ımto argumentem je moˇzn´e nadefi- novat veˇsker´e argumenty odkazu, kter´y se sestav´ı automaticky a zahrne pˇr´ıpadnˇe relativn´ı cestu. Nen´ı tedy nutn´e zakotvit odkazy pˇr´ımo do k´odu, ˇc´ımˇz se pˇredejde komplikac´ım v pˇr´ıpadˇe restrukturalizace aplikace. D´ale je v r´amci LinkBuilderu nab´ıdnuta metoda navigate, slouˇz´ıc´ı t´eˇz pro vygenerov´an´ı odkazu. T´e staˇc´ı pˇredat pouze dva jednoslovn´e argumenty – n´azev controlleru a n´azev akce. Pro vytv´aˇren´ı

odkaz˚u na zdroje, jak´ymi jsou napˇr. obr´azky, je moˇzn´e pouˇz´ıt metodu linkToRe- source. V pˇr´ıpadˇe SimpleViewControlleru se LinkBuilder vkl´ad´a automaticky do modelu pod kl´ıˇcem lb, t´ım se st´av´a dostupn´y i v r´amci ˇsablonovac´ıho jazyka Twig.

2.4.3 Instantn´ı formul´ aˇ re

KomponentaAnnotationDriverFormBuilder pˇredstavuje moˇznost generov´an´ı for- mul´aˇr˚u pouh´ym doplnˇen´ım anotac´ı nad tˇr´ıdy datov´eho modelu. Pomoc´ı jedno- duch´ych kl´ıˇcov´ych slov lze nastavit, kter´y atribut dan´e tˇr´ıdy bude reprezentov´an jako textov´e pole, rolovac´ı nab´ıdka ˇci zatrˇz´ıtko apod. Podporov´any jsou i podsku- piny (fieldsety), do kter´ych lze napˇr´ıklad generovat formul´aˇre referencovan´ych tˇr´ıd a rozˇs´ıˇren´ı pomoc´ı dˇediˇcnosti. Lze tedy generovat formul´aˇre pro rozs´ahl´e struktury a vyhnout se ruˇcn´ımu mapov´an´ı hodnot. T´ımto zp˚usobem je zajiˇstˇen pokroˇcil´y da- tabinding, zn´am´y napˇr´ıklad z platformy ASP.NET.

2.4.4 XML import a export

Pro snadnou manipulaci s XML soubory byla v r´amci frameworku vytvoˇrena vlastn´ı knihovna XmlSerializer, kter´a stejnˇe jako AnnotationDriverFormBuilder, zm´ınˇen´y v pˇredchoz´ı sekci, vyuˇz´ıv´a anotace k zajiˇstˇen´ı mapov´an´ı objektu na XML ˇretˇezec a zpˇet. Pˇredlohou XmlSerializeru se stala knihovna LexaXmlSerializer, jej´ıˇz v´yvoj byl vˇsak ukonˇcen.

2.4.5 Spr´ ava uˇ zivatel˚ u a opr´ avnˇ en´ı

Pro spr´avu uˇzivatel˚u a definici pˇr´ıstupov´ych pr´av k jednotliv´ym controller˚um a akc´ım lze pouˇz´ıt komponentu Security. V r´amci t´eto komponenty lze volit r˚uzn´e poskytovatele pro autentizaci a autorizaci, pro zdroj uˇzivatel˚u a skupin a zdroj pˇriˇrazen´ych opr´avnˇen´ı.

3 Realizovan´ e komponenty

Tato kapitola je vˇenov´ana popisu vˇsech komponent realizovan´ych a zaˇclenˇen´ych do frameworku Phem v r´amci t´eto diplomov´e pr´ace. Pozornost je vˇenov´ana jejich obecn´emu ´uˇcelu, souˇcinnosti s ostatn´ımi komponentami a tak´e implementaˇcn´ım detail˚um. Obr´azek 1 zn´azorˇnuje z´akladn´ı strukturu frameworku a jeho hlavn´ıch souˇc´ast´ı. Tmavˇe oranˇzovou barvou jsou zv´yraznˇeny komponenty, kter´e byly do- plnˇeny. Svˇetle oranˇzovou jsou pak zn´azornˇeny dalˇs´ı z´avisl´e souˇc´asti doplnˇen´e souˇcasnˇe s nov´ymi komponentami.

Obr´azek 1: Diagram zp˚usobu zaˇclenˇen´ı nov´ych komponent do frameworku Phem

3.1 Komponenta Dispatcher

Prvn´ım nutn´ym krokem pˇred realizac´ı komponent, kl´ıˇcov´ych v r´amci t´eto pr´ace, bylo sjednocen´ı inicializace frameworku, pˇrihlaˇsov´an´ı, ovˇeˇrov´an´ı totoˇznosti uˇzivatele, opr´avnˇen´ı a smˇerov´an´ı poˇzadavk˚u do metod pˇr´ısluˇsn´ych controller˚u. Toto vˇse bylo doposud ˇreˇseno pomˇernˇe chaotick´ym zp˚usobem, pˇr´ımo v indexov´em souboru apli- kace, nav´ıc se k´od s postupn´ym v´yvojem v r˚uzn´ych pˇr´ıpadech nasazen´ı diverzifikoval a stal se vz´ajemnˇe nekompatibiln´ım. Tato komponenta by mˇela zahrnout podporu pro vˇsechna doposud zn´am´a ˇreˇsen´ı a navr´atit kompatibilitu a moˇznost snadn´ych aktualizac´ı. D´ale pˇrid´av´a nˇekolik nov´ych funkc´ı (napˇr´ıklad univerz´aln´ı pˇrihlaˇsovac´ı dialog) a tak´e nˇekolik konfiguraˇcn´ıch konstant, pomoc´ı kter´ych lze snadno definovat chov´an´ı aplikace v pˇr´ıpadˇe selh´an´ı autentizace ˇci autorizace dan´eho poˇzadavku.

3.1.1 Princip ˇ cinnosti

Na obr´azku 2 je v´yvojov´y diagram, kter´y zn´azorˇnuje z´akladn´ı funkcionalitu kom- ponenty Dispatcher. Pokaˇzd´e, pˇri naˇcten´ı kter´ekoliv str´anky aplikace se ihned po inicializaci frameworku aktivuje metoda dispatchRequest tˇr´ıdy Dispatcher. V t´eto metodˇe se nejprve zpracuj´ı parametry HTTP poˇzadavku a extrahuje se argument, kter´y urˇc´ı, do jak´eho controlleru m´a b´yt poˇzadavek d´ale smˇerov´an. Na z´akladˇe to- hoto argumentu je controller vyhled´an ve sloˇzk´ach s controllery v aplikaci i ve fra- meworku. Pokud existuje alespoˇn v jednom z tˇechto um´ıstˇen´ı, jsou naˇctena dalˇs´ı me- tadata a pokraˇcuje se ovˇeˇren´ım autorizace. Pokud controller nebyl nalezen v ˇz´adn´em z tˇechto um´ıstˇen´ı, na z´akladˇe pouˇzije se v´ychoz´ı, kter´y lze nastavit pomoc´ı kon- figuraˇcn´ı konstanty DEFAULT CONTROLLER. V opaˇcn´em pˇr´ıpadˇe, pokud cont- roller existuje souˇcasnˇe i ve frameworku i v aplikaci, znamen´a to, ˇze v´yvoj´aˇr aplikace pravdˇepodobnˇe pouˇzil pro n´azev sv´eho controlleru nˇekter´y z rezervovan´ych n´azv˚u a je tud´ıˇz vygenerov´ana v´yjimka.

Obr´azek 2: V´yvojov´y diagram funkce dispatchRequest

V dalˇs´ı f´azi se nejprve ovˇeˇr´ı, zda je nutn´e dan´y HTTP poˇzadavek autorizo- vat. Moˇznosti, kdy lze autorizaci pominout jsou dvˇe. Prvn´ı nast´av´a v pˇr´ıpadˇe, kdy je prostˇrednictv´ım konfiguraˇcn´ı konstanty LOGIN REQUIRED zcela deak- tivov´an pˇrihlaˇsovac´ı a ovˇeˇrovac´ı mechanizmus. Dalˇs´ı moˇznost´ı je v´yjimka pro DispatcherController, kter´y je pˇr´ıstupn´y vˇzdy. V tˇechto pˇr´ıpadech je poˇzadovan´a

´

uloha automaticky vykon´ana, bez nutnosti dalˇs´ıho ovˇeˇrov´an´ı. Samotn´a autori- zace je pˇrenech´ana komponentˇe Security, kter´a prostˇrednictv´ım metody canTask nad nˇekterou z implementac´ı rozhran´ıIAuthorizationProvider urˇc´ı, zda je dan´y uˇzivatel opr´avnˇen prov´adˇet poˇzadovanou ´ulohu z poˇzadovan´eho controlleru. Pokud je opr´avnˇen´ı udˇeleno, ´uloha je vykon´ana. Pokud je odepˇreno, dojde k pˇresmˇerov´an´ı na str´anku informuj´ıc´ı o odepˇren´em pˇr´ıstupu. V pˇr´ıpadˇe, ˇze opr´avnˇen´ı nelze ovˇeˇrit, je rozhodnuto na z´akladˇe v´ychoz´ı pˇrihlaˇsovac´ı politiky, jak bude s poˇzadavkem naloˇzeno d´ale. Tuto politiku lze nastavit konfiguraˇcn´ı konstantou LOGIN POLICY, pˇriˇcemˇz jsou k dispozici tˇri r˚uzn´e volby: povolen´ı pˇr´ıstupu, odepˇren´ı pˇr´ıstupu a pˇresmˇerov´an´ı na pˇrihlaˇsovac´ı str´anku.

3.1.2 Pˇ rihlaˇ sov´ an´ı uˇ zivatel˚ u

Pˇrihlaˇsov´an´ı je doporuˇceno ˇreˇsit prostˇrednictv´ım DispatcherControlleru, kter´y nab´ız´ı veˇsker´e potˇrebn´e metody, pro pˇrihl´aˇsen´ı, odhl´aˇsen´ı, pˇresmˇerov´an´ı a za- chycen´ı pˇr´ıpadn´ych chyb. Vyuˇz´ıv´a jednoduch´y pˇrihlaˇsovac´ı dialog, vykreslovan´y prostˇrednictv´ım Twig ˇsablony, kter´y je moˇzn´e pˇrizp˚usobit pomoc´ı kask´adov´ych styl˚u, definovan´ych v r´amci aplikace. Moˇzn´e je vˇsak pouˇz´ıt i vlastn´ı ˇreˇsen´ı, v´ybˇerem jin´eho controlleru pro spr´avu pˇrihlaˇsov´an´ı, pomoc´ı konfiguraˇcn´ıch konstant DISPATCHER CONTROLLER NAME a DISPATCHER LOGIN TASK NAME.

3.2 Komponenta ResourceLoading

Jednou ze slabˇs´ıch str´anek frameworku doposud z˚ust´avala spr´ava zdroj˚u pro kli-

snaha tyto soubory tˇr´ıdit podle typu do jednotliv´ych sloˇzek, existuje cel´a ˇrada kniho- ven tˇret´ıch stran, kter´e obsahuj´ı r˚uzn´e typy zdroj˚u. Jejich zaˇclenˇen´ı a roztˇr´ıdˇen´ı do spr´avn´ych sloˇzek (a s t´ım leckdy souvisej´ıc´ı nutn´a modifikace) je vysoce kontra- produktivn´ı. ˇCasto tedy bylo v´yhodnˇejˇs´ı ˇreˇsit zaˇclenˇen´ı tˇechto knihoven na stranˇe aplikace, nikoliv v r´amci frameworku. Nyn´ı lze vˇsak snadno tyto z´avislosti spravovat pomoc´ı nov´eho mechanizmu v r´amci komponenty ResourceLoading.

3.2.1 Prohled´ avan´ a um´ıstˇ en´ı a typy zdroj˚ u

Soubory zdroj˚u se mohou nach´azet ve tˇrech r˚uzn´ych um´ıstˇen´ıch, podle jejich p˚uvodu, rozsahu pouˇzitelnosti a ´uˇcelu. Tabulka 2 pˇribliˇzuje jejich v´yznam.

Tabulka 2: Pˇrehled um´ıstˇen´ı soubr˚u se zdroji pro klientskou stranu

Um´ıstˇen´ı Popis obsahu

Application/Resources/ zpr´avy jsou pˇren´aˇseny prostˇrednictv´ım per- manentn´ıho websocketov´eho spojen´ı

Framework/Resources/ pro pˇrenos zpr´av je pouˇzita metoda comet (vyˇck´avaj´ıc´ı Ajaxov´y dotaz)

Framework/Resources/3rdParty kombinace obou v´yˇse uveden´ych metod

V prvn´ıch dvou pˇr´ıpadech existuje vˇzdy pro kaˇzd´y typ zdroje samostatn´a sloˇzka, kter´a je pˇri naˇc´ıt´an´ı proch´azena rekurzivnˇe a tedy pro odpov´ıdaj´ıc´ı typ zdroje jsou soubory naˇcteny z dan´e sloˇzky i ze vˇsech podsloˇzek. Do sloˇzky Resources pod sloˇzkou aplikace jsou um´ıst’ov´any zdroje vytvoˇren´e v r´amci dan´e aplikace. Ve sloˇzce Resources pod sloˇzkou frameworku jsou pak univerz´aln´ı zdroje, kter´ymi disponuje framework s´am o sobˇe. Zdroje javascript˚u a kask´adov´ych styl˚u jsou spravov´any ResourceManagerem, o kter´em pojedn´av´a samostatn´a sekce 3.2.3.

Obr´azky, zvuky a ostatn´ı zdroje z tˇechto dvou um´ıstˇen´ı lze snadno vkl´adat do k´odu str´anek prostˇrednictv´ım tˇr´ıdy LinkBuilder, konkr´etnˇe jeho metody linkTo- Resource. Referenci na LinkBuilder lze z´ıskat z metody getLinkBuilder ve tˇr´ıdˇe EnvironmentManager.

Zat´ımco naˇc´ıt´an´ı zdroj˚u z prvn´ıch dvou lokac´ı je pomˇernˇe pˇr´ımoˇcar´e, v pˇr´ıpadˇe po- sledn´ıho zm´ınˇen´eho um´ıstˇen´ı je situace znaˇcnˇe komplikovanˇejˇs´ı. Zaˇclenˇen´ı a naˇc´ıt´an´ı knihoven a zdroj˚u tˇret´ıch stran je vˇenov´ana samostatn´a sekce 3.2.2.

3.2.2 Knihovny a zdroje tˇ ret´ıch stran

Ve sloˇzce se zdroji pˇribyla podsloˇzka pro knihovny tˇret´ıch stran, kam je nyn´ı moˇzn´e knihovny vkl´adat tak jak jsou, bez nutnosti jak´ekoliv ´upravy. Jedin´ym nutn´ym krokem pˇri zaˇcleˇnov´an´ı je vytvoˇren´ı nov´e implementace abstraktn´ı tˇr´ıdy ThirdPartyResourceLoader, ve kter´e se v r´amci metody load definuje, kter´e zdroje se maj´ı jak´ym zp˚usobem zav´adˇet. Tato tˇr´ıda mus´ı b´yt pojmenov´ana stejnˇe, jako nadˇrazen´a sloˇzka (obvykle n´azev knihovny) a za n´azvem mus´ı b´yt jeˇstˇe extenze

"Loader". Obr´azek 3 ukazuje pˇr´ıklad struktury zaˇclenˇen´e knihovny Twitter Boot- strap.

Obr´azek 3: Struktura zaˇclenˇen´e knihovny Twitter Bootstrap

Zdrojov´y k´od 1 zn´azorˇnuje, jak´ym zp˚usobem lze definovat zav´adˇen´e zdroje z t´eto knihovny uvnitˇr zavadˇeˇceBoostrapLoader. Kl´ıˇcovou ´ulohu zde sehr´av´a metoda add- Resource, zdˇedˇen´a od rodiˇcovsk´e tˇr´ıdy, kter´a registruje zdroje do kolekc´ı, kter´e jsou pak kdykoliv dostupn´e pˇres ResourceManager, jenˇz je podrobnˇeji pops´an v sekci 3.2.3. Metodˇe addResource staˇc´ı pˇredat pouze zvolen´y n´azev pro dan´y zdroj, cestu k souboru ˇci sloˇzce, typ (kategorii) zdroje a volitelnˇe lze tak´e uv´est pˇr´ıznak, jestli m´a b´yt sloˇzka prohled´av´ana rekurzivnˇe, a nav´ıc tak´e prioritu.

1 c l a s s B o o t s t r a p L o a d e r e x t e n d s T h i r d P a r t y R e s o u r c e L o a d e r

2 {

3 p u b l i c f u n c t i o n l o a d()

4 {

5 $this- >a d d R e s o u r c e(" B o o t s t r a p m i n i m a l JS ",

6 " js / b o o t s t r a p . min . js ",R e s o u r c e T y p e::JS,

7 false , 8);

8 $this- >a d d R e s o u r c e(" B o o t s t r a p m i n i m a l CSS ",

9 " css / b o o t s t r a p . min . css ",R e s o u r c e T y p e::CSS,

10 false , 8);

11 }

12 }

Zdrojov´y k´od 1: Pˇr´ıklad implementace zavadˇeˇce knihovny zdroj˚u

3.2.3 ResourceManager

V bˇeˇzn´ych pˇr´ıpadech uˇzit´ı nen´ı nutn´e s ResourceManagerem nijak manipulovat. Po- kud vˇsak aplikace vyˇzaduje implementaci vlastn´ıho controlleru, kter´y nen´ı zaloˇzen na ˇz´adn´e ze tˇr´ıdSimpleViewController, ani naWorkspaceViewController(viz kapi- tola 3.4), lze jeho prostˇrednictv´ım z´ıskat kolekce vˇsech relativn´ıch cest k javascrip- tov´ym zdroj˚um nebo zdroj˚um s kask´adov´ymi styly. Pro tyto ´uˇcely slouˇz´ı funkce getResourcePathCollection, kter´a pˇreb´ır´a jako argument poˇzadovan´y typ zdroje. Po- kud je potˇreba zdroje nˇejak´ym zp˚usobem d´ale filtrovat nebo tˇr´ıdit, lze z´ıskat i kolekci vˇsech zdroj˚u se vˇsemi metadaty, vyuˇzit´ım metody getResources. Zdroje jsou v tomto pˇr´ıpadˇe reprezentov´any objektem tˇr´ıdy Resource. Instanci ResourceManageru lze z´ıskat z tov´arn´ı metody getResourceManager ve tˇr´ıdˇe EnvironmentManager.

3.2.4 Automatick´ a minifikace

V produkˇcn´ı reˇzimu kaˇzd´e aplikace je vhodn´e vyuˇz´ıt automatickou minifikaci zdroj˚u, kter´a zajist´ı, ˇze kaˇzd´y javascriptov´y soubor, nebo soubor s kask´adov´ymi styly je zredukov´an na co moˇzn´a nejmenˇs´ı velikost (odstranˇen´ım mezer, zalomen´ı ˇr´adk˚u, a zkr´acen´ım n´azv˚u promˇenn´ych) a z´aroveˇn jsou vˇsechny zdroje dan´eho typu zkombi-

nov´any do jedin´eho souboru. Tento mechanizmus tak redukuje mnoˇzstv´ı jednotliv´ych poˇzadavk˚u a objem pˇren´aˇsen´ych dat mezi webov´ym serverem a prohl´ıˇzeˇcem.

Vyuˇzita je zde knihovna Minify, kter´e jsou veˇsker´e soubory zdroj˚u pˇred´any ke zpracov´an´ı. Poskytov´an´ı minifikovan´ych zdroj˚u lze nastavit konfiguraˇcn´ı konstan- tou MINIFY RESOURCES. Ruˇcnˇe je moˇzn´e minifikovan´e zdroje dan´eho typu z´ıskat zResourceManageru metodou getMinifiedResourcesPath.

3.3 Komponenta MessageBus

Komponenta MessageBus zajiˇst’uje v´ymˇenu syst´emov´ych (aktualizaˇcn´ıch) zpr´av mezi aplikac´ı a pˇripojen´ymi uˇzivateli i mezi uˇzivateli samotn´ymi. Lze j´ı pouˇz´ıt i napˇr´ıklad pro jednoduchou realizaci rozhran´ı pro instantn´ı zpr´avy (chat). Pˇren´aˇsen´e zpr´avy jsou k´odov´any do form´atu JSON, kter´y je velmi jednoduch´y a napˇr´ıklad oproti XML vynik´a n´ızkou reˇzi´ı. Do frameworku byla zaˇclenˇena v r´amci jmenn´eho prostoru Phem\Libraries\MessageBuss. Z´aroveˇn byly rozˇs´ıˇreny ˇc´asti jmenn´eho prostoru Phem\Environment, zejm´ena statick´a tˇr´ıda Application, kter´a nyn´ı dis- ponuje funkcemi pro zas´ıl´an´ı zpr´av. P´ateˇr t´eto komponenty tvoˇr´ı kromˇe tˇr´ıdy MessageBus, reprezentuj´ıc´ı samotnou sbˇernici zpr´av, tak´e dvˇe abstraktn´ı tˇr´ıdy Pusher a Puller. Zat´ımco Pusher zajiˇst’uje vkl´ad´an´ı zpr´av na sbˇernici, Puller slouˇz´ı pro jejich vyzved´av´an´ı a pˇred´av´an´ı adres´at˚um. K dispozici je nˇekolik z´akladn´ıch implementac´ı, kter´e vypl´yvaj´ı z podporovan´ych bˇehov´ych reˇzim˚u (viz.

sekce 3.3.1). Je vˇsak moˇzn´e v pˇr´ıpadˇe potˇreby pˇridat vlastn´ı implementaci.

3.3.1 Bˇ ehov´ e reˇ zimy

K dispozici je nˇekolik bˇehov´ych reˇzim˚u, kter´e se odv´ıjej´ı od pouˇzit´e metody pro notifikaci okna prohl´ıˇzeˇce ze strany serveru. Bˇehov´y reˇzim lze vybrat pomoc´ı kon- figuraˇcn´ı konstanty MESSAGEBUS MODE, kter´a byla pˇrid´ana do konfiguraˇcn´ıho souboru aplikace. Pˇrehled reˇzim˚u je zobrazen v tabulce 3.

Tabulka 3: Pˇr´ıpustn´e hodnoty pro MESSAGEBUS MODE

Hodnota Popis

WebSocket zpr´avy jsou pˇren´aˇseny prostˇrednictv´ım permanentn´ıho websocketov´eho spojen´ı

Comet pro pˇrenos zpr´av je pouˇzita metoda comet (vyˇck´avaj´ıc´ı Ajaxov´y dotaz)

Both kombinace obou v´yˇse uveden´ych metod Disabled pˇrenos notifikaˇcn´ıch zpr´av je zak´az´an

Reˇzim Websocket

Reˇzim WebSocket je nejefektivnˇejˇs´ı. Disponuje n´ızkou latenci pˇri doruˇcov´an´ı zpr´av a klade nejniˇzˇs´ı n´aroky na objem pˇrenesen´ych dat. V tomto reˇzimu je nutn´e spustit samostatn´y skript socket.run.php, kter´y websocketov´a spojen´ı obsluhuje. Tento skript je t´eˇz naps´an v PHP a vyuˇz´ıv´a souˇc´asti frameworku. Um´ıstˇen byl pˇr´ımo do koˇrenov´eho adres´aˇre. V unixov´em prostˇred´ı je vhodn´e, aby byl spuˇstˇen pomoc´ı obalov´eho shellov´eho skriptu socket.run.sh, kter´y zajist´ı pˇred´an´ı PHP skriptu k interpretaci PHP procesov´emu manaˇzeru nebo HHVM interpreteru, ˇc´ımˇz se zajist´ı pˇr´ıstup ke stejn´e sd´ılen´e pamˇeti a aplikaˇcn´ım promˇenn´ym, jako pˇr´ımo z webov´eho serveru (podrobnˇeji o t´eto problematice viz. kapitola 6). Tak´e je vhodn´e vyuˇz´ıt Supervisor, coˇz je d´emon, kter´y dohl´ıdne na to, aby skript z˚ustal bˇeˇzet, pˇr´ıpadnˇe se pˇri selh´an´ı opˇetovnˇe spustil.

Z´aklad skriptu tvoˇr´ı smyˇcka ud´alost´ı z knihovny React, se kterou je sv´az´an na- slouchaj´ıc´ı websocketov´y server Ratchet a obvykle tak´e puller naslouchaj´ıc´ı pro pro pˇr´ıjem zpr´av ze strany webov´eho serveru. Na z´akladˇe ud´alost´ı jsou vol´any pˇr´ısluˇsn´e metody nad instanc´ı tˇr´ıdy MessageBus, kter´a sbˇernici zpr´av reprezen- tuje. Prostˇrednictv´ım konfiguraˇcn´ı konstanty WEBSOCKET PULLER MODE lze vybrat konkr´etn´ı implementaci zp˚usobu pˇred´av´an´ı zpr´av socketov´emu serveru ze serveru webov´eho. Pˇrehled dostupn´ych implementac´ı je zobrazen v tabulce 4.

Tabulka 4: Pˇr´ıpustn´e hodnoty pro WEBSOCKET PULLER MODE

Hodnota Popis

ReactSocket jednoduch´a implementace fronty zpr´av pomoc´ı socke- tov´eho serveru z knihovny React

ZMQ vyuˇzit´ı knihovny ZeroMQ

Disabled pˇred´av´an´ı zpr´av websocketov´emu serveru je zak´az´ano

Vyuˇzit´ı ZeroMQ je univerz´alnˇejˇs´ı ˇreˇsen´ı, umoˇzˇnuj´ıc´ı snadn´e zaˇclenˇen´ı do kom- plexnˇejˇs´ıho distribuovan´eho syst´emu. Nev´yhoda t´eto volby spoˇc´ıv´a v nutnosti in- stalovat na bˇehov´y server knihovnu libzmq a podporu t´eto knihovny pro jazyk PHP (php zmq modul). Podpora ZMQ pro HHVM nav´ıc st´ale chyb´ı, pˇrestoˇze se v pr˚ubˇehu dubna objevila na serveru github portovan´a verze php zmq pro HHVM, jej´ı pouˇzitelnost je st´ale sp´ıˇse v mez´ıch experiment´aln´ıch ´uˇcel˚u. Pˇred´av´an´ı zpr´av pomoc´ı ReactSocket implementace funguje spolehlivˇe i s HHVM.

Pro konfiguraci rozhran´ı a port˚u, na kter´ych m´a websocketov´y server i puller na- slouchat, lze pouˇz´ıt tyto konfiguraˇcn´ı konstanty:

• WEBSOCKET BIND ADDR

• WEBSOCKET PORT

• WEBSOCKET PULER BIND ADDR

• WEBSOCKET PULER PORT

Podrobnˇejˇs´ım informac´ım a doporuˇcen´ım ohlednˇe konfigurace bˇehov´e platformy se vˇenuje kapitola 6.

Reˇzim Comet

Pokud bˇehov´a platforma neumoˇzˇnuje nasazen´ı technologie WebSocket, nebo je

serveru, obzvl´aˇstˇe v pˇr´ıpadˇe pouˇzit´ı komponenty UI, nebo jin´ych aplikaˇcn´ıch souˇc´ast´ı, n´aroˇcn´ych na objem asynchronnˇe pˇren´aˇsen´ych dat. Webov´y server by mˇel v tomto pˇr´ıpadˇe nab´ızet dostatek voln´ych vl´aken ˇci proces˚u pro obsluhu pˇr´ıchoz´ıch poˇzadavk˚u. Nev´yhodou toho ˇreˇsen´ı je latence pˇri detekci ukonˇcen´ı spo- jen´ı a pˇredevˇs´ım z´avislost na modulu php pcntl, kter´y je dostupn´y pouze na uni- xov´ych syst´emech. Na rozd´ıl od reˇzimu WebSocket, kde je vyuˇzita fronta zpr´av a naslouchaj´ıc´ı puller, zde jsou zpr´avy pˇri odesl´an´ı (v r´amci CometPusheru) ukl´ad´any mezi aplikaˇcn´ı promˇenn´e, kde vyˇck´avaj´ı na vyzvednut´ı. Jednotliv´a spojen´ı jsou re- alizov´ana pomoc´ı ajaxov´eho poˇzadavku, jehoˇz obsluhuj´ıc´ı PHP skript vloˇz´ı mezi aplikaˇcn´ı promˇenn´e identifik´ator dan´eho spojen´ı sp´arovan´y s identifik´atorem pro- cesu ˇci vl´akna, pod kter´ym bˇeˇz´ı a d´ale na serveru vyˇck´av´a (v r´amci CometPulleru) na sign´al SIGUSR1. Tento sign´al je procesu zasl´an bezprostˇrednˇe po vloˇzen´ı zpr´avy mezi aplikaˇcn´ı promˇenn´e, prostˇrednictv´ım funkce pcntl sigtimedwait. Po vyzvednut´ı vˇsemi adres´aty je zpr´ava z aplikaˇcn´ıch promˇenn´ych odstranˇena. Pokud k vyzvednut´ı vˇsemi adres´aty nedojde, je zpr´ava odstranˇena po uplynut´ı lh˚uty, stanoven´a konfi- guraˇcn´ı konstantou COMET MESSAGE TIMEOUT. Toto ˇreˇsen´ı je tedy z´aroveˇn n´aroˇcnˇejˇs´ı na alokovanou pamˇet’ a nen´ı pˇr´ıliˇs vhodn´e pro souˇcasn´y pˇr´ıstup velk´eho mnoˇzstv´ı uˇzivatel˚u.

Reˇzim Both

V nˇekter´ych pˇr´ıpadech m˚uˇze b´yt v´yhodn´e pouˇzit´ı bˇehov´eho reˇzimu Both, kter´y lze oznaˇcit za reˇzim kompatibility. Nab´ız´ı Webosocketov´e spojen´ı pouze prohl´ıˇzeˇc˚um, kter´e je podporuj´ı. Ostatn´ı prohl´ıˇzeˇce mohou z´ısk´avat notifikace prostˇrednictv´ım Co- met principu. MessageBus s´am zajist´ı interoperabilitu mezi tˇemito dvˇema pˇr´ıstupy.

Reˇzim Both je dostupn´y pouze na unixov´ych platform´ach, stejnˇe jako reˇzim Comet.

3.3.2 Adresace

MessageBus nab´ız´ı sedm metod pro r˚uzn´e typy adresace pˇr´ıjemc˚u zpr´avy. Tyto metody byly doplnˇeny do statick´e tˇr´ıdy Application. V tabulce 5 je uveden seznam metod se struˇcn´ym popisem.

Tabulka 5: Varianty metody notify pro r˚uzn´e typy adresace N´azev metody C´ıl zpr´avy

notifyAll vˇsechna aktivn´ı spojen´ı

notifyUsers vˇsechna aktivn´ı spojen´ı vˇsech uveden´ych uˇzivatel˚u notifyUser vˇsechna aktivn´ı spojen´ı konkr´etn´ıho uˇzivatele notifySessions vˇsechna aktivn´ı spojen´ı vˇsech uveden´ych sezen´ı notifySession vˇsechna aktivn´ı spojen´ı konkr´etn´ıho sezen´ı notifyConnections vˇsechna vybran´a aktivn´ı spojen´ı

notifyConnection konkr´etn´ı aktivn´ı spojen´ı

Pro pouˇzit´ı metod notifyUser, notifyUsers, notifySession a notifySessions je nutn´e m´ıt zapnutu podporu pro ukl´ad´an´ı aplikaˇcn´ıch promˇenn´ych. V opaˇcn´em pˇr´ıpadˇe tyto metody generuj´ı v´yjimku. Pokud jsou aplikaˇcn´ı promˇenn´e povoleny, pod kl´ıˇcem ve tvaru Phem.[jmenn´y prostor aplikace].Users se vytv´aˇr´ı strom aktivn´ıch uˇzivatel˚u, sezen´ı a spojen´ı, na z´akladˇe kter´eho je moˇzn´e takto specifickou adresaci realizovat.

Obr´azek 4 je pˇr´ıkladem grafick´e reprezentace takto vytvoˇren´eho stromu.

Obr´azek 4: Pˇr´ılad v´ypisu aktivn´ıch uˇzivatel˚u, sezen´ı a spojen´ı

3.3.3 Vytvoˇ ren´ı a odesl´ an´ı zpr´ avy

Zpr´avu je moˇzn´e vytvoˇrit ruˇcn´ım sestaven´ım JSON ˇretˇezce (napˇr. pomoc´ı Twig ˇsablony), vhodnˇejˇs´ım zp˚usobem je vˇsak pouˇzit´ı univerz´aln´ıho objektu zpr´avy. Tento