Play framework

Playje framework sloužící k tvorbě webových aplikací běžících nadJVMa postavených na architektuřeMVC. Je založen na principechRESTa důraz klade na bezstavovost jednotlivých aplikací. Jako jazyk umožňuje programátorům zvolitJavuneboScalu, o kterou programátor i při vývoji v Javě často zavadí, jelikož je na pozadí celého frameworku a je mimo jiné použita i jako šablonovací jazyk.
Protože Scala je zpětně kompatibilní s Javou, lze jednotlivé Java objekty používat i ve Scale. Teoreticky je tak možné celou modelovou část aplikace napsat v Javě a na řadiče a pohledy použít Scalu.
Jedná se o kompletní framework, který přichází s vestavěnou databázíH2, vlastním ORM nástrojemEbeana vlastním serverem Netty, na kterém lze aplikace během vývoje spouštět. Díky svému charakteru je často srovnáván s podobně zaměřenými frameworky, jako jsouNette Framework,Django,SymfonyneboRuby on Rails, a díky svým vlastnostem se hodí pro vývoj menších a středně velkých aplikací. V Play je spojen charakter vývoje typický pro podobné frameworky - rychlost, jednoduchost a lehkost a svět Javy, který je dnes vedle .NET frameworku standardem pro enterprise aplikace.
V praxi je framework používán kromě jiných firmami Linkedin nebo britským listem The Guardian.
Jedná se o open source nástroj, jehož vývoj zastřešuje společnost Typesafe. K dispozici je kromě dokumentace pro Javu i Scalu také množství ukázkových aplikací. Co se týče dalších zdrojů informací, je možné sáhnout po zahraniční literatuře. Příkladem publikací jsou Play for Java, Play for Scalaa další.
Základním předpokladem pro používání frameworku je správně nainstalovaná Java. Jeho zprovoznění je pak otázkou několika minut. Celý framework má zhruba 1,17MB. Po jeho stažení je třeba celý archiv rozbalit na libovolné místo na disku. K tomuto adresáři je třeba nastavit práva pro čtení a zápis, protože během spuštění si zde framework ukládá pomocné soubory. Posledním krokem instalace je úprava systémové proměnnéPATH. Potom, co je v systému nastavena cesta k adresáři s frameworkem, je zpřístupněn také příkazactivator.
Přestože Play nenutí programátory k používání konkrétníhoIDE, jeho volba je do jisté míry ovlivněna zvoleným jazykem. I tak je ale možné pracovat v prakticky jakémkoli textovém editoru. Co se týče třech nejpoužívanějších vývojových prostředí pro Javu, framework nalezne podporu vEclipse,NetbeansiIntelliJ Idea, a to již přímo nebo po instalaci dodatečných pluginů. Pro práci se Scalou je možné použít i nástroj Scala IDE, který je postavený nad Eclipse.
Pro generování základní struktury projektu je možné z konzole spustit příkazactivator newza kterým se uvede název vytvářené aplikace. Následně je možné zvolit jazyk, ve kterém bude aplikace vytvářena. Vybrat je možné mezi Javou a Scalou. V aktuální složce je poté vytvořen adresář se zadaným názvem a základní strukturou aplikace.
Základním konfiguračním souborem aplikace je souborapplication.conf.Jedná se o běžný textový soubor, používající formátHOCONa jeho úpravou je možné měnit nastavení databázového připojení, konfiguraci nástroje Ebean, logování, nebo vlastnosti lokalizace. Základní konfiguraci databáze a ORM nástroje lze provést odkomentováním několika řádků.
Za sestavení celé aplikace je odpovědný nástroj zvaný Scala Build Tool (sbt). Ten se stará o veškeré závislosti, jejich stažení, integraci a sestavení výsledné aplikace.
Jednou možností, jak framework používat je zpříkazového řádku, druhou je pak webové rozhraní. V dřívějších verzích frameworku byl pro práci s ním vyhrazen příkazplay. Ten je od verze 2.3.6 (v době psaní tohoto článku je nejnovější verze 2.3.9) nahrazen příkazemactivator. Kompletní seznam příkazů lze pak vypsat pomocíactivator help.
Modelová část aplikace se odvíjí od zvoleného jazyka, v případě Javy jsou jednotlivé objekty modelu klasické Java soubory. Za kontroverzní vlastnost frameworku lze na první pohled označit to, že umožňuje deklarovat jednotlivé atributy tříd jako veřejně přístupné a dochází tak k porušení zapouzdření, jedné ze základních objektových vlastností.
Ve skutečnosti se ale autoři Play frameworku snažili programátorům maximálně ulehčit práci. V tomto případě zpřehlednit kód a zmenšit množství psaného / generovaného kódu. Přestože to tak nevypadá, při překladu jsou ke každému veřejnému atributu vygenerovány přístupové metody a práce s atributy je pak prováděna přes tyto metody. Některé frameworkzy (napříkladHibernate) přístupové metody vyžadují. Nic tak nebrání tomu, aby se od počátku v kódu tyto metody vyskytovaly a jednotlivé atributy byly označeny jako neveřejné (příp. soukromé).
Uvnitř modelových objektů je možné použítJPAanotace. ORM nástroj Ebean, který je součástí frameworku registruje mapované objekty s pomocí anotace@Entity. Aby mohly jednotlivé objekty využívat vlastností nástroje Ebean, měly by dědit ze třídyplay.db.ebean.Model.
Controllery (Model-view-controller) jsou ve webových aplikacích postavených na architektuře MVC místem, kde jsou zpracovány jednotlivé HTTP požadavky. Jsou tak vstupním a výstupním místem aplikace a propojením dalších dvou vrstev - modelu a jednotlivých pohledů.
Ve frameworku Play jsou to pak objekty dědící od třídyplay.mvc.Controller. Každý takový objekt řadiče obsahuje několik statických metod, jejichž úkolem je zpracovat příchozí HTTP požadavek a vrátit instanci třídyplay.mvc.Result. Mapování jednotlivých HTTP požadavků je prováděno uvnitř souboruconf/routes. Uvnitř každé definice je HTTP požadavek na konkrétní adresu přiřazen ke konkrétní metodě konkrétního řadiče.
Jednotlivé definice mohou kromě statických částí obsahovat i další parametry. Protože je Scala silně typový jazyk, je nutné u každého parametru uvést i jehodatový typ.
Proces směrování jednotlivých požadavků je možné provádět i opačným směrem. Jedná se o situaci, kdy nejprve dojde k zavolání metody řadiče, která místoplay.mvc.Resultvrátí objektplay.mvc.Call, čímž daný HTTP požadavek vyvolá. Po překladu je ze souboruconf/routesvygenerován objektRoutes, který tyto obrácené definice obsahuje.
Protokol HTTP je ze své podstaty bezstavový, takže data, která jsou uvnitř jednoho požadavku předávána, jsou po zpracování požadavku ztracena. Pro ukládání stavů aplikace mezi jednotlivými požadavky tak slouží souboryHTTP cookie. Soubory cookies jsou obyčejné textové soubory - obsahují text a jejich velikost je omezena na 4Kb, které HTTP server ukládá na straně klienta. Tyto soubory mohou obsahovat různé textové informace, na které se lze v případě potřeby odvolávat mezi jednotlivými HTTP požadavky. U jednotlivých cookies lze také nastavit dobu, po kterou je má server na straně klienta držet.
Doba platnosti se liší podle potřeby. Nejkratším úsekem, který lze v Play definovat jeRequest. Data s touto platností jsou k dispozici přesně po dobu existence jednoho HTTP požadavku. Další možností jeFlash, která data udržuje při životě přesně po dobu dvou HTTP požadavků. To je například doba nutná k zaslání informačních výpisů při odesílání formulářů nebo přesměrování mezi dvěma stránkami. Doba platnostiSessionudržuje data do chvíle, než uživatel ukončí prohlížeč a jedná se o nejdelší časový úsek, který lze v Play aplikaci definovat. Poslední možností je pak doba platnostiResponse, kterou lze použít například pro úpravu podoby odpovědi HTTP protokolu.
Pohledy (Views) jsou vrstvou MVC architektury, která má za úkol prezentovat data uživateli v čitelné a srozumitelné formě. Ve webových aplikacích jsou to často soubory s koncovkou.html, které lze ale díky použití dalších jazyků dynamicky generovat. V prvních verzích Play frameworku byl tímto šablonovacím jazykem Groovy, který byl později nahrazen Scalou.
Každá šablona může, kromě instrukcí značkovacího jazyka definujícího statickou strukturu stránky, obsahovat ještě sadu dalších jazykových konstrukcí pro generování dynamického obsahu. Jedná se o podmínky, cykly nebo části jiných šablon. Každá takto definovaná dynamická část je ve výsledku přegenerována na statický výstup. Nevýhodou takového přístupu je, že se tento proces generování provádí při každém požadavku o tuto stránku. Play tento nedostatek řeší tím, že každou stránku generuje pouze jednou již při překladu, čímž zobrazení jednotlivých stránek urychluje. Během překladu dochází také ke kontrole správnosti jednotlivých typů dat a případnou chybu lze tak odhalit již během překladu.
Šablony ve frameworku Play jsou soubory s koncovkou.scala.htmla jsou umístěné v adresářiapp/views. Každou šablonu je třeba chápat jako funkci a její použití lze provést zavoláním dané funkce.
Práce s formulářem obvykle vyžaduje dva základní kroky. Prvním je formulář uživateli zobrazit, druhým potom zajistit jeho odeslání zpět do aplikace, včetně ověření jeho obsahu. Formuláře jsou ve frameworku Play objekty typuplay.data.Form. Základem pro každý formulář je vždy některá třída z modelu, jehož data se mají s pomocí formuláře získat. K vytvoření formulářového objektu stačí v odpovídajícím řadiči implementovat metodu, která objekt formuláře pošle společně s dalšími požadovanými daty do dané šablony.
Po zavolání metody render je dané šabloně předán objekt formuláře. Každou šablonu lze chápat jako objekt (funkci) - lze jí předávat parametry a volat její metody.
Výše uvedený výpis je příkladem jednoduchého přihlašovacího formuláře. Znakem, který odděluje dynamické výpisy od statických je@. Příkaz@helper._importuje vše z balíku helper. Po tomto příkazu následuje seznam parametrů, které daná funkce přijímá. Jedná se o objekt formuláře a nadpis stránky, který je použit v šabloněmain. Do ní je vložen také objekt formuláře.
Hlavička formuláře obsahuje metodu, která se má zavolat po jeho odeslání. Po překladu odpovídá HTML kódu<form action="/login" method="POST" id="loginForm">Adresa URL, na kterou se mají data z formuláře posílat je určena podle směrovacího souboru, který by v následujícím případě měl mít následující podobu.
Pro vytvoření formuláře je možné použít jednak klasické HTML elementy, jako je tomu v předchozím příkladu nebo využít formulářové konstruktory, které jsou součástí Play. Stejného výsledku jako v předchozím příkladu lze dosáhnout i touto cestou.
Posledním krokem práce s formulářovými daty je jejich validace. Správnost dat lze ověřit buď na straně klienta nebo na straně serveru. Obecně platí, že by se tyto dva způsoby měly kombinovat. Ověření na straně serveru lze v Play provést například následujícím způsobem v metodě controlleru.
První řádek metody vytvoří odkaz na objekt formuláře získaného z příchozího HTTP požadavku. K tomu slouží metodabindFromRequest(). Následuje první ověření. Na každý objekt typuplay.data.Formje možné zavolat metoduhasErrors(), která vrací hodnotutruev případě, že daný formulář obsahuje chyby. Může se například jednat o situaci, kdy uživatel nevyplnil povinné pole formuláře.
V případě, že jsou data formuláře neúplná, lze na toto uživatele upozornit s použitím souborůcookies. Metodaflash("error","Vyplňte prosím, všechna pole formuláře.");stanovuje dobu platnosti chybové hlášky na dva HTTP požadavky. Poté je uživatel přesměrován zpět na stránku s formulářem.
MetodavalidCustomer(), která je ve výpisu použita, má za úkol v databázi zákazníků najít toho, jehož přihlašovací údaje jsou shodná jako ty zadané do formuláře. Pokud takový není nalezen, dojde opět k přesměrování zpět na stránku s přihlašovacím formulářem. V opačném případě je vytvořen soubor cookies s přihlašovacími údaji zákazníka. Jeho doba platnosti je nastavena do chvíle, než je aplikace (prohlížeč) ukončena, nebo nedojde k odhlášení.