}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Podpora pro rámec Stripes v prostředí NetBeans IDE DIPLOMOVÁ PRÁCE Josef Šustáček Brno, jaro 2009

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Ing. Petr Adámek ii

3 Poděkování Děkuji vedoucímu této práce, Petrovi Adámkovi, za cenné rady, postřehy, nabídnutá řešení a nevyčerpatelný zdroj nejlepšího vína z Moravy. Dále Gabriele Galiové, za tolerantní přístup při časté noční tvorbě této práce a v neposlední řadě za jazykovou korekturu. iii

4 Shrnutí Tato diplomová práce se zabývá implementací webového rámce Stripes do prostředí Net- Beans IDE a klade si za cíl zjednodušit tvorbu webových aplikací postavených na platformě Java. NetBeans IDE je vývojové prostředí vycházející z platformy NetBeans, která je vysoce modulární a poskytuje tak podporu pro tvorbu nových zásuvných modulů. Celá platforma je šířena zdarma a včetně všech zdrojových kódů za podpory společnosti Sun. Webový rámec Stripes je nadstavba nad Java Servlet API, která usnadňuje tvorbu webových aplikací. Je založen na principu architektury MVC a zajišt uje nejběžnější operace potřebné při tvorbě téměř každé webové aplikace. Mezi ně patří zpracování formulářů, validace vstupních hodnot, zobrazování zpráv uživatelům, řízení toku stránek a další. Rámec také obsahuje dobře použitelný systém šablon pro JSP stránky. Propojením NetBeans IDE a Stripes vzniká silný nástroj, pomocí nějž lze v krátké době tvořit rozsáhlé, výkonné a přesto snadno udržovatelné aplikace založené na platformě Java. iv

5 Klíčová slova NetBeans IDE, Stripes, Java, J2EE, EE, NetBeans RCP, JSF, Struts, Spring, Servlet API v

6 Obsah 1 Úvod Vývoj webových aplikací v jazyce Java Běhové prostředí kontejnery Definice webové aplikace Prezentační webové aplikace Deployment deskriptor Java Servlet API Protokol HTTP Servlet Životní cyklus servletu Příklad servletu Filtr Java Server Pages Srovnání přípustných formátů JSP Standardní syntax JSP JSP akce JSP direktivy Dynamický obsah JSP stránek Knihovny značek Webové aplikační rámce Typicky poskytované služby Autentizace a autorizace Tvorba hezkých URL Nástroje pro tvorbu šablon Cache AJAX Přístup do databáze Architektura MVC Základní koncept Životní cyklus požadavku Výhody a přínosy Rámce založené na komponentách Java Server Faces Tapestry Wicket Rámce založené na akcích Struts Spring Web MVC Rámec Stripes Hlavní koncepty rámce Stripes vi

7 3.1.1 Action beans Fáze životního cyklu požadavku Určení action bean instance Volba vyvolané akce Vázání parametrů z požadavku Validace dat Obsluha požadavků Statické mapování požadavků Dynamické mapování pomocí DynamicMappingFilter Knihovna značek Stripes Značky pro tvorbu formulářů Ostatní značky Možnosti tvorby šablon Shrnutí konceptů a výhod užití NetBeans RCP API použitá pro tvorbu nového modulu Nodes API Filesystems API, Datasystems API Window System API Web APIs, J2EE DD API Project API, Project UI API, Java Project Support Lexer API Editor API, Text API Implementace zásuvného modulu Implementovaná funkcionalita Registrace rámce v projektu Nové šablony souborů Nové položky JSP palety Hypertextové odkazy Použité nástroje a postupy NetBeans IDE Řízení projektu Publikování nových verzí modulu Problémy a jejich řešení Dialogy pro výběr souboru Refactoring Přechod na platformu NetBeans verze Testování Závěr Literatura Rejstřík vii

8 Kapitola 1 Úvod Tvorba webových aplikací se stala v posledních letech jedním z nejrychleji se rozvíjejících odvětví vývoje softwaru. Již nestačí tvořit aplikace pro izolované uživatele, čím dál častěji je požadována komplexní funkcionalita založená především na spolupráci mnoha uživatelů, sdílení dat, autorizaci, autentizaci a dalších pokročilých funkcích. K naplnění těchto požadavků postupně vykrystalizovala specifická kategorie softwaru webové aplikace. Tento druh aplikací lze tvořit v mnoha programovacích či skriptovacích jazycích, z nejpoužívanějších v současné době jmenujme C#, Javu, Ruby, Python či PHP. Každý z těchto jazyků má svoje specifika, výhody i nevýhody, mnoho expertů se však shoduje na tom, že pro opravdu robustní, škálovatelné, spolehlivé a výkonné aplikace je vhodné zvolit jazyk Java. Tato volba v sobě v prvotním kroku zahrnuje zvýšené náklady, a to jak materiální, tak co se vzdělání týče. V současné době, na rozdíl od PHP či Ruby, stále neexistuje téměř žádný bezplatný hosting pro Java aplikace. A pokud už se nějaký najde, pak je poskytována pouze velmi omezená konfigurace, na které není možné provozovat žádný sofistikovanější systém používající některé z moderních prvků edice Java EE. Jedinou možností je placená služba nějakého zkušeného poskytovatele či vlastní server. Základním nástrojem pro obsluhu komunikace přes protokol HTTP jsou standardy Java Servlet API a Java Server Pages. Jde o nízkoúrovňové řešení, s nímž lze sice vytvořit libovolnou aplikaci, ale je to zdlouhavé a neefektivní. Postupně tak začaly vznikat nadstavby nad těmito API, které vývoj webových aplikací v jazyce Java podstatně usnadňují webové rámce. K maximální efektivitě využití možností, které rámce nabízejí, je velmi vhodné, aby pro ně byla co nejširší podpora ze strany vývojových prostředí jako jsou NetBeans, Eclipse či IDEA. V kapitole 2 se nejprve seznámíme se specifiky vývoje webových aplikací v prostředí Java. V další kapitole 3 podrobněji probereme architekturu rámce Stripes a srovnáme ho s dalšími používanými rámci. Náplň kapitoly 4 bude tvořit rozebrání návrhu platformy NetBeans a základní seznámení s API použitými k vývoji zásuvného modulu pro podporu rámce Stripes. Poté se již budeme v kapitole 5 zabývat samotným zásuvným modulem jeho možnostmi a implementací. Poslední kapitola 6 rekapituluje a hodnotí dosažené výsledky a specifikuje prostor pro další rozvoj modulu. 1

9 Kapitola 2 Vývoj webových aplikací v jazyce Java Tato diplomová práce se zabývá integrací webového rámce do vývojového prostředí Net- Beans, nejprve si tedy musíme objasnit, jak jsou webové aplikace v Javě specifikované a na jakých základech je každá taková webová aplikace vystavěna. K tomu je nezbytné ale nejdříve definovat prostředí, kde může každá webová aplikace běžet, a služby, které může využívat. 2.1 Běhové prostředí kontejnery Základní běhové prostředí pro webové aplikace v Javě poskytuje tzv. kontejner. Tato softwarová komponenta zajišt uje pro webové aplikace základní služby, například bezpečnost, souběžnost, řízení životního cyklu, transakce či nasazování nových webových aplikací. Podle typu komponent, které je možné v kontejneru nasadit a používat, jsou dále rozlišovány například Servlet kontejnery, EJB kontejnery či Portlet kontejnery. Nejpoužívanějšími jsou v současné době open-source kontejnery Apache Tomcat, Liferay, Jetty, GlassFish či komerční JBoss nebo WebSphere od IBM. Každý z nich zajišt uje nějakou podmnožinu popsaných služeb. 2.2 Definice webové aplikace Spolu s vydáním první verze Java Servlet API 1 byl do jazyka Java, potažmo její edice J2EE, zaveden koncept webové aplikace. Podle této specifikace je webová aplikace definována takto: Webová aplikace je kolekcí servletů, HTML stránek, tříd a dalších zdrojů, které jsou společně svázány a lze je nasadit a používat na různých kontejnerech od různých výrobců. V zásadě lze rozlišit dva typy webových aplikací: 1 Prezentační webové aplikace tyto aplikace generují pro každého uživatele sadu dynamických webových stránek různého značkování (HTML, XHTML, XML...), které podle akcí prováděných uživatelem mění svůj obsah. Tyto aplikace často slouží jako klient neobsahují téměř žádnou aplikační logiku ani přímé spojení s perzistentním úložištěm (databází). Pokud prezentační aplikace potřebuje tyto služby využít, použije servisní třídy příslušné servisní webové aplikace. 1. Verze 2.2 vznikala průběžně během roku 2000, viz následující podkapitola

10 2.2. DEFINICE WEBOVÉ APLIKACE Servisní webové aplikace slouží jako koncový bod, zajišt ují zmíněné služby jako je persistence objektů a obsahují třídy reprezentující aplikační logiku. S prezentační částí komunikují nejrůznějšími způsoby. Pokud se nacházejí obě aplikace na různých strojích, je třeba využít některou z metod vzdálené komunikace například pomocí webových služeb nebo některého z RPC protokolů (Remote Procedure Call). Často je však servisní aplikace přibalena k prezentační formou knihovny a všechna komunikace je redukována na volání jednotlivých metod servisních tříd. Celou situaci ilustruje schématický obrázek 2.1. Tato idea dekompozice má velmi blízko k architektuře klient-server, více viz [CS]. Obrázek 2.1: Druhy webových aplikací Prezentační webové aplikace Nadále se již budeme zabývat pouze prezentačními webovými aplikacemi, jelikož webové rámce jako Stripes jsou součástí právě prezentačních vrstev. V dalším obsahu bude pojem webová aplikace synonymem pro prezentační webovou aplikaci. Jedna z vlastností webových aplikací je vztah se Servletovým kontextem. Každá webová aplikace má právě jeden takový kontext. Vztah mezi kontextem a webovou aplikací je kontrolován kontejnerem a tento zajišt uje, že každé dvě aplikace nasazené v témže kontejneru mezi sebou nebudou nijak kolidovat ani se navzájem ovlivňovat. Součástí webové aplikace mohou být tyto objekty: servlety; 3

11 2.2. DEFINICE WEBOVÉ APLIKACE JSP soubory; třídy implementované v jazyce Java; statické dokumenty HTML soubory, obrázky a další; meta informace sloužící k popisu dané webové aplikace. Každá webová aplikace má podle specifikace přesně danou souborovou strukturu, která je vyžadovaná každým kontejnerem. Webová aplikace s nesprávnou strukturou bud nepůjde do kontejneru ani nasadit, nebo nebude správně pracovat. Pro ukázku zvolme jako kořen naší aplikace složku ovoceazelenina. Pak správně strukturovaná webová aplikace bude vypadat následovně: /ovoceazelenina Tato složka (a případně i všechny její podsložky) obsahují soubory, které budou po nasazení v kontejneru přímo adresovatelné pomocí URL. Soubor: /ovoceazelenina/dalsi/zeli.html bude typicky dostupný na adrese: /ovoceazelenina/web-inf Obsahem této složky jsou nejčastěji různé XML deskriptory dané webové aplikace (například web.xml, viz podkapitola 2.2.2), mohou se zde ale nacházet i libovolné další zdroje stejně jako v kořenové složce. Žádný z obsažených souborů není ale přímo dostupný pomocí své URL. /ovoceazelenina/web-inf/lib V této složce jsou všechny jar soubory naší webové aplikace knihovny, na kterých je naše aplikace závislá. Například knihovna pro tvorbu log souborů, vzdálený přístup k jiným aplikacím a budou se zde nacházet i knihovny potřebné k běhu rámce Stripes, pokud ho budeme chtít v naší webové aplikaci využívat. /ovoceazelenina/web-inf/classes Složka obsahující zkompilované třídy naší aplikace například servlety, viz podkapitola Deployment deskriptor Srdcem každé webové aplikace je její deployment deskriptor. Je reprezentován XML souborem web.xml, který je umístěn ve složce WEB-INF, v našem příkladu půjde tedy konkrétně o soubor ovoceazelenina/web-inf/web.xml. Tento XML soubor popisuje nastavení pro celou webovou aplikaci. Obsahuje například tyto elementy: 4

12 inicializační parametry servletového kontextu; 2.2. DEFINICE WEBOVÉ APLIKACE konfiguraci sezení (session) jak dlouho bude například trvat, než vyprší; definice servletů a filtrů; mapování servletů a filtrů na URL lze využít i divoké karty, například servlet mapovaný na URL *.action bude obsluhovat všechny URL končící na.action; mapování MIME typů; seznam výchozích souborů ty budou ve složce vždy hledány, pokud není v URL explicitně zadán požadovaný soubor, typicky je proveden pokus o nalezení a zobrazení souboru index.html; definici chybových stránek, které budou zobrazeny pro dané chybové kódy HTTP protokolu například chyba s kódem 404, stránka s daným URL nebyla nalezena; ošetření bezpečnosti které oblasti webové aplikace budou autentizované, jaké uživatelské role budou pro vstup požadovány apod. Pro názornost následuje jednoduchý příklad deployment deskriptoru, který do webové aplikace přidává podporu pro rámec Stripes: <?xml version="1.0" encoding="utf-8"?> <web-app version="2.5" xmlns=" xmlns:xsi=" xsi:schemalocation=" <filter> <filter-name>stripesfilter</filter-name> <filter-class>net.sourceforge.stripes. controller.stripesfilter</filter-class> <init-param> <param-name>localepicker.locales</param-name> <param-value>en:utf-8,cs:utf-8</param-value> </init-param> <init-param> <param-name>actionresolver.packages</param-name> <param-value>com.my.web.bean</param-value> </init-param> </filter> <filter-mapping> <filter-name>stripesfilter</filter-name> <url-pattern>*.jsp</url-pattern> <dispatcher>request</dispatcher> </filter-mapping> 5

13 <filter-mapping> <filter-name>stripesfilter</filter-name> <servlet-name>dispatcherservlet</servlet-name> <dispatcher>request</dispatcher> </filter-mapping> <servlet> <servlet-name>dispatcherservlet</servlet-name> <servlet-class>net.sourceforge.stripes. controller.dispatcherservlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcherservlet</servlet-name> <url-pattern>*.action</url-pattern> </servlet-mapping> <session-config> <session-timeout> 30 </session-timeout> </session-config> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app> 2.2. DEFINICE WEBOVÉ APLIKACE V příkladu můžeme vidět, že se jedná o aplikaci užívající Java Servlet API verze 2.5 (...<web-app version="2.5"...). Je definován pouze jeden HTTP filtr nesoucí název StripesFilter, který má dva inicializační parametry. Tento filtr je aplikován na všechny JSP stránky (URL končící na sekvenci.jsp). Také je specifikován jeden servlet s názvem DispatcherServlet, který obsluhuje všechny URL ukončené sekvencí znaků.action. Dále je nakonfigurováno sezení tak, že vyprší vždy za 30 minut. Posledním elementem je definice souborů, které se hledají ve složce, pokud nebyly v URL explicitně zvoleny. Detailněji se budeme funkci a významu jednotlivých komponent, důležitých pro běh rámce Stripes, věnovat v kapitole 3. Mnohé společnosti vyvíjející jednotlivé kontejnery podporují i řadu dalších deskriptorů pro webové aplikace, které se rovněž vždy nalézají ve složce WEB-INF. Tyto vždy nějakým dalším způsobem rozšiřují možnosti konfigurace dané webové aplikace v oblasti, kterou neobsahuje specifikace Servlet API. Příkladem může být soubor sun-web.xml, který čte a aplikuje při nasazování aplikace pouze kontejner GlassFish od firmy Sun spolu se standardním deskriptorem web.xml. 6

14 2.3. JAVA SERVLET API 2.3 Java Servlet API Java Servlet API je základní normou pro zpracovávání HTTP požadavků v prostředí platformy Java. Tato specifikace vznikala od roku 1997 a postupně byla publikována jako jednotlivé normy JSR 2. K dnešnímu datu (10. březen 2009) je aktuální Servlet API verze 2.5 ze září roku 2005 jako JSR 154. V poslední fázi připomínkového řízení je od ledna roku 2009 verze 3.0 jako JSR 315. Součástí edice J2EE jazyka Java se staly servlety od verze 2.2 (J2EE verze 1.2). 2 Při běžném provozu webových aplikací se téměř výhradně užívá protokol HTTP, případně jeho zabezpečená varianta HTTPS. Specifikace Java Servlet API obsahuje předem implementované třídy právě pro tento protokol, je však možné specifikaci využít i pro obsluhu dalších protokolů využívaných v internetovém prostředí. Specifikace obsahuje popis dvou základních entit servletů a filtrů Protokol HTTP Protokol HTTP je nejběžnějším prostředkem pro získání obsahu z webového serveru prostřednictvím internetu. Pracuje na principu požadavek odpověd a je bezstavový. Mezi jednotlivými dotazy si server například nepamatuje údaje o uživateli, každý požadavek je nezávislý na každém dalším, i kdyby přišel ze stejného prohlížeče a od stejného uživatele. Pokud je držení stavu žádoucí, využívá se například sezení nebo cookies. První metoda je implementována na straně serveru, o druhou se stará klient (webový prohlížeč). Typický životní cyklus jednoho požadavku lze ve zkratce popsat následující sekvencí. Klient (webový prohlížeč) pošle požadavek (request) vytvořený pro danou URL zadanou uživatelem. K požadavku je případně v jeho těle připojen i obsah formuláře vyplněného uživatelem. Pokud je server nalezen, pro daný požadavek vrátí odpověd (response), která nejčastěji obsahuje v těle HTML či XML značkování. Tento navrácený obsah webový prohlížeč zpracuje a graficky (případně textově) zobrazí uživateli. Protokol definuje několik dotazovacích metod možných druhů požadavků. Mezi nejvyužívanější metody patří tyto: get celý požadavek je určen pomocí URL požadované k zobrazení, případné parametry jsou součástí jako soubor dvojic klíč = hodnota. post pomocí této metody se na server nejčastěji odesílají data většího objemu. Používá se například po vyplnění formuláře a odesílání jeho obsahu na server ke zpracování. Data se posílají v těle požadavku. options slouží ke zjištění HTTP metod podporovaných daným serverem. Podrobnější informace o tomto komunikačním protokolu a kompletní popis všech jeho metod lze nalézt například na webu [HTTP]. 2. JSR je zkratkou ze slov Java Specification Request. Jde o produkt vycházející z Java Community Process, což je otevřený proces tvorby norem pro jazyk Java. Více viz [JSR]. 7

15 2.3. JAVA SERVLET API Servlet Základním nástrojem pro obsluhu HTTP komunikace v Javě je servlet. Specifikace Java Servlet API je obecná a neomezuje se pouze na protokol HTTP, využít ji lze pro obsluhu libovolného protokolu založeného na principu požadavek odpověd. V balíku javax.servlet se nachází rozhraní Servlet a jeho abstraktní implementace GenericServlet. K obsluze HTTP požadavků je k dispozici třída HttpServlet z balíku javax.servlet.http, která je rozšířením třídy GenericServlet. Rozhraní Servlet obsahuje především tyto tři metody: init(); service(); destroy(). Třída HttpServlet již obsahuje metody pro obsluhu jednotlivých druhů HTTP požadavků metod zmíněných v předešlé podkapitole 2.3.1: doget() obsluha HTTP požadavků generovaných metodou get; dopost() obsluha HTTP požadavků odeslaných pomocí metody post atd Životní cyklus servletu Typický životní cyklus každého servletu se dá popsat těmito čtyřmi body: 1. Třída servletu je načtena do paměti příslušnou ClassLoader instancí 3, která obsluhuje daný servletový kontejner Kontejner zavolá metodu init(), dříve než je k servletu doručen první požadavek. Tato metoda je vždy zavolána právě jednou. 3. Servlet je připraven k provozu, kontejner volá metodu service() pokaždé, když je HTTP požadavek určen pro tento servlet. 4. Nemá-li už být servlet nadále používán (webová aplikace, jejíž je součástí, je odinstalována z kontejneru apod.), zavolá kontejner metodu destroy(), čímž končí životní cyklus tohoto servletu. V dalším textu, pokud nebude explicitně uvedeno jinak, budeme již pod pojmem servlet mít vždy na mysli HTTP servlet. 3. Více o principech načítání tříd v Javě a konceptu virtuálních strojů lze nalézt například v [CLLDR]. 8

16 2.3. JAVA SERVLET API Příklad servletu Každý servlet je potomkem třídy HttpServlet a musí překrývat vždy aspoň jednu z metod pro obsluhu HTTP požadavků. Tento servlet musí být rovněž korektně nadefinován v deskriptoru webové aplikace v souboru web.xml. Příkladem jednoduchého servletu může být následující třída: package com.my.web.servlet; import java.io.ioexception; import java.io.printwriter; import javax.servlet.servletexception; import javax.servlet.http.httpservlet; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; public class MyServlet extends HttpServlet public void doget(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException { res.setcontenttype("text/html;charset=utf-8"); PrintWriter out = res.getwriter(); } } try { out.println( "<html>\n" + " <head><title>my First Servlet</title></head>\n" + " <body>\n" + " <h1>this is my first servlet ever made!</h1>\n" + " </body>\n" + "</html>"); } finally { out.close(); } Správnou definice tohoto servletu v souboru web.xml pak ilustruje tento fragment XML značkování: <servlet> <servlet-name>myservlet</servlet-name> <servlet-class>com.my.web.servlet.myservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>myservlet</servlet-name> <url-pattern>/myservleturl</url-pattern> </servlet-mapping> 9

17 2.3. JAVA SERVLET API Servlet je podle definice určen na obsluhu jediné URL. Pokud by byl součástí naší demonstrační webové aplikace (viz podkapitola 2.2.1), byla by metoda doget() zavolána vždy, když by webový prohlížeč odeslal požadavek pomocí metody get protokolu HTTP na URL <nase_domena>:<port_kontejneru>/ovoceazelenina/myservleturl. Servlety se užívají ke generování obsahu nejrůznějších formátů, nejčastěji jsou výstupem HTML či XML stránky, jako tomu je i v našem jednoduchém příkladu. Ke generování větších fragmentů zmíněných formátů je však vhodnější využít přesměrování požadavku na nějakou JSP stránku. Jejich princip bude popsán v následující podkapitole 2.4. Dalším velmi častým použitím servletů je zpřístupnění souborů (obrázků, PDF dokumentů a dalších), které nejsou statické či nejsou dostupné z kořene webové aplikace (viz příklad v podkapitole 2.2.1). Stačí specifikovat správný typ obsahu MIME typ 4 a do odpovědi (objektu typu HttpServletResponse) zapsat obsah daného souboru jako proud bytů Filtr Verze 2.3 specifikace Java Servlet API zavedla do konceptu webových aplikací novou entitu filtr. Tato komponenta dynamicky zachytává jednotlivé HTTP požadavky směřující na webovou aplikaci a provádí nad nimi požadované operace. Filtry stejně jako servlety jsou mapovány na obsluhu URL podle definice v deployment deskriptoru (viz podkapitola 2.2.2). Specifikace komponenty filtr je dána rozhraním Filter z balíku javax.servlet. Konkrétní filtr je pak třídou implementující toto rozhraní. Specifikace neobsahuje žádnou generickou implementaci filtru ani specifické rozhraní pro HTTP filtr. Rozhraní Filter obsahuje metodu: void dofilter(servletrequest request, ServletResponse response, FilterChain chain) Životní cyklus filtru je velmi podobný servletu, rozhraní Filter rovněž obsahuje metody init() a destroy() se sémantikou ekvivalentní metodám z rozhraní Servlet. Filtry mohou plnit nejrůznější funkce, příklady možného využití lze nalézt v následujícím výčtu: Autentizace na základě údajů o přihlášeném uživateli (které lze získat z předaného HttpServletRequest objektu) je možné zamítnout přístup do určité oblasti webové aplikace. Požadavek je typicky filtrem přesměrován na stránku s chybovou zprávou. Tvorba log souborů a evidence užívání filtry lze rovněž využít ke sledování návštěvnosti jednotlivých stránek, případně k zaznamenávání statistik o jednotlivých požadavcích apod. 4. Multipurpose Internet Mail Extensions, více viz například [MIME]. 10

18 2.4. JAVA SERVER PAGES Transformace XML pomocí XSLT šablon podle typu zařízení, ze kterého byl odeslán požadavek, je možné přeformátovat XML výstup tak, aby maximálně vyhovoval danému zobrazovacímu zařízení. Komprese dat pokud webový prohlížeč podporuje příjem HTTP odpovědí v komprimovaném formátu (GZIP apod.), je možné například původní odpověd servletu zkomprimovat a tím urychlit přenos odpovědi ze serveru zpět k webovému prohlížeči. Lokalizace s využitím dat o uživateli, který požadavek vytvořil, lze požadavek nasměrovat na obsah s regionálním nastavením co nejvíce se blížícím jeho místním zvyklostem, například správným časovým pásmem, měnou a podobně. Jeden HTTP požadavek může projít i více filtry, pořadí jejich aplikace je dáno pořadím jejich deklarace v deployment deskriptoru. Filtr má zároveň možnost v metodě dofilter() rozhodnout, že aktuální filtr bude posledním aplikovaným. Dalšími filtry tak na aktuální požadavek nebudou použity. Více informací o filtrech a jejich využití, včetně příkladů, lze nalézt například v [FLTR]. 2.4 Java Server Pages Jak již bylo naznačeno v předešlé podkapitole 2.3.2, servlety se příliš nehodí ke generování velkého objemu dat formátu HTML či XML. Snaha o účelnější způsob generovaní tohoto druhu dat vedla ke vzniku Java Server Pages. Počínaje verzí 1.2 technologie vycházela z Java Community Process formou jednotlivých specifikací JSR. Java servlety a technologie JSP jsou velmi úzce provázané, jsou proto i často součástí jednoho JSR (Java Servlets 2.3 a JSP 1.2 jsou dány společnou normou JSR 53). JSP 2.0 je samostatnou normou pokrytou JSR 152, od května roku 2006 je v platnosti finální verze JSR 245, jejíž součástí je specifikace JSP verze 2.1. V dalším textu se budeme zabývat vlastnostmi JSP podle nejnovější specifikace (2.1), pokud nebude výslovně zmíněna jiná verze. Pokud do kontejneru přijde požadavek na zobrazení výstupu nějaké JSP stránky, je nejprve zvolená stránka převedena na servlet pomocí JSP kompilátoru. Ten generuje bud Java byte kód, nebo zdrojový kód v jazyce Java, který je posléze přeložen běžným překladačem jazyka Java. Jednotlivé servlety lze generovat až při příchodu požadavku vedoucího na danou JSP stránku, či je všechny vygenerovat předem. Toto chování kontejneru lze ovlivnit, pro každou webovou aplikaci existuje možnost explicitně povolit či zakázat automatické generování servletů z JSP stránek Srovnání přípustných formátů JSP V zásadě jsou možné dvě syntaxe JSP souborů: standardní syntax a XML syntax. Oba zápisy jsou stejně silné oběma lze dosáhnout stejného výstupu. 11

19 2.4. JAVA SERVER PAGES Rozdíl mezi nimi si demonstrujeme na jednoduchém příkladu. JSP stránka utvořená pomocí XML syntaxe je čisté XML správně strukturované a validní. Jednoduchý soubor vzniklý tímto postupem může ilustrovat následující příklad: <?xml version="1.0" encoding="utf-8"?> <jsp:root xmlns:jsp=" version="2.0"> <jsp:directive.page contenttype="text/html" pageencoding="utf-8"/> <!-- any content can be specified here, e.g.: --> <jsp:text> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>jsp Page</title> </head> <body> <h1>hello <i>world</i>!</h1> </body> </html> </jsp:text> </jsp:root> Standardní JSP syntax vypadá při stejném výstupu takto: <%@page contenttype="text/html" pageencoding="utf-8"%> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>jsp Page</title> </head> <body> <h1>hello <i>world</i>!</h1> </body> </html> Druhý způsob zápisu standardní JSP syntax v drtivé většině webových aplikací převažuje nad prvním, a to z několika důvodů: je stručnější stránky pomocí ní lze tvořit rychleji; je čitelnější neobsahuje upovídané části bez viditelného výstupu; je známější pro CSS designéry znalé (X)HTML je standardní syntax snazší na pochopení a přístupnější k vytvoření sedícího stylu; 12

20 2.4. JAVA SERVER PAGES umožňuje přímočarý HTML výstup HTML není kompatibilní s XML, nepárové značky by tak musely být při použití XML syntaxe uzavřeny v CDATA sekcích; je stejně silná jako XML syntax. Z těchto důvodů se dále budeme zabývat pouze standardní syntaxí Standardní syntax JSP V každé JSP stránce můžeme rozlišit těchto pět základních částí (ne všechny ale musí být vždy využity): statická data například HTML značkování; JSP akce nejčastěji užívány k vyvolání akcí v kontejneru; JSP direktivy slouží například k vložení jiné stránky, viz dále; JSP skriplety a výrazy Expression Language bude rozebráno vzápětí; značky z dalších JSP knihoven například JSTL, jež bude blíže rozebrána později v této podkapitole. Použití statických dat je nejpřímočařejší, nejčastěji ho tvoří HTML či modernější XHTML značkování. Podrobnější informace o dalších částech JSP stránek jsou podány v následujících podkapitolách JSP akce JSP akce jsou XML značky, které vždy vyvolají nějakou akci na straně kontejneru. Jsou vyvolávány vždy až za běhu servletu, do kterého byla daná JSP stránka přeložena. Nejpoužívanější jsou: jsp:usebean vytvoří Java Bean instanci dané třídy s daným ID, popřípadě znovu využije dostupnou instanci v aktuální stránce; jsp:include chování je identické jako u direktivy include; jsp:getproperty spolu s duální akci jsp:setproperty získá, popřípadě zapíše hodnotu parametru v dané Java Bean instanci. Specifikace obsahuje i další akce, mimo jiné jsp:forward, která přesměruje aktuální požadavek na jinou URL JSP stránku nebo servlet. Její užívání se ale příliš nedoporučuje, pokud se snaží programátor dodržet princip architektury Model-View-Controller MVC. V této totiž JSP stránky slouží pouze jako komponenta zobrazující data uživateli (View) a zásadně neprovádí žádná přesměrování či podobné akce. Princip MVC přístupu k budování aplikací bude podrobněji probrán v podkapitole Tabulku srovnávající obě syntaxe lze nalézt například v [JSPSYNT]. Jedná se však pouze o JSP verze

21 2.4. JAVA SERVER PAGES JSP direktivy JSP direktivy jsou uzavřeny v sekvenci znaků <%@ %>, ve specifikaci jsou uvedeny tyto tři: include slouží ke vložení obsahu jiné JSP stránky do té aktuální: <%@ include file="somefile.jspf" %> page má mnoho použití, například nastavuje content-type dané JSP stránky nebo její kódování: <%@ page contenttype="text/html" %> <%@ page pageencoding="utf-8" %> taglib slouží k rozšíření sady dostupných značek o značky definované nějakou knihovnou: <%@ taglib prefix="s" uri=" %> Dynamický obsah JSP stránek Základním účelem JSP komponent je generování dynamického obsahu, dosáhnout toho lze bud psaním skripletů nebo využíváním výrazů Expression language. První způsob vychází ze starších verzí JSP a od jeho užívání je upouštěno, protože znepřehledňuje JSP kód a svádí ke špatným vzorcům programování. Od JSP verze 2.0 byl zaveden uniformní jazyk výrazů Expression language (dále jen EL). Byla sjednocena jeho syntaxe s podobným jazykem užívaným v JSF komponentách (viz dále). At se programátor rozhodne pro kterýkoliv přístup, vždy má v JSP stránce k dispozici sadu implicitních objektů. O jejich zpřístupnění a korektní zinicializování se stará kontejner spravující příslušnou JSP stránku. Mezi tyto objekty patří aktuální sezení (session instance třídy implementující rozhraní javax.servlet.http.httpsession), HTTP request (instance implementující javax.servlet.http.httpservletrequest) nebo odkaz na výstupní proud určený k zápisu dat do HTTP odpovědi generované servletem (objekt typu HttpServletResponse). Skriplety jsou části JSP kódu ohraničené sekvencí znaků <% %> a mohou obsahovat libovolný správně utvořený kus Java kódu. Tento kód je při překladu JSP stránky na servlet přímo vložen na dané místo do metody obsluhující HTTP požadavek. Skriplet může být rovněž uzavřen znaky <%! %>, obsažený Java kód bude do výsledného servletu vložen mimo obslužnou metodu, lze v něm tedy například definovat novou metodu nebo atribut daného servletu. V našem příkladu uvažme dvě třídy, User a Book, které jsou obě správně utvořené Java Beans 6. JSP skriplet pak může vypadat třeba takto: 6 6. Java Bean je třída s bezparametrickým konstruktorem, která pro čtení s zápis svých parametrů využívá pouze metod getterů a setterů. Více o Java Beans viz například [JBNS]. 14

22 2.4. JAVA SERVER PAGES User has specified a book with name <% User user = (User) request.getattribute("user"); if (user!= null) { Book book = user.getbook(); if (book!= null) { out.print(book.getname()); } } %>. Oproti tomu, výrazy EL jsou celé uvozeny znakem dolar($) a uzavřeny ve složených závorkách ({}). Stejného výsledku jako v předešlém skripletu (tedy vypsání jména knihy daného uživatele) lze dosáhnout i použitím EL: User has specified a book with name ${user.book.name}. Úspora kódu je na první pohled zřejmá. Výrazy jazyka EL lze nyní využít v jakékoliv části dokumentu, výskyt není omezen pouze na atributy specifických značek, jak tomu bylo ve standardu JSP před verzí 2.0. Výrazy EL mohou obsahovat proměnné základních primitivních typů známých z jazyka Java (boolean, integer, float, string a null), kolekce proměnných, stejně jako mapy (instance java.util.map) a nad těmito mohou být dále prováděny jak aritmetické tak logické operace. Více o EL, jeho možnostech a omezeních lze najít například v [EL] Knihovny značek Expression language neobsahuje žádné konstrukce známé z imperativního paradigmatu, například do-while cyklus nebo for cyklus. Vhodným doplněním jazyka EL je tak některá knihovna značek pokrývající tyto požadavky, například JSTL (Java Server Pages Standard Tag Library ), produkt z portfolia společnosti Sun. Jde o kolekci pěti knihoven značek, námi požadované imperativní konstrukce obsahuje knihovna JSTL Core. Ostatní knihovny slouží například pro práci s XML, SQL či k lokalizaci obsahu pomocí Java ResourceBundles 7. 7 Knihovna se nejprve pomocí direktivy include nadefinuje v hlavičce JSP stránky a pak již lze jí definované značky užívat v celém JSP dokumentu, vždy uvozené příslušným prefixem. Pokud tedy chceme projít kolekci (seznam či množinu) objektů, může kód využívající kombinaci JSTL a EL vypadat následovně (opět předpokládáme, že objekty v kolekci users jsou správně utvořené Java Beans s parametry name a age): <%@ taglib prefix="c" uri=" %> There are following users available: <c:foreach var="user" items="${users}" > 7. Více o lokalizaci v Javě viz JavaDoc edice J2SE [RBNDL]. 15

23 ${user.name} - ${user.age}, </c:foreach> 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Kompletní dokumentaci k JSTL lze nalézt v [JSTL]. Pokud žádná existující knihovna značek nevyhovuje potřebám naší webové aplikace, lze si napsat i vlastní. Podrobných návodů lze nalézt na internetu dostatek, dobrým startovním bodem je například výukový kurz na webu firmy Sun, viz [JSTLTUT]. 2.5 Webové aplikační rámce Spolu s uvedením dříve zmíněných specifikací, které dávají k dispozici základní nástroje k tvorbě webových aplikací v jazyce Java, začalo mnoho těchto aplikací vznikat. Postupem času začalo být zřejmé, že v jednotlivých webových aplikacích se často opakují podobné požadavky co se funkcionality týče. A to bylo hlavním impulsem ke vzniku prvních webových rámců. Webové aplikační rámce jsou softwarové knihovny, které poskytují nástroje, jak typicky požadované služby zpřístupnit pro libovolnou novou webovou aplikaci. Zabývat se budeme především službami týkajícími se tvorby uživatelského rozhraní, jelikož na tuto oblast je zaměřen i rámec Stripes. Přehledný a poměrně obsáhlý seznam (obsahuje více jak 50 položek) existujících webových rámců dostupných pro jazyk Java lze nalézt v [WFWRKS] Typicky poskytované služby Nejběžnější aspekty funkcionality, které poptává mnoho webových aplikací, shrnují následující podkapitoly Autentizace a autorizace Webové aplikace velmi často vyžadují, aby svůj obsah generovaly v závislosti na uživateli, který k ní přistupuje. Tedy v první řadě je nutné zajistit správu uživatelských účtů a rolí, pomocí nichž je pak nejčastěji řízen systém oprávnění. Webové rámce přistupují k oběma úkolům různě. Některé jako jednotku přístupu používají JSP stránky daný uživatel ji bud může či nemůže zobrazit. Jiné využívají například Java anotací 8 a autorizace je aplikována při vykonávání jednotlivých Java metod Tvorba hezkých URL V dnešní době je SEO Search Engine Optimalization 9 velmi využívanou marketingovou metodou. Velkou devizou webové aplikace je tak její vstřícnost k internetovým vyhledávačům, jejíž součástí je i využívání dobře utvořených URL. Avšak URL generované webovou 8. Anotace jsou novým syntaktickým prvkem jazyka Java od verze 1.5. Jde o meta informace, které mohou být přidány k řadě prvků: třídám, metodám, atributům tříd a dalším. Více viz například [ANOT]. 16

24 2.5. WEBOVÉ APLIKAČNÍ RÁMCE aplikací mohou být velmi dlouhé, nepřehledné a pro tyto účely zcela nepoužitelné. Mapování hezkých URL tak tvoří vhodný nástroj, jak na jedné straně ponechat vývojáři webové aplikace podle potřeby volnost v tvorbě URL a na druhé poskytnout celou aplikaci k dispozici vyhledávačům Nástroje pro tvorbu šablon Pro návrh vzhledu webových stránek je jednou z dobrých technik dodržování jednotného vzhledu. Tedy, že uživatel není při přechodu mezi jednotlivými stranami zmaten navigaci například najde vždy na stejném místě, hlavní obsahové sdělení každé stránky je zřetelně označené, barevné schéma se radikálně nemění a je přiměřeně kontrastní apod. V rozsáhlých webových aplikacích se typicky zobrazuje mnoho různých dat. Obsah výsledné stránky pak z velké části tvoří stále stejný obsah hlavička, menu, rychlá navigace či patička. K dosažení jednotného vzhledu nabízí mnoho webových rámců systémy pro tvorbu šablon, tedy možnost definovat různé vzory rozložení. Pro konkrétní obsah lze pak jen zvolit použití vybrané šablony a dodat konkrétní data zobrazená na stránce. Tím se docílí jak výše zmíněné jednotnosti vzhledu, tak i lepší udržovatelnosti zdrojových kódů Cache Pro vytížené webové aplikace, které mají za úkol obsluhovat mnoho uživatelských požadavků současně, je téměř nezbytné využívat nějakou úroveň ukládání do vyrovnávací paměti (cache). Pokud jsou splněny určité požadavky, pak dva různé požadavky na tutéž stránku mohou být uspokojeny stejným výsledkem s tím, že v druhém případě se již poskytne jako odpověd stránka vygenerovaná pro předešlý požadavek. Tím se například zamezí opakovanému přístupu do databáze pro stejná data či interpretaci šablony rozložení (viz předchozí bod) AJAX Asynchronous JavaScript and XML neboli AJAX se postupně vyvinul jako reakce na požadavek, aby webové aplikace byly více interaktivní. Standardně fungují webové aplikace na principu požadavek-odpověd (podrobnosti viz podkapitola 2.3.1). To však často vede ke zbytečnému přenosu stále stejného HTML značkování. Pokud výsledek akce směruje uživatele na stejnou stránku, ze které byl požadavek odeslán, často není třeba získávat kompletní HTML stránku. Stačí získat relevantní data, která se provedenou akcí změnila a tyto zakomponovat do současné HTML stránky. Dalším velmi obvyklým příkladem užití může být našeptávač. Ten při vyplňování textového pole ve formuláři dynamicky získává ze serveru relevantní data odpovídající již napsanému textu a dává je k dispozici uživateli jako přehledný seznam zobrazený pod textovým 9. SEO je soubor technik, které mají webovou stránku či celou aplikaci učinit lépe viditelnou pro internetové vyhledávače. Mezi etické metody patří kvalitní obsah, validní (X)HTML kód, sémantické značkování obsahu, poskytnutí meta informací o obsahu stránek nebo krátké a výstižné URL. Více lze nalézt například v [SEO]. 17

25 2.5. WEBOVÉ APLIKAČNÍ RÁMCE polem. Uživatel pak nemusí vypisovat celý obsah pole, stačí vybrat z nabízených hodnot, pokud mu některá vyhovuje. V současné době již existuje mnoho knihoven napsaných v jazyce JavaScript, které asynchronní získávání dat redukují na záležitost několika řádků kódu. Z nejznámějších uved me jquery 10, DOJO 10 nebo Prototype 10. Tyto jsou často součástí samotných webových rámců a poskytují i nějakou pokročilejší míru integrace Přístup do databáze Tento aspekt se do oblasti prezentačních webových rámců příliš počítat nedá. Většinou se užívá striktní oddělení prezentační vrstvy a aplikační logiky (viz obrázek 2.1) a o přímý přístup do databáze se stará jiná část aplikace. Nicméně pro rychlou tvorbu prototypů obsahují i některé prezentační rámce možnosti přístupu do databáze, objektově-relační mapování 11 nebo řízení transakcí Architektura MVC Častým problémem rostoucích aplikací, nejen webových, se stává udržovatelnost produkovaného kódu. S časem se požadavky na aplikaci mohou měnit, a ta se jim musí přizpůsobovat. Proto je velmi důležité už na začátku návrhu zvolit vhodnou architekturu, nejlépe s využitím již vyzkoušených návrhových vzorů Téma návrhových vzorů a obecně architektura SW systémů by vydaly na samostatnou práci, my se budeme krátce zabývat pouze konceptem často využívaným v prezentačních webových rámcích. Tím je architektura MVC Model-View-Controller, jejíchž pravidel se drží i rámec Stripes. Nyní si tento způsob tvorby webových aplikací blíže popíšeme Základní koncept Základním stavebním kamenem konceptu MVC je jasné oddělení následujících tří složek webové aplikace: model data z doménové oblasti, kterou aplikace pokrývá; view vizualizace dat, tedy jejich prezentace uživateli; controller aplikační logika starající se o obsluhu uživatelských akcí a řídící tok celé aplikace. 10. Oficiální stránky zmíněných projektů lze nalézt na následujících stránkách: jquery com/, DOJO Prototype Objektově-relační mapování ORM je způsob, jak nakládat s relačními databázovými daty jako s běžnými objekty programovacího jazyka. Více viz [ORM]. 12. O návrhových vzorech při vývoji software bylo napsáno již mnoho knih a spoustu informací lze nalézt i na webu, například v [DP]. 18

26 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Jako model jsou ve webových rámcích pro jazyk Java používány různé technologie, nejčastěji JSP nebo FreeMarker Životní cyklus požadavku Ačkoliv se v detailech mohou jednotlivé implementace lišit, nejčastěji probíhá zpracování požadavku v těchto krocích: 1. uživatel se nachází na některé stránce webové aplikace a provede zvolenou akci (například stiskne tlačítko); 2. tím aplikace obdrží požadavek a upozorní komponentu controller, která spustí obsluhu doručeného požadavku; 3. pokud uživatel odeslal požadavek na změnu dat (modelu), controller tuto operaci provede (například smaže položku z databáze); 4. poté controller vybere stránku (view), která má být uživateli zobrazena; 5. zde jsou dvě možnosti dalšího postupu: a controller dodá potřebná data, která se mají zobrazit v komponentě view; b samotná komponenta view si potřebná data obstará, bez zásahu controlleru; 6. ze zvolené stránky a získaných dat je utvořena HTTP odpověd a doručena webovému prohlížeči uživatele; 7. aplikace čeká na další akci iniciovanou uživatelem, kruh se tím uzavírá. Celou situaci zpracování jednoho požadavku ilustruje obrázek 2.2. Webové rámce založené na konceptu MVC můžeme dále rozdělit na dvě základní podskupiny. Tyto se navzájem liší mimo jiné v pátém bodu předešlého popisu zpracování požadavku, rozlišujeme tedy rámce založené na: komponentách také tzv. pull-based rámce akcích jinak též tzv. push-based rámce 13. FreeMarker je technologie v základu podobná JSP, pouze s jinou syntaxí. Umožňuje specifikovat šablony obsahující jak statická tak i dynamická data. Engine pro zpracování šablon poté při zobrazení konkrétní instance šablony nahradí dynamický obsah dodanými daty. Oproti čistému JSP (bez JSTL apod.) obsahuje podporu pro cykly, větvení, rekurzi a další. Více viz stránky projektu na webu 19

27 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Obrázek 2.2: Koncept architektury MVC Výhody a přínosy Jaké benefity nám tedy přinese snaha o dekompozici aplikace podle architektury MVC? Mezi nejdůležitější přínosy patří tyto: snadnější udržovatelnost úprava jednotlivých částí je snadnější a tím i levnější; nezávislost komponent je snadné vyměnit jednu komponentu za jinou a přitom máme zaručeno, že bude nová část se zbytkem systému korektně spolupracovat; znovupoužitelnost jednotlivé komponenty je možné opakovaně použít v dalších aplikacích a tím snížit náklady na jejich vývoj Rámce založené na komponentách Ačkoliv je rámec Stripes je zástupcem druhé skupiny, uvedeme si pro srovnání rovněž krátký popis nejpoužívanějších rámců prvního typu založených na komponentách. 20

28 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Tyto rámce mají jeden významný společný rys snaží se před vývojáři skrýt podstatu webových aplikací, tedy bezstavovost protokolu HTTP a jeho princip požadavek-odpověd. Na návrh webových aplikací se snaží tyto rámce pohlížet pomocí osvědčených postupů známých z tvorby běžných desktopových programů běžících v operačním systému. Druhým společným atributem je způsob, jakým je ve webové aplikaci zajištěno řízení životního cyklu pomocí zvoleného rámce. Ve všech případech se tak děje pomocí servletu případně filtru, který musí být přidán do deployment deskriptoru a správně namapován k obsluze všech požadovaných URL uvnitř webové aplikace. Není bez zajímavosti, že s příchodem Servlet API 3.0 by mělo zmizet i toto omezení webových rámců. Každý rámec bude moci specifikovat svůj vlastní soubor web.xml umístěný mezi zdrojovými soubory ve složce META-INF, který bude obsahovat všechny potřebné definice servletů či filtrů. Pokud bude knihovna s rámcem (tedy její jar soubor) přidána k webové aplikaci (tj. bude obsažena ve složce WEB-INF/lib dané webové aplikace), budou kontejnerem při jejím nasazení přidány všechny elementy ze souboru web.xml daného rámce do deployment deskriptoru samotné webové aplikace Java Server Faces Java Server Faces JSF jsou zřejmě nejznámějším a nejpoužívanějším zástupcem skupiny rámců založených na komponentách. Nejde však o jeden konkrétní rámec, nýbrž o standard, který je implementován v rámci jednotlivých projektů. Tento standard je součástí edice Java EE, jelikož pochází přímo z dílny společnosti Sun, a z tohoto faktu zřejmě plyne i jeho rozšířenost na poli webových aplikací. Firma Sun rovněž vytvořila referenční implementaci tohoto standardu. Historie JSF se začala psát v roce 2003, kdy byla jako JSR 127 zveřejněna jeho první specifikace verze 1.1. Ta stavěla na Java SE 1.4 a Servlet API 2.4. O tři roky později byla uvedena verze 1.2, která již požadovala pro svůj běh Servlet API 2.5 a Java SE 5, čímž byla značnou dobu limitována. Implementaci obou těchto standardů totiž dlouhou dobu poskytoval pouze aplikační server GlassFish firmy Sun. V současné době (březen 2009) se již téměř dva roky pracuje na JSF verze 2.0 v rámci JSR 314. Standard JSF je v mnohém podobný návrhu uživatelského rozhraní pomocí technologie Swing. Celá aplikace je tvořena jednotlivými komponentami, každá plní jasně daný díl funkcionality. Některé komponenty lze do sebe zanořovat (komponenta formulář obsahuje komponenty textové pole, tlačítko a další), jednotlivé akce vyvolané uživatelem (například stisk tlačítka) vytvářejí události, na které pak aplikace reaguje pomocí předem registrovaných posluchačů. Pro potřeby konfigurace se používá XML soubor faces-config.xml, který se nachází ve složce WEB-INF. V tomto deskriptoru je definováno použití jednotlivých posluchačů stejně jako navigační pravidla pro celou aplikaci. V nové verzi 2.0 lze pozorovat zřetelnou snahu o omezení konfigurace v XML souboru a jejího nahrazení pomocí anotací deklarovaných u jednotlivých elementů tvořených tříd. Mezi největší pozitiva tohoto standardu patří: 21

29 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Rychlá tvorba webových aplikací standard poskytuje základní sadu komponent, které pokrývají velkou část běžně požadované funkcionality (například tlačítka či celé formuláře). Stejně tak je i poskytnut prostor pro tvorbu nových komponent. V neposlední řadě je nutné k výhodám přičíst i možnost využít množství nástrojů, které podporují vizuální tvorbu JSF aplikací například modul Visual Web 4 JSF 14 pro NetBeans IDE. 14 Vynucování správného zapouzdření všechno jsou komponenty, každý napsaný kód musí být v některé obsažen. Tím se výsledná aplikace v pozdějších fázích lépe udržuje. Vysoká přizpůsobitelnost jakákoliv úroveň životního cyklu může být nahrazena libovolnou jinou, pokud splňuje příslušné kontrakty. Rámec JSF tak například není omezen na generování výstup v HTML a nemusí ke komunikaci ani využívat HTTP protokol. V současné době jsou k dispozici dvě implementace JSF, obě s kompletním přístupem ke zdrojovým kódům referenční implementace od společnosti Sun a Apache MyFaces. Jelikož JSF je standard, je k dispozici celá řada knihoven, které obsahují implementaci nových komponent. Ty lze využít v libovolné aplikaci řídící se standardem JSF. Mezi nejznámější knihovny komponent lze zařadit tyto: RichFaces ICEfaces Velmi časté je obohacení základního standardu JSF o další principy, které ještě více usnadňují tvorbu webových aplikací například možnost využívat k zobrazování dat HTML soubory místo standardních JSP stránek. Mezi nejběžnější rozšíření standardu JSF patří: Facelets JBoss Seam Poměrně často diskutovaným tématem ve spojení se standardem JSF je jeho vysoká výpočetní náročnost. Zajímavé je srovnání Apache MyFaces s rámcem Wicket, které lze nalézt v [JSFVWIC]. Podrobnější informace o standardu Java Server Faces, jeho rysech a možnostech lze nalézt třeba v [JSF]. 14. Zjednodušeně lze vizuální tvorbu webových aplikací přirovnat k WYSIWYG editoru vývojář tvoří uživatelské rozhraní a ihned vidí, jak bude daná stránka vypadat, konkrétní kód pak za něj generuje IDE. 22

30 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Tapestry Dalším zástupcem komponentních webových rámců je Tapestry. Jde o silně objektově orientovaný rámec, který v nejnovější verzi 5 klade důraz především na jednoduchost, snadnost použití a omezení rozsahu neefektivního kódu. Tapestry celou aplikaci vidí jako kolekci stránek a komponent. Stránky jsou šablonami, které definují rozložení dat na stránce, tedy jejich vizuální podobu. Komponenty se starají pouze o funkcionalitu. Komponenty se dále dělí na základní a pomocné. Základní poté poskytují veškerou výkonnou funkcionalitu webové aplikace, jako například validaci formulářů, persistenci objektů či navigaci. Pomocné komponenty definují pravidla, podle kterých mezi sebou mohou komunikovat jednotlivé základní komponenty. Velmi podstatnou výhodou tohoto rámce je fakt, že jako šablony uživatelského rozhraní jednotlivé komponenty typu stránka jsou použity XHTML soubory, nikoliv JSP. Tím se podstatně usnadňuje spolupráce návrháře vzhledu a vývojáře. Vývojář vytvoří postupně sadu XHTML stránek, které využívá k zobrazování dat. Ty poté poskytne návrháři, aby pro ně vytvořil příslušné styly. Návrhář vrátí vývojáři vytvořený CSS styl, který je zakomponován do webové aplikace. Vytvářet CSS styl pro XHTML stánku je podstatně pohodlnější a rychlejší, než pro JSP. Návrhář může používat všechny své oblíbené vizuální nástroje a nemusí se jakkoliv starat o samotnou webovou aplikaci instalovat kontejner, aplikaci na něm nasazovat apod. Krátká ukázka XHTML značkování demonstrující tuto funkcionalitu může vypadat například takto: <table> <tr> <th>first Name</th> <th>last Name</h> </tr> <tr jwcid="loop"> <td><span jwcid="insertfirstname">john</span></td> <td><span jwcid="insertlastname">doe</span></td> </tr> <tr jwcid="$remove$"> <td>frank</td> <td>smith</td> </tr> <tr jwcid="$remove$"> <td>jane</td> <td>jones</td> </tr> </table> Návrhář uvidí při zobrazení tohoto kódu jednoduchou tabulku o dvou sloupcích a třech řádcích, kterou snadno vizuálně upraví podle své libosti. Ve webové aplikaci je však před zobrazením tato tabulka zpracována odlišně. Druhý a třetí řádek (nepočítáme-li v úvahu řádek s nadpisy sloupečků) se nezobrazí a místo prvního řádku se zobrazí postupně všechny 23

31 2.5. WEBOVÉ APLIKAČNÍ RÁMCE záznamy definované komponentou loop tak, že v prvním sloupci se vypíše křestní jméno a ve druhém příjmení. Toho vše je dosaženo pouze vhodným užitím atributu jwcid u jednotlivých značek, případně dalších rámcem rozeznávaných atributů (value, key apod.). Kompletní dokumentaci včetně příkladů použití lze nalézt na webových stránkách uvedených v [TAP] Wicket Wicket je posledním nástrojem zmíněným ve výčtu rámců, které budují webovou aplikaci pomocí komponent. Ten je v mnoha ohledech podobný předešlému rámci Tapestry a tím i filozofii návrhu komponent Swing. K vykreslování komponent do XHTML stránek je také používán speciální atribut. Tím je zachována výhoda tvorby XHTML návrhu v libovolném editoru. Jediným rozdílem oproti Tapestry je fakt, že Wicket má svůj atribut obsažen ve vlastním jmenném prostoru celý se tak typicky uvádí jako wicket:id. Krátký úsek XHTML značkování obsahující vykreslení komponenty Wicket vypadá například následovně: <span wicket:id="message" id="message"> This text will be replaced with actual message </span> Komponenta vykreslující konkrétní zprávu pak může vypadat například takto: package com.my.web.wicket; import org.apache.wicket.markup.html.webpage; import org.apache.wicket.markup.html.basic.label; public class MessagingPage extends WebPage { /** * Constructor */ public MessagingPage() { add(new Label("message", "Hello World!")); } } Hlavní výhodou a podstatnou odlišností rámce Wicket je snaha o kompletní odstínění vývojáře od správy stavu aplikace. Vývojář tak například nikdy nemusí pracovat přímo s objektem typu HttpSession, celá správa stavu aplikace je prováděna v režii samotného rámce. Každá komponenta má svůj vlastní stav, navigační stav celé aplikace je pak držen pro každého uživatele zvlášt v jeho sezení. Vývojář tak vždy pracuje pouze s komponentami vytvořenými v jazyce Java a o vše nezbytné se stará rámec. Toto řešení přináší ještě jednu výhodu rámec Wicket poměrně robustně řeší problém tlačítka Zpět. Sám kontroluje, zda platnost dat na stránce již nevypršela a místo načtení stránky z vyrovnávací paměti provede jejich kompletní obnovení (například z databáze). 24

32 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Zvolený návrh rámce s sebou ovšem přináší větší režii na straně kontejneru někdy se stará o zbytečně mnoho informací, které aplikace třeba vůbec ani nevyužívá. Na druhé straně, v dnešní době je hardware většinou výrazně levnější než práce programátorů, a proto se vyplatí za cenu serverového vybavení snížit náklady na vývoj webové aplikace. Podrobnější informace spolu s odkazy na další zdroje lze nalézt například v [WIC] Rámce založené na akcích V této podkapitole si blíže představíme rámce, které jsou založené na zcela jiné filozofii, než první skupina. Nesnaží se na webovou aplikaci pohlížet jako na sadu komponent, spíše ji vidí jako skupinu obslužných entit, které reagují na jednotlivé HTTP požadavky odesílané uživateli. Jak bylo vysvětleno v podkapitole 2.3.1, komunikace webového prohlížeče a aplikace je založena na odesílání požadavků a navracení odpovědí. Rámce založené na akcích se snaží tento koncept dále rozvinout, jejich hlavní snahou je oprostit vývojáře od nutnosti práce s nízkoúrovňovou obsluhou požadavků se servlety. Mapování jednotlivých požadavků na obslužné entity je opět dosaženo podobně jako u rámců založených na komponentách přidáním servletu či filtru do deployment deskriptoru webové aplikace a jeho vhodným svázáním s tvarem obsluhovaných URL Struts Patrně historicky nejstarším a nejznámějším zástupcem této skupiny rámců jsou Struts. Jejich původ sahá až do května roku 2000, kdy byla uvedena první verze stvořená Craigem McClanahanem. Později projekt přešel pod křídla Apache Software Foundation, kde se v roce 2005 stal jedním z hlavních projektů a dále nesl název Jakarta Struts. V současné době je k dispozici již verze Struts2, která však není přímým nástupcem původního rámce. Tento rámec vznikl přejmenováním projektu WebWork, rovněž z dílny korporace Apache. Častou součástí webové aplikace jsou formuláře. Než vznikly první webové rámce, o obsluhu formulářů se staraly bud servlety, nebo JSP stránky. Vyhodnotily data, případně provedly nějakou interakci s databází a vygenerovaly HTML výstup srozumitelný pro uživatele. Obě metody zpracování velmi často vedly ke spojování aplikační logiky s generováním výstupu. Tomu se pokusil webový rámec Struts udělat rázný konec. Hlavním cílem rámce Struts je vynucení přístupu MVC. Tedy oddělení komponent model, view a controller. Modelem zde jsou všechna doménová data, která se získávají prostřednictvím nižší vrstvy webové aplikace backendu. Tím může být například servisní webová aplikace viz kapitola 2.2. Komponentu view tvoří HTML šablony, nejčastěji JSP stránky (ale i XML či Velocity), které pouze zobrazují poskytnutá data modelu. Součástí komponenty controller je v první řadě třída ActionServlet, která je zaregistrována jako servlet v souboru web.xml a typicky obsluhuje všechny URL končící na.do. Každý požadavek zpracovávaný tímto servletem je poté odeslán ke zpracování konkrétní obslužné třídě. Tyto jsou tvořeny vývojářem webové aplikace a rovněž jsou součástí komponenty controller. 25

33 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Srdcem konfigurace celého rámce je v každé webové aplikaci soubor struts-config.xml, který musí být umístěn ve složce WEB-INF. V tomto konfiguračním souboru se nachází mapování mezi akcemi a obslužnými třídami. Obslužné třídy musejí být potomkem třídy org.apache.struts.action.action a nejčastěji překrývají metodu execute(). Tato je zavolána obslužným servletem při příchodu požadavku určeného pro danou obslužnou třídu. Konkrétní akci lze vyvolat vytvořením požadavku na URL, jejíž část před příponou.do je shodná s názvem akce. V konfiguračním souboru je dále uvedeno, které JSP stránky se mají zobrazit po proběhnutí konkrétních akcí. Také mohou být definovány obslužné třídy pro jednotlivé formuláře form-beans. Konkrétní část souboru struts-config.xml může vypadat například takto: <struts-config>... <form-beans> <form-bean name="userdata" type="com.my.web.struts.userdataform" />... </form-beans> <action-mappings>... <action path="/checkrepairstatus" type="com.my.web.struts.checkstatusaction"> <forward name="finished" path="repair-finished.jsp" /> <forward name="pending" path="repair-pending.jsp" /> </action>... Máme-li v naší webové aplikaci správně nastaven controller pro rámec Struts a jeho konfigurační soubor obsahuje zmíněnou definici, bude se aplikace chovat následovně. Pokud zavoláme URL /checkrepairstatus.do, pak to způsobí vyvolání metody execute() ze třídy com.my.web.struts.checkstatusaction. Ta zkontroluje stav opravy v databázi. Pokud je již předmět opraven, nahrají se z databáze potřebná data (informace o závadě, cena opravy apod.), tato data se nastaví jako atribut HTTP request objektu poskytnutého metodě execute() a metoda vrátí identifikátor finished. Pokud předmět není opraven, vrátí metoda identifikátor pending. Řídící servlet pak podle identifikátoru vráceného metodou předá vyřízení požadavku na stránku repair-finished.jsp nebo repair-pending.jsp. Jak již bylo zmíněno dříve, velmi častým scénářem ve webových aplikacích je vkládání dat pomocí formuláře a jejich následné zpracování. I na tento způsob využití je rámec Struts připraven. Jak bylo napsáno o několik odstavců výše, v souboru struts-config.xml lze definovat komponenty form-beans. Specifikovaná třída je pak určená především k validaci dat. Pokud validace selže, formulář je zobrazen znovu s předvyplněnými daty a zvýrazněním těch položek, které byly vyplněny nesprávně. Pokud validace uspěje, je zavolána metoda execute() ze třídy určené podle postupu popsaného v předešlém odstavci. Ke správnému zobrazování dat ve formulářích je nutné místo běžných HTML značek 26

34 2.5. WEBOVÉ APLIKAČNÍ RÁMCE používat elementy z knihovny značek, která je součástí rámce Struts. Velmi pěkně jsou možnosti rámce Struts shrnuty v [STRFI]. Velkou snahou Struts2 je omezení rozsahu konfigurací v souboru struts-config.xml a užívání anotací u jednotlivých obslužných tříd. U velkých projektů se počet různých akcí může rapidně zvyšovat a konfigurační soubor se tak snadno stává nepřehledným a nesnadno udržovatelným. Rámec taktéž obsahuje podporu pro tvorbu šablon jednotlivých stránek Tiles. Pokud se tedy na nějaké skupině stránek používá stejné rozložení, lze pro ně nadefinovat šablonu a v jednotlivých souborech pak mít pouze kód pro zobrazování obsahu, kterým se jednotlivé stránky odlišují. Tiles používají k definici šablon samostatný soubor nesoucí název tilesdefs.xml, který se nachází ve stejné složce jako struts-config.xml. Kompletní dokumentaci a mnoho příkladů lze nalézt na oficiální stránce projektu odkazované v [STR] Spring Web MVC Webový rámec Spring Web MVC, jak už název napovídá, v mnohém vychází v velmi známého a používaného nástroje Spring. Jeho velkou zbraní je právě možnost jednoduchého a přímočarého napojení na aplikační logiku, pokud je tato implementována pomocí rámce Spring. Mnoho rysů nástroje Spring Web MVC vychází přímo z rámec Spring, proto si tento nejprve ve zkratce přiblížíme. Hlavní motivací, která vedla vývojáře k započetí práce na rámci Spring, bylo poskytnout vývojářům pomocnou ruku v psaní velkých a přesto dobře dekomponovaných webových aplikací. V mnohém se podobá technologii EJB, která si klade za cíl podobné mety. Rámec Spring má však tu výhodu, že je velmi lehký. Není součástí žádného kontejneru, on sám je de facto webovým kontejnerem, protože aplikacím zajišt uje stejné služby. Avšak lze ho přidat ve formě jar archivů k libovolné aplikací (at webové či desktopové) a aplikace může plně využívat jeho služeb. Mezi služby poskytované rámcem Spring patří zejména tyto: Inversion of Control o závislosti mezi třídami se nestarají třídy samotné, ale externí komponenta, která instanci třídy vždy poskytne všechny implementace služeb, na kterých je třída závislá. Tento princip vystihuje anglická fráze Don t call us, we will call you. Více o tomto přístupu k budování aplikací viz [IOC]. Aspect-oriented programming snaha o rozvinutí objektově orientovaného programování směrem k dalšímu striktnímu oddělení jednotlivých částí aplikace a jejich centrální správy. Více informací o tomto novém paradigmatu lze nalézt například v [AOP]. Přístup k datům rámec umožňuje v průběhu tvorby aplikace měnit typ napojení na databázi. Je tak možné plynule přejít od JBDC k JDO a později k implementaci pomocí Hibernate. 27

35 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Řízení transakcí Spring sjednocuje jednotlivá API a stará se o vykonávání transakčních operací nad jednotlivými objekty jazyka Java. Autentizace a autorizace rámec poskytuje konfigurovatelný a vynutitelný nástroj na správu uživatelských identit a jednotlivých oprávnění. Podpora pro testování Spring poskytuje řadu možností, jak aplikaci testovat, například pomocí nástrojů JUnit či TestNG. Ačkoliv byl v seznamu bod podpora pro testování uveden až jako poslední, právě nutnost důkladně testovat aplikace se stává čím dál důležitější. Zřejmě není třeba zdůrazňovat význam známého pravidla, které říká, že čím dříve se v aplikaci chyba objeví, tím snadnější a lacinější je ji opravit. A právě možnost pohodné tvorby a spouštění jednotlivých testů mimo kontejner (kterým je například GlassFish) dělá z rámce Spring zdatného konkurenta technologii EJB. Nyní již se budeme zabývat podmnožinou rámce Spring, který se stará o vhodnou dekompozici prezenční části webové aplikace. Celá práce webového rámce Spring Web MVC je soustředěna kolem dvou bodů webové aplikace. Prvním je servlet DispatcherServlet z balíku org.springframework.web.servlet, který je nutno přidat do deployment deskriptoru a namapovat na požadovaný tvar URL, podobně jako je tomu u rámce Struts. Druhým stěžejním bodem je XML deskriptor (nejčastěji pojmenovaný spring-servlet.xml), který obsahuje deklaraci všech tříd potřebných pro obsluhu jednotlivých požadavků. Syntaxe konfiguračního souboru je převzata z rámce Spring, obsahuje kolekci elementů bean, u kterých je vždy deklarován jejich jedinečný název v rámci celé aplikace. U jednotlivých bean elementů může být deklarováno, jaké jiné bean instance mají být při vytvoření do daného objektu injektovány. Tím je velmi snadno a přehledně zrealizován princip Inversion of Control popsaný výše. V tomto konfiguračním souboru se lze odkazovat na libovolné bean instance z jiných konfiguračních souborů rámce Spring. Do třídy obsluhující HTTP požadavek se tak typicky injektují vždy implementace jednotlivých servisních tříd, které jsou potřeba k obsluze daného požadavku (například uložení položky do databáze) a byly deklarovány jako bean instance v konfiguračním souboru rámce Spring v aplikační části webové aplikace. V konfiguračním souboru webového rámce Spring Web MVC lze rozlišit tyto významné elementy: Controller jde o třídy napsané vývojářem webové aplikace, které obsluhují určitou podskupinu požadavků. Handler mapping jsou deklarace podmínek, za kterých bude pro obsluhu požadavku použit daný controller. Vymezující podmínkou může být například tvar URL nebo hodnota nějakého parametru. View resolver tyto elementy zabezpečují mapování názvů komponent view na konkrétní soubory (například JSP stránky nebo šablony Velocity). 28

36 2.5. WEBOVÉ APLIKAČNÍ RÁMCE Locale resolver starají se o volbu jazyka uživatelského rozhraní. Theme resolver jejich úkolem je práce s různými vzhledy webové aplikace, pokud jich tato poskytuje více. Multipart file resolver slouží k obsluze požadavků obsahujících binární data ze souborů nahraných na server pomocí HTML formuláře. Handler exception resolver stará se o obsluhu výjimek vzniklých ve webové aplikaci. Rámec taktéž disponuje podporou pro zjednodušenou obsluhu formulářových dat a jejich validaci, tvorbu formulářů tvořených více stránkami a podobně. Nemalou výhodou je rovněž fakt, že tento webový rámec má svou variantu i pro čím dál více rozšířené portálové aplikace 15. Vývojář znalý rámce Spring Web MVC tak může s téměř nulovou režií přejít na Spring Portlet MVC a tvořit, stejným postupem jako dosud, portálové aplikace. 15 Velkou devizou celého projektu Spring je rozsáhlá a velmi kvalitní dokumentace, která obsahuje spoustu příkladů s konkrétním využitím jednotlivých rysů rámce. Nejlepším zdrojem informací pro kompletní referenci o rámci Spring Web MVC jsou kapitoly z oficiální dokumentace uvedené v [SPRING]. 15. Portálovou aplikací je míněna webové aplikace podle JSR 168 či 286, více viz například [PORT]. 29

37 Kapitola 3 Rámec Stripes Jedním ze zástupců skupiny webových rámců, které jsou založené na akcích, je rámec Stripes. Jeho hlavním cílem je snaha o co největší zjednodušení tvorby webových aplikací na platformě Java. Funkcionalita a koncepty zavedené rámcem již nejsou v současné době zcela unikátní, protože řadu povedeních rysů převzaly ostatní nástroje včetně rámců Struts či Spring Web MVC zmíněných v předešlé kapitole. Stále však jde o živý projekt, který má své zastánce a neustále se vyvíjí a zdokonaluje. Rámec se snaží držet krok s nejnovějšími technologiemi zaváděnými do platformy Java. Mezi ně v počátcích jeho návrhu (rok 2005) patřilo poskytování meta informací ve formě anotací a užívání generických typů, které v jazyce Java přibyly od jeho verze 5.0. Rámec si také vzal za příklad některé rysy populárního prostředí Ruby on Rails, především přístup convention-over-configuration. Jeho princip bude vysvětlen a ilustrován dále. Jedním z hlavních odlišností od ostatních rámců je fakt, že není třeba používat žádný XML deskriptor pro konfiguraci rámce ve webové aplikaci (pokud pomineme nezbytnou definici servletu případně filtru v souboru web.xml). Jako konfigurace slouží pouze soubor anotací, které jsou specifikovány u jednotlivých obslužných tříd action bean objektů. Navíc je uplatňován přístup convention-over-configuration, tedy pokud není nějaké nastavení specifikováno, použije se automaticky vhodná výchozí hodnota. V některé literatuře lze tento princip najít i pod názvem configuration-by-exception. Příkladem může být která slouží u action bean třídy k nastavení URL, kterou bude daná třída obsluhovat. Pokud tato anotace chybí, pak třída obsluhuje URL vytvořenou kombinací části názvu balíku a třídy třída com.my.web.action.auth.useractionbean tak bude namapována na URL /auth/user.action. Nejnovější stabilní verze rámce nese označení a byla vydána v březnu roku 2009, velmi rozšířená a používaná je i předešlá verze Hlavní koncepty rámce Stripes Základním stavebním kamenem webové aplikace, která využívá rámec Stripes, jsou prosté třídy Java, které musí pouze implementovat předepsané rozhraní ActionBean z balíku net.sourceforge.stripes.action. Tento fakt umožňuje, aby vytvořené třídy mohly dědit funkcionalitu z libovolné jiné třídy a vývojář nebyl nijak omezován co se objektového návrhu týče. Nyní si toto rozhraní a návrh jeho implementací blíže popíšeme. 30

38 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES Action beans Rozhraní ActionBean má pouze dvě metody, které je nutno implementovat: public ActionBeanContext getcontext(); public void setcontext(actionbeancontext ctx); Metoda setcontext() je zavolána rámcem pokaždé při vytváření action bean instance a daný parametr typu ActionBeanContext je naplněn daty, která se dají použít k mnoha účelům. Jeho prostřednictvím má action bean třída přístup k HTTP request či response objektu a tím i k HTTP sezení. Obecně by měl být tento objekt centrálním vstupním bodem ke všem datům, která popisují, v jakém stavu se aplikace aktuálně nachází Fáze životního cyklu požadavku Rámec Stripes má velmi dobře oddělené jednotlivé fáze zpracování HTTP požadavku. Od jeho příchodu ke controlleru až po přesměrování na nějakou komponentu view. Při příchodu požadavku je rozlišováno těchto šest fází: 1. ActionBeanResolution rámec v prvním kroku rozhodne, jakou action bean instanci použije pro obsluhu požadavku a vytvoří instanci příslušné třídy. 2. HandlerResolution zde je zjištěna konkrétní akce, která se vykoná, a určena metoda obslužné třídy, která tuto akci reprezentuje. 3. BindingAndValidation ve třetí fázi se mapují parametry požadavku do jednotlivých atributů obslužné třídy a rovněž je provedena validace dat specifikovaná anotacemi (viz dále). 4. CustomValidation v dalším kroku je zavolána validační metoda, pokud vývojář tuto v action bean instanci určil (bude vysvětleno dále). 5. EventHandling v této fázi je vykonána metoda, která byla vybrána ve druhém kroku k obsluze požadavku. 6. ResolutionExecution poslední krok je vykonán vždy, provádí se v něm předání požadavku na příslušnou komponentu view. Ta je specifikována bud objektem typu Resolution, který vrátila provedená metoda akce, nebo je jí zdrojová stránka, pokud například selhala validace dat a uživatel má být přesměrován zpět na původní stránku pro jejich opětovné zadání. Ne všechny fáze jsou pro každý požadavek vykonány. Jak již bylo uvedeno, pokud se například vyskytnou validační chyby, požadavek je přesměrován na původní stránku (nejčastěji se znovu zobrazí formulář a v něm se vyznačí chybně zadaná data). Tím je například zcela vynechána pátá fáze. 31

39 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES Pomocí anotací lze také specifikovat, že pro danou akci se má vynechat například fáze validace dat. Autor jednotlivých action bean instancí má jednoduchou možnost, jak nějaký úsek kódu vykonat přesně v daný okamžik, například před či po některé fázi zpracování požadavku. Toho lze docílit připojením k libovolné metodě action bean instance a specifikováním požadované fáze. V dalších kapitolách si postupně rozebereme některé zajímavé fáze a popíšeme si jejich princip Určení action bean instance Stejně jako u Struts či Spring Web MVC, i pro Stripes je nutno jednotlivé požadavky rozdělit podle nějakého kritéria a jejich obsluhu pak směrovat na jednotlivé action bean instance. U těchto je možné deklarovat která vyžaduje pouze parametr value typu String. Jeho obsahem je vzor absolutních URL (vzhledem ke kontextu webové aplikace) jejichž požadavky bude třída obsluhovat. Anotace může tak vypadat třeba public class UserActionBean implements ActionBean {... } Pokud je pro mapování požadavků použit nový DynamicMappingFilter (viz následující podkapitola 3.1.2), lze použít i složitější public class UserActionBean implements ActionBean {... } Mezi složené závorky ({})je možné uvést názvy atributů, které mohou být součástí URL. Speciálním řetězcem je {$event}, který bude nahrazen konkrétní akcí vyvolanou v této třídě. Uvedený zápis tak znamená, že tato třída má obsluhovat URL /user/save/101. Pro tuto URL pak bude vyvolána akce save a do atributu id atributu user dané action bean instance bude nastaveno číslo 101. Detailněji budou akce a automatické vázání parametrů rozebrány v následující podkapitolách a Více o podporovaném formátu lze najít v dokumentaci API uvedené jako zdroj v [STRDOC]. Korektní URL pro danou action bean instanci jsou v JSP stránkách tvořeny pomocí dodávané knihovny značek, více viz podkapitola Stripes tak vývojáři umožňuje velmi pohodlně používat hezké URL i pro obsluhu jednotlivých akcí. To je velmi výhodné pro SEO, jak bylo popsáno v podkapitole Volba vyvolané akce Jak již bylo zmíněno, v rámci jedné action bean instance je dále možné rozlišovat jednotlivé akce. Tyto jsou identifikovány svým názvem a reprezentovány metodou. Akcí může 32

40 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES být libovolná veřejná metoda, jejímž návratovým typem je objekt implementující rozhraní Resolution. Tedy public Resolution saveuser() {... } return new ForwardResolution("/user-detail.jsp"); Jak je v příkladu vidět, u této metody je specifikována která pojí tuto metodu s názvem akce, kterou reprezentuje. Pokud by tato anotace nebyla uvedena, za název akce by byl brán název metody, tedy řetězec saveuser. Toto automatické chování je další ukázkou principu convention-over-configuration, uplatňovaným rámcem Stripes. U jedné z metod reprezentujících akce může být uvedena Pokud pak požadavek na tuto action bean instanci neobsahuje určení konkrétní akce, která se má provést, je vykonána právě takto specifikovaná akce. Na návratové hodnotě uvedené metody je také vidět, jakým způsobem se po vykonání akce předává řízení dále. V tomto případě je požadavek přesměrován na JSP stránku, která vypíše detaily aktuální uživatele a zobrazí informační zprávu, zda byly nové hodnoty uloženy. Rámec Stripes obsahuje několik implementací rozhraní Resolution, které pokrývají nejběžnější scénáře použití: ForwardResolution přesměruje požadavek na danou URL; RedirectResolution přepošle požadavek na uvedenou adresu; StreamingResolution slouží k poskytnutí XML dat pro AJAX či pro generování dynamických obrázků; ErrorResolution vrátí jako výsledek HTTP chybu s daným kódem. Vývojář může rovněž využívat libovolnou vlastní implementaci rozhraní Resolution, pokud vyhodnotí její použití jako nejvhodnější Vázání parametrů z požadavku Velmi užitečným nástrojem, který rámec Stripes nabízí, je automatické vázaní parametrů požadavku do atributů action bean instance. Typický případ může vypadat takto: public class User { private Long id; private String login; private String name; private BigDecimal interestrate; 33

41 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES }... // get and set methods for all attributes public class UserActionBean implements ActionBean { private int count; public int getcount() { return this.count; } public void setcount(int count) { this.count = count; } private User user; public User getuser() { return this.user; } public void setuser(user user) { this.user = user; } }... Typ User musí být správně utvořený Java Bean, tedy především mít bezparametrický konstruktor a rovněž set a get metody pro všechny svoje atributy. Před zavoláním libovolné akce provede rámec Stripes pokus o naplnění všech atributů dané action bean instance (v našem příkladu tedy atributů user a count): pokud je typ atributu primitivní (String, long, int...): 1. v HTTP požadavku se hledá parametr s názvem odpovídajícím danému atributu, pokud je nalezen, nastaví se jeho hodnota například následujícím způsobem: Integer count = Integer.valueOf(request.getParameter("count")); bean.setcount(count); pokud typ atributu není primitivní: 1. inicializuje se daný atribut, tedy například se zavolá metoda: bean.setuser(new User()); 2. v HTTP požadavku se hledají parametry, jejichž název začíná názvem daného atributu, pro atribut user jsou tedy hledány parametry user.id, user.name a další; 3. pokud jsou tyto parametry nalezeny, pro každý se spustí opakování celého tohoto postupu rekurzivně od začátku. Jak je z popsaného postupu vidět, rámec je schopných nastavit atributy action bean instance i do hloubky, daný algoritmus je spuštěn rekurzivně na již nalezených atributech. 34

42 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES Rámec se taktéž stará o nezbytné přetypování hodnot jednotlivých parametrů (hodnoty HTTP parametrů jsou vždy typu String). Pomocí anotace lze rovněž určit konvertor, který bude pro převod parametru z typu String na objekt použit. Rámec obsahuje implementace více jak 15 konvertorů, například pro všechny primitivní typy jazyka Java, navíc třeba DateTypeConverter, PercentageTypeConverter či EnumeratedTypeConverter. Vázání atributů z parametrů požadavku je velmi těsně spojeno s jejich validací, dokonce se tyto dvě činnosti provádějí v rámci jedné fáze. Princip validace bude přiblížen v následující podkapitole Validace dat Velmi užitečným nástrojem, který rámec Stripes nabízí, je validace formulářových dat. Největší odlišností od validačních systémů v rámcích Struts či Spring Web MVC je jeho deklarativní charakter. A jistě nebude překvapením, že validaci dat lze nastavit pomocí anotací přímo v třídě action bean instance. Základním deklarativním nástrojem sloužícím k ověření integrity vložených dat je Ta slouží k ověření jedné konkrétní hodnoty. Ke specifikování souběžné validace pro více atributů stačí zahrnout danou množinu do jedné a tuto připojit v action bean instanci před deklaraci atributu nebo jeho set metody. Pro nastavení konkrétního chování validace slouží jednotlivé atributy obsažené v uvedeme si zde pouze ty nejpoužívanější: field název atributu, na který má být validace uplatněna; required pokud má hodnotu true, je nutné danou položku ve formuláři vyplnit; on seznam názvů akcí, při kterých bude validace provedena. Pokud je seznam prázdný nebo není pole u anotace uvedeno, provede se validace vždy; maxlength, minlength udává maximální (resp. minimální) povolenou délku vstupního řetězce; maxvalue, minvalue specifikuje maximální (resp. minimální) povolenou numerickou hodnotu daného atributu; expression v tomto poli je možno uvést výraz jazyka Expression Language, který bude pro daný atribut vyhodnocen; mask zde je možno zadat regulární výraz, kterému musí daný vstupní řetězec vyhovovat; converter hodnotou tohoto pole lze určit, která třída má sloužit jako konvertor z textového řetězce do objektu. 35

43 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES Pro ilustraci aspoň části možností uvedeme jednoduchý příklad z praxe. Uvažme situaci, kdy chceme evidovat zákazníky banky. U každého zákazníka chceme uchovávat pouze jeho id, login pro přihlášení, celé jméno a míru úroku pro poskytnutí hypotéky viz ukázka kódu v předchozí kapitole Příklad deklarativně zadané validace může vypadat například takto: public class UserActionBean implements required=false, required=true, minlength=5, required=true, minlength=3, maxlength=100, mask="\\w on={"grantmortgage"}, required=true, converter=percentagetypeconverter.class) } ) private User user; public User getuser() { return user; } public void setuser(user user) { this.user = user; } public Resolution grantmortgage() {... } }... Pokud vývojář přesto zjistí, že dané anotace neposkytují dostatečnou sílu k provedení jeho validací, lze v action bean instanci určit pomocí libovolnou metodu, která bude automaticky rámcem zavolána k validaci dat. Tato metoda se vždy volá až po provedení všech deklarativně specifikovaných validací Obsluha požadavků Jediným nastavením, které je potřeba před používáním rámce provést, je deklarování servletu (respektive filtru), který bude jednotlivé HTTP požadavky mapovat na vývojářem vytvořené třídy action bean instance. Existují dvě možnosti, jak tuto konfiguraci provést Statické mapování požadavků První možností je deklarovat servlet StripesDispatcher a filtr StripesFilter. 36

44 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES StripesFilter při své inicializaci (která je spuštěna při nasazení aplikace do kontejneru) najde všechny obslužné třídy specifikované pomocí hodnoty inicializačního parametru ActionResolver.Packages v dané webové aplikaci a shromáždí jejich konfiguraci poskytnutou formou anotací specifikovaných k kódu třídy. StripesDispatcher pak již podle dostupné konfigurace odbavuje jednotlivé HTTP požadavky a směruje je na jednotlivé přítomné action bean instance podle URL, na kterou jsou mapovány. Úplnou ilustraci tohoto případu konfigurace lze najít v podkapitole Dynamické mapování pomocí DynamicMappingFilter Druhým způsobem, jak korektní mapovaní URL zajistit, je deklarovat dva filtry. Tento způsob byl do rámce Stripes přidán ve verzi 1.5. Prvním povinným filtrem je StripesFilter, jehož účel je shodný s předešlým případem. Druhým nezbytným úkonem je deklarování filtru DynamicMappingFilter, který plní stejnou funkci jako StripesDispatcher, avšak jinými prostředky. Pro tento dynamický filtr také platí další dvě omezující podmínky, co se konfigurace týče: Tento filtr musí být mapován pomocí hodnoty /*, tedy musí být aplikován na veškeré požadavky přicházející do webové aplikace. Filtr musí být posledním aplikovaným filtrem. Pokud se mu totiž podaří úspěšně namapovat požadavek na některou action bean instanci, jakékoliv následné filtry jsou již ze zpracování požadavku vyřazeny. Úsek správné deklarace filtru DynamicMappingFilter v souboru web.xml tak vypadá následovně: <filter> <display-name>stripes Dynamic Mapping Filter</display-name> <filter-name>dynamicmappingfilter</filter-name> <filter-class>net.sourceforge.stripes.controller.dynamicmappingfilter </filter-class> </filter> <filter-mapping> <filter-name>dynamicmappingfilter</filter-name> <url-pattern>/*</url-pattern> <dispatcher>request</dispatcher> <dispatcher>forward</dispatcher> <dispatcher>include</dispatcher> </filter-mapping> <!-- end of filters declarations --> 37

45 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES Knihovna značek Stripes Ačkoliv je možné jako komponentu view rámce Stripes používat i Velocity šablony, pohodlnější je pracovat s JSP. Pro ně totiž vývojáři rámce Stripes připravili velmi užitečnou knihovnu značek. Jednotlivé značky kompletně pokrývají funkcionalitu co se tvorby HTML formulářů týče, názvy elementů jsou pro snadné zapamatování shodné, pouze pocházejí z jiného jmenného prostotu a nabízejí deklaraci atributů pro konfiguraci chování v rámci Stripes. Navíc tato knihovna obsahuje značky pro formování rozložení jednotlivých stránek či zobrazení informačních zpráv uživatelům. Aby bylo v následujícím textu zřejmé, že daný element je z jmenného prostoru Stripes, bude vždy uváděn s prefixem s. Běžné HTML elementy budou uváděny bez prefixu Značky pro tvorbu formulářů Základní značkou je <s:form>, která slouží, stejně jako její ekvivalent v HMTL, k ohraničení všech elementů, které obsahuje formulář. Ke správné obsluze formuláře je nutné zadat bud URL nějaké action bean instance, nebo což je preferovaná volba vyplnit prostřednictvím atributu beanclass plně kvalifikované jméno této instance, tedy název třídy včetně balíku. Knihovna značek pak správnou URL vyplní automaticky, například podle dané třídy. Knihovna dále obsahuje ekvivalent všech známých ovládacích prvků jazyka HTML: textová pole, drop-down menu, zaškrtávací položky, tlačítka a další. Značky se však ve formuláři navíc zobrazují v závislosti na stavu aplikace. Například značka <s:text> (ekvivalent <input type="text"/>) zobrazí obsah atributu daného názvu příslušné action bean instance, která je svázána z daným formulářem. Pokud byla zadána neplatná hodnota tohoto atributu, bude tato značka vykreslená s CSS třídou signalizující problém (například bude mít červené ohraničení). Podle doporučení mnohých webových standardů by se k popiskám jednotlivých formulářových polí mělo využívat výhradně značky <label>, především z důvodu jednotnosti a přístupnosti i pro postižené uživatele. S tímto počítá i rámec Stripes a obsahuje ekvivalentní značku <s:label>, která vygeneruje nejen standardní HTML popisek, ale navíc se pokusí i vyhledat svůj vlastní text podle atributu for, tedy podle identifikátoru atributu, pro který je popisek určen. Toto chování bude ilustrováno na příkladu uvedeném v následujících odstavcích. Velmi užitečně rámec řeší generování drop-down seznamů (ukázka viz obrázek 3.1). Pro vygenerování takového menu ve webovém prohlížeči je nutno vytvořit následující úsek HTML značkování: <label for="color">vaše oblíbená barva:</label> <select name="colorid" id="color"> <option value="1">červená</option> <option value="2">modrá</option> <option value="3">černá</option> 38

46 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES Obrázek 3.1: Drop-down menu <option value="4">bílá</option> </select> S knihovnou značek Stripes se stejného výsledku dosáhne pomocí značek <s:label>, <s:select> a <s:options-collection>: <s:label for="color" name="color.id"/> <s:select name="color.id" id="color"> <s:options-collection collection="${availablecolors}" value="id" label="name" /> </s:select> Značka <s:label> nejprve dohledá svůj text podle atributu name v ResourceBundle balíku rámce Stripes 1. Poté se vygeneruje daný ovládací prvek iterací přes prvky kolekce availablecolors. Pro každou položku se jako její hodnota, tedy obsah parametru color.id odeslaný v požadavku po vyplnění formuláře, doplní hodnota atributu id a jako textový popisek hodnota atributu name. 1 Rámec obsahuje podobné značky i pro iteraci přes kolekci typu Map a výčet hodnot Enum. Pro vypsání seznamu položek tedy není nutné používat značku <c:foreach> zahrnutou v knihovně JSTL 2, která slouží k iteraci přes libovolnou kolekci či pole hodnot Ostatní značky Velmi užitečným nástrojem jsou značky vypisující informační případně chybové zprávy připojené k odpovědi na aktuální požadavek. O jejich zobrazení se stará dvojice značek <s:messages /> a <s:errors />. Zprávy se mohou na seznam k zobrazení dostat dvojím způsobem: Vloží je automaticky rámec, například pokud selže některá validace specifikovaná 1. ResourceBundle balík rámce Stripes se podle Java standardu načítá ze souboru s názvem StripesResources.properties umístěném v kořenovém balíku (default package) webové aplikace. Pomocí přípon může obsahovat lokalizované klíče pro nejrůznější jazyky a státy. Více o práci s ResourceBundle lze nalézt v [RBNDL]. 2. Knihovna JSTL Java Server Pages Standard Tag Library byla podrobněji přiblížena v předešlé kapitole v části

47 3.1. HLAVNÍ KONCEPTY RÁMCE STRIPES Jsou přidány v metodě obsluhující vyvolanou akci. Zprávy, jak informační tak chybové, jsou vždy přístupné přes kontext action bean instance a přidat je lze tímto jednoduchým způsobem: getcontext().getmessages().add( new LocalizableMessage("mortgage-granted", getuser().name)); getcontext().getvalidationerrors().addglobalerror( new LocalizableError("mortgage-not-granted", getuser().name)); Zprávy musí být pod příslušnými klíči umístěny do ResourceBundle balíku rámce Stripes Možnosti tvorby šablon Často v aplikaci narazíme na problém, že jednotlivé JSP stránky jsou složeny z více částí (hlavička, menu, obsah, patička), z nichž některé zůstávají vždy stejné. Proto je výhodné využít nějaký systém šablon, který přidávání nových stránek oprostí od zbytečného kopírování již vytvořeného kódu. Ve webové aplikaci spolupracující s rámcem Stripes lze k tomu účelu úspěšně využít značek <s:layout-definition>, <s:layout-render> a <s:layout-component>. K fungování není třeba žádný konfigurační soubor, i samotná šablona je pouhou JSP stránkou. Příklad jednoduché šablony může vypadat následovně: <s:layout-definition> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " <html> <head>... </head> <body> <div id="header">${pagename}</div> <div id="menu"> <ul>... </ul> </div> <div id="content"> <s:layout-component name="content"/> </div> <div id="footer"> Josef Sustacek</div> </body> </html> 40

48 3.2. SHRNUTÍ KONCEPTŮ A VÝHOD UŽITÍ Pro použití této šablony pak stačí vytvořit novou JSP stránku a celý vypisovaný obsah zahrnout do těla značky <s:layout-render name="path">, kde místo řetězce path je uvedena absolutní cesta k souboru se šablonou (například /WEB-INF/layout/layoutdefinition.jsp). Aby byl v šabloně správně nahrazen obsah jednotlivých částí, je nutné tento obsáhnout ve značkách tvaru:... <s:layout-component name="content"> The content of first JSP page. </s:layout-component>... V těle šablony je možno užívat pomocí Expression Language odkazy na proměnné, které budou specifické pro každou stránku. V našem příkladu je to ${pagename}, čímž vkládáme do hlavičky název stránky. Při využití šablony je pak možné specifikovat libovolný počet atributů (ve značce <s:layout-render>), které jsou poté v těle šablony přístupné a vygenerují příslušnou hodnotu předanou při využití šablony. 3.2 Shrnutí konceptů a výhod užití Rámec Stripes bezesporu nemusí být pro každou webovou aplikaci nejvhodnějším řešením, přesto přichází z řadou konceptů, které jsou postupně přebírány i jinými webovými rámci. Mezi klíčové charakteristiky rámce patří tyto vlastnosti: žádné konfigurační soubory vše je konfigurováno pomocí nástrojů jazyka Java (především anotací); convention-over-configuration pokud není nějaká hodnota nastavení uvedena, je automaticky doplněna vhodná výchozí hodnota; návrh podporující rozšiřitelnost jestliže narazí vývojář na problém a rámec ho nedokáže vyřešit, má možnost naprogramovat vlastní rozšíření a instruovat rámec, aby ho využíval; projekt je živý na projektu se stále pracuje, přibývá nová funkcionalita a opravují se chyby, aby byl rámec schopen držet krok s nejnovějšími technologiemi. Velmi dobrým zdrojem dalších informací jsou oficiální stránky projektu Stripes, které jsou odkazované v [STRSITE]. Ty byly také použity jako hlavní pramen pro tuto kapitolu, vedle výukových materiálů pro předmět PA165 vyučovaný na Fakultě informatiky MU, viz [STRIPESFI]. 41

49 Kapitola 4 NetBeans RCP NetBeans Platform je generický rámec pro tvorbu desktopových aplikací v jazyce Java. Ve svém jádru používá mnoho konceptů a komponent základního nástroje pro tvorbu uživatelského rozhraní rámce Swing. Jeho hlavním záměrem je poskytnout vývojářům nových aplikací bohatou sadu již připravených nástrojů, které řeší funkcionalitu, jež musí být součástí každé desktopové aplikace. Mezi ty patří například: persistence stavu aplikace; propojení položek v menu se spuštěním jednotlivých akcí; konfigurovatelné nástrojové lišty; správa klávesových zkratek; jednotný přístup k nastavením celé aplikace; správa jednotlivých oken aplikace a jejich částí. Vývojáři je také nabídnuta časem prověřená architektura, která je modulární a podporuje tak tvorbu a dynamické přidávání nových zásuvných modulů do již existující aplikace. Zřejmě nejznámější aplikací založené na této platformě je NetBeans IDE, komplexní vývojové prostředí pro nejrůznější programovací jazyky. Původně bylo uzpůsobeno především pro vývoj v jazyce Java, což zahrnovalo podporu jak pro standardní edici SE, tak i ME určenou pro mobilní telefony či EE, zaměřenou na tvorbu rozsáhlých enterprise aplikací. Postupně však přibyla podpora i pro další programovací jazyky a v současné verzi NetBeans IDE 6.5 je možné tvořit aplikace v C/C++, PHP, JavaScriptu, Ruby, Groovy či Pythonu. Díky dobře navržené architektuře si každý vývojář může sestavit IDE přesně podle svých představ a zahrnout do něj pouze ty moduly, které bude využívat. Při změně zaměření není problém nepoužívané moduly odstranit a přidat libovolné nové. Historie NetBeans se začala psát roku 1997, kdy studenti MFF UK v Praze odstartovali práci na projektu Xelfi. V následujících letech založili členové týmu společnost, která se zabývala tvorbou placené verze vývojového prostředí NetBeans IDE. S rokem 1999 přišla významná a pro další budoucnost NetBeans klíčová událost veškerá práva koupila společnost Sun Microsystems. Tím dostal celý projekt možnost dále se rozvíjet pod křídly velké nadnárodní společnosti, která se na přelomu tisíciletí rozhodla distribuovat zdrojové 42

50 4.1. API POUŽITÁ PRO TVORBU NOVÉHO MODULU kódy jako open-source aktuálně pod licencí Common Development and Distribution License (viz [CDDL]). Tím se také začala kolem projektu NetBeans formovat komunita, která je v současné době již velmi početná a společně s vývojáři firmy Sun se stará o stálý rozvoj celé platformy. Srdcem konfigurace každého modulu je soubor layer.xml. V tomto deskriptoru je specifikováno, zda modul zavádí nové typy souborů, přidává nové položky v menu, přináší další typy projektů, se kterým lze pracovat, a podobně. Celý modul má po svém vytvoření formu jednoho souboru s příponou nbm jde o běžný archiv vytvořený algoritmem ZIP. Má přesně danou strukturu, obsahuje jar archiv se všemi třídami vytvořenými v rámci modulu a v souboru MANIFEST.MF pak reference na všechna NetBeans API použitá při tvorbě modulu. NetBeans IDE poskytuje poměrně bohatou škálu nástrojů podporujících tvorbu nových modulů. Vývojář se tak může soustředit pouze na funkcionalitu samotného modulu a vývojové prostředí za něj zařídí správné vytvoření výsledného archivu i doplnění všech použitých referencí. Popis celé platformy by vydal na několik diplomových prací, proto zde bude uveden pouze krátký popis těch API, která byla využita pro tvorbu zásuvného modulu, o kterém pojednává tato práce. 4.1 API použitá pro tvorbu nového modulu Pro tvorbu modulu bylo celkem využito služeb 23 aplikačních rozhraní z palety nabízené platformou NetBeans, následující seznam tedy není vyčerpávající. Obsahuje však všechny stěžejní komponenty a účel jejich využití při implementaci modulu Nodes API Prvním rozhraním zmíněným ve výčtu je Nodes API. Je základním stavebním kamenem jakékoliv aplikace založené na platformě NetBeans, protože se stará o vizualizaci veškerých objektů v aplikaci. Každý objekt je obalen jednotlivými aspekty (vlastnostmi), které jsou poté užívány pro jejich zobrazení a dohromady tvoří uzel node. Mezi ně patří například název, zobrazený název, sada nastavení, hierarchie poduzlů nebo sada souborů, které mají být použity jako ikony reprezentující daný objekt v menu. Jakmile je pro nějaký objekt vytvořen jeho uzel, je možno začít tento objekt zobrazovat v nejrůznějších komponentách seznamech, stromech či tabulkách. Architektura Nodes API je v mnohém rozšířením konceptu JavaBeans přidává do něj aspekty nezbytné pro pohodlné využívání uzlů v jednotlivých pohledech. V implementovaném modulu je toto API používáno napříč celou architekturou. Jak již bylo řečeno, jde o stěžejní komponentu platformy NetBeans, bez které se neobejde téměř žádná aplikace vizualizující nějaké objekty. 43

51 4.1.2 Filesystems API, Datasystems API 4.1. API POUŽITÁ PRO TVORBU NOVÉHO MODULU Další dvě rozhraní spolu velmi úzce souvisí Datasystems API je postaveno nad Filesystems API. Nejprve si tedy řekneme, k čemu slouží a co přináší Filesystems API a poté navážeme diskuzí, co vše lze získat prostřednictvím Datasystems API. Filesystems API poskytuje jednotnou abstrakci nad libovolným souborovým systémem. Vývojář se nemusí starat o odlišnosti mezi jednotlivými specifikacemi a operačními systémy, k souboru vždy přistupuje přes jednotné rozhraní, at jde o NTFS, EXT-3, ZFS či JAR archiv. Základní třídou tohoto rozhraní je FileObject. Ten reprezentuje jeden objekt na disku bud soubor nebo složku. K daném objektu poskytuje odpovídající FileObject základní informace jako název, rodičovský objekt či informaci, zda objekt fyzicky existuje. Dále tato třída zpřístupňuje esenciální operace potřebné k manipulaci s objekty přejmenování, smazání, přesunutí, kopírování a další. Datasystems API, jak již bylo zmíněno, staví na předešlém rozhraní. Pomocí něj je možné každému objektu či složce přidat složitější logické atributy a provádět nad ním sofistikovanější operace například vytvoření souboru na základě šablony a poskytnutých parametrů, které jsou vyhodnoceny a vloženy do výsledného souboru. Podobně jako v předchozím API i zde lze rozeznat jednu klíčovou třídu DataObject. Avšak již neplatí rovnost jako v případě Filesystems API, kde jeden soubor na disku reprezentoval vždy jeden FileObject. Jeden DataObject může reprezentovat i kolekci více instancí typu FileObject. Příkladem je například zdrojový soubor pro jazyk Java. Ten je vždy reprezentován jak textovým souborem s příponou.java, tak souborem s příponou.class obsahujícím přeložený byte kód. Pro každý jednotlivý DataObject však existuje vždy jednoznačně specifikovaný primární FileObject v našem příkladě je jím textový soubor z příponou.java. Obě API jsou v modelu využívána pro veškeré operace se soubory například čtení obsahu deployment deskriptoru, již zmíněné vytváření souborů že šablon či hledání zdrojových souborů vytvořených vývojářem v daném projektu Window System API Každá desktopová aplikace, která má grafické rozhraní, se skládá z jednoho či více oken. O jejich správu se v prostředí platformy NetBeans stará Window System API. Celé rozhraní je vystavěno nad třídou TopComponent, která je rozšířením jedné z komponent rámce Swing třídy JComponent. Reprezentuje vizuální jednotku, která může být v NetBeans zobrazena a lze v ní vizualizovat nějaká data. Takovou komponentou může být například celé okno aplikace či ji může reprezentovat jedna záložka tvořící součást jiného okna. Nad instancí třídy TopComponent může uživatel provádět operace, které jsou typické pro mnoho aplikací s grafickým uživatelským rozhraním jednotlivé komponenty lze minimalizovat, maximalizovat nebo zakotvit uvnitř jiné komponenty. O správu oken se stará vždy implementace třídy WindowManager. Především se automaticky stará o persistenci stavu všech oken aplikace. Pokud uživatel ukončí běh aplikace, 44

52 4.1. API POUŽITÁ PRO TVORBU NOVÉHO MODULU uloží se nejen obsah všech oken (například v editoru), ale také rozložení jednotlivých komponent. Zajímavou funkcionalitou je asociace rozložení oken podle typu souboru, který je otevřen v editoru. Je zřejmé, že k pohodlné editaci JSP souboru je vhodné mít k dispozici zcela jiné ovládací prvky, něž pro psaní zdrojového kódu v jazyce Java. Správce oken si složení a rozložení sady oken pamatuje a při otevření souboru stejného typu zobrazí ta okna, která uživatel k editaci stejného typu souboru použil naposled, a umístí je na stejná místa, kde je uživatel zanechal. Toto chování je velmi podobné perspektivám známým z vývojového prostředí Eclipse. Toto API není v modulu využíváno explicitně, nebylo třeba vytvářet nové typy oken či s nimi asociovat speciální akce. Jeho využití je však nezbytné vzhledem ke grafickému rozhraní celého NetBeans IDE Web APIs, J2EE DD API Dostáváme se k rozhraním, která jsou využívána především u modulů, které rozšiřují možnosti při tvorbě webových aplikací. První sada API usnadňuje práci s webovými moduly obecně zpřístupňuje jejich nastavení a definuje pro ně užitečné konstanty. Architekti platformy NetBeans mysleli na možné rozšiřování IDE o nejrůznější webové rámce. Toto rozhraní tak například obsahuje metody pro získání seznamu registrovaných rámců a v SPI 1 části pak přímo i třídy užívané při tvorbě modulu přidávajícího do IDE podporu pro webový rámec. 1 Základem celého API je abstraktní třída WebFrameworkProvider, která reprezentuje jeden webový rámec v rámci platformy. Prostřednictvím instance této třídy lze získat řadu informací: seznam konfiguračních souborů, se kterými rámec pracuje, jaké knihovny se mají k projektu připojit, pokud chce vývojář webový rámec využívat, či jaké nastavení je třeba v projektu (webové aplikaci) provést, aby rámec po nasazení do kontejneru správně pracoval. Instance této třídy musí být korektně zaregistrována v souboru layer.xml pod klíčem j2ee/webtier/framework. Druhé rozhraní J2EE DD API je využíváno ke čtení a zápisu deployment deskriptoru webové aplikace. Jak již bylo zmíněno, pokud vývojář má zájem o využívání rámce Stripes ve webové aplikaci, musí provést některá nutná nastavení v souboru web.xml. Modul, jehož návrhem a implementací se zabývá tato diplomová práce, provede všechna nezbytná nastavení automaticky. Soubor se však nezpracovává jako textový soubor ani se neanalyzuje pomocí XML parseru. J2EE DD API poskytuje třídy a metody k pohodlné práci s deskriptorem, přidání nezbytných servletů a filtrů je pak otázkou pouze několika řádků kódu Project API, Project UI API, Java Project Support Project APIje základem pro jakoukoliv práci s projekty v prostředí platformy NetBeans. Toto 1. SPI je zkratka slov Service Provider Interface. Na rozdíl od API Application Programming Interface to není sada rozhraní, nýbrž abstraktních tříd, které sice obsahují nějakou funkcionalitu, ale musí být pro konkrétní nasazení vývojářem doplněny o další chování. 45

53 4.1. API POUŽITÁ PRO TVORBU NOVÉHO MODULU API definuje abstrakci nad projekty jako kolekcemi souborů, které mají danou strukturu, je možné je kompilovat a jinak s nimi manipulovat. V NetBeans se standardně k sestavování projektů používá nástroj Ant, jsou však i moduly podporující tvorbu a práci s projekty sestavovanými pomocí nástroje Maven či make. Z tohoto rozhraní bylo využíváno především třídy FileOwnerQuery, pomocí níž lze určit projekt, ve kterém je obsažen daný soubor (určený pomocí instance FileObject). Také bylo hojně využíváno možností třídy ProjectUtils, která umožňuje získat všechny skupiny zdrojových souborů (kolekci instancí implementujících rozhraní SourceGroup) vytvořených v daném projektu. Toho bylo využito v nejrůznějších oknech, které reflektují aktuální strukturu zdrojových souborů v projektu. Příkladem může být dialog, ve kterém vývojář vybírá šablonu rozložení pro novou JSP stránku. Další dvě rozhraní obsahují implementaci typicky používaných grafických komponent, které jsou využívány v souvislosti s projekty aplikací založených na platformě Java. Příkladem může být dialog pro vytvoření nového Java souboru, který lze získat prostřednictvím třídy JavaTemplates. Obsahuje standardní pole pro volbu názvu souboru a balíku, ve kterém má být nový zdrojový soubor umístěn. Komponenta může být navíc rozšířena o panel obsahující ovládací prvky pro zadání dalších údajů, které jsou poté použity k vytvoření souboru. Tohoto dialogu bylo využito při implementaci tvorby nové action bean instance. Jde to běžnou třídu, vývojář má však navíc možnost při vytváření nové action bean instance specifikovat předka třídy (jiný, dříve vytvořený action bean), či zda mají být implementovány / překryty metody pro získání a nastavení kontextu Lexer API Toto rozhraní, jak již jeho název napovídá, definuje přístup k lexikografické analýze nějakého textu. Zdrojem textu může být například CharSequence, java.io.reader nebo javax.swing.text.document. Klíčovým prvkem celého API je rozhraní TokenId. Každá instance toho rozhraní pak reprezentuje jeden token v daném jazyce. Jednotlivé jazyky (například Java, JSP, HTML atd.) implementují rozhraní TokenId nejčastěji ve formě výčtového typu (potomka abstraktní třídy java.lang.enum). Výčet pak zahrnuje veškeré lexikografické jednotky daného jazyka: rezervovaná slova, identifikátory, literály, oddělovače, operátory atd. Pro účely tvorby nového modulu byly využity následující dvě implementace rozhraní Lexer: Java Lexer; HTML Lexer. Obě implementace byly použity pro možnost tvorby hypertextových odkazů mezi jednotlivými zdrojovými soubory. Vždy je nejprve nutné určit, zda daná oblast textu, ve které vývojář chce aktivovat hypertextový odkaz, má jako odkaz sloužit. Například v JSP souboru je podle umístění kurzoru v textu určeno, zda se tento nachází uvnitř hodnoty atributu beanclass nějaké značky Stripes. Pokud ano, je celá hodnota tohoto atributu zobrazena jako odkaz 46

54 4.1. API POUŽITÁ PRO TVORBU NOVÉHO MODULU a po kliknutí na něj se provede pokus o otevření Java souboru specifikovaného daným plně kvalifikovaným jménem (balík a název třídy) Editor API, Text API Poslední dvě rozhraní, která budou ve výčtu zmíněna, pokrývají v NetBeans potřebu na otevírání souborů v editoru a možnost změny jejich obsahu, například na základě uživatelem provedené akce. Editor API slouží k přidávání různých editorů, které jsou vždy vázány na určité typy souborů. Pro každý typ souboru (XML dokument, zdrojový soubor Java, JSP, soubor CSS pravidel) je vhodné mít k dispozici specializovaný editor, který tvorbu příslušného dokumentu co nejvíce usnadní. V NetBeans IDE jsou k dispozici editory pro nejrůznější jazyky, v nichž je samozřejmostí barevné zvýrazňování klíčových slov, odsazování nových řádků, doplňování konce rozepsané části slova v závislosti na kontextu (code-completion) a další. Pokud tvůrce nového modulu zavede nový typ souboru (například přidává podporu pro nový programovací jazyk, jež dosud není v NetBeans IDE zahrnut), může pro něj rovněž definovat nový typ editoru. Ten je pak automaticky vybrán pro otevření nového typu souboru. Pokud pro daný typ souboru neexistuje žádný specializovaný editor, použije se editor prostého textu. Text API přináší možnosti, jak textový obsah daného dokumentu (otevřeného v nějakém editoru) číst a programově měnit. Zajímavou možností tohoto rozhraní je schopnost zamknout určitou část zdrojového kódu tak, že jej uživatel nemůže prostřednictvím NetBeans editoru nijak změnit. To je velmi vhodné, pokud je například tato část kódu automaticky generována a uživatelovy změny v této oblasti by byly dříve či později nahrazeny vygenerovaným textem. Kombinace možností, které obě API nabízejí, bylo využito při tvorbě nových položek pro paletu. Ta slouží ke vkládání krátkých úseků kódu, například HTML značek. Z okna palety stačí přetáhnout myší příslušnou značku přímo do okna editoru a ta se automaticky vloží na určené místo v kódu. API bylo použito ke zjištění pozice kurzoru a vložení kódu nové značky do již existujícího textu. 47

55 Kapitola 5 Implementace zásuvného modulu Nový modul si klade za cíl usnadnit vývoj webových aplikací, které jsou založeny na rámci Stripes. Na rozdíl od ostatních webových rámců (Struts, Spring Web MVC, Wicket, JSF) neexistovala pro tento rámec v prostředí NetBeans IDE žádná speciální podpora. To samozřejmě nevylučovalo vývoj aplikace operující prostřednictvím tohoto rámce, nicméně oproti vývoji aplikace využívají některý z podporovaným rámců to vyžadovalo od vývojáře větší počáteční investici, co se znalostí týče. V první podkapitole budou shrnuty rysy, které jsou do vývojového prostředí díky novému modulu přidány. Zároveň budou uvedeny názorné ukázky, jak tyto nové aspekty zjednodušují vývoj nové webové aplikace. V další podkapitole si přiblížíme nástroje a postupy, pomocí nichž byl projekt řízen a které napomáhaly k úspěšnému naplnění jeho cílů. Mezi ně patří sběr požadavků, správa verzí, sledovaní změn, publikování nových verzí a další. Již delší dobu se ukazuje, že tyto činnosti jsou daleko důležitější, než samotná tvorba (kódování) celé aplikace a jejich opomenutí má často za následek neúspěch celého projektu. V poslední, třetí podkapitole budou diskutovány některé z problémů, které musely být při implementaci modulu řešeny, a způsob, jakým byly překonány. 5.1 Implementovaná funkcionalita V této podkapitole, jak již její název napovídá, bude probrána šíře záběru nového modulu, tedy jaké podpůrné nástroje přidává do NetBeans IDE a jak tyto vývojáři mohou usnadnit vývoj. Sběr požadavků byl proveden na základě dvou hlavních zdrojů. Prvním byly osobní zkušenosti při vývoji několika projektů, ve kterých se na prezentační vrstvě používal rámec Stripes. Druhým byly již existující zásuvné moduly, které v NetBeans IDE existují, například pro Struts, Spring Web MVC nebo Wicket. Kořenovým balíkem byl po vzoru konvencí v prostředí platformy NetBeans a ostatních webových modulů zvolen org.netbeans.modules.web.stripes Registrace rámce v projektu Základním požadavkem na funkčnost nového modulu bylo vytvoření stejných startovních podmínek, jako mají jiné webové rámce. Tedy dát vývojáři nové webové aplikace možnost 48

56 5.1. IMPLEMENTOVANÁ FUNKCIONALITA zvolit si podporu pro rámec Stripes na stejném místě, jako byl zvyklý u jiných rámců. Tímto bodem je v NetBeans IDE průvodce pro vytvoření nového projektu webové aplikace. Průvodce má několik částí a jedna z nich dává možnost přidat podporu pro některý z dostupných webových rámců. Proto bylo více než vhodné zahrnout přidání rámce Stripes právě do seznamu nabídnutém při vytvoření nového projektu. Nový webový rámec lze do zmíněného seznamu zahrnout zaregistrováním instance v souboru layer.xml pod klíčem j2ee/webtier/framework. Tato instance musí rozšiřovat třídu WebFrameworkProvider, dané kritérium splňuje v modulu nově vytvořená třída nazvaná StripesWebFrameworkProvider, která implementuje všechny povinné abstraktní metody svého předka. V architektuře NetBeans IDE reprezentuje každá instance třídy WebFrameworkProvider obálku, která zaštit uje jeden webový rámec. Jejím prostřednictvím lze získat název daného rámce, jeho popis, množinu konfiguračních souborů užívaných rámcem a mimo jiné i implementaci třídy WebModuleExtender, pomocí níž je webová aplikace fyzicky rozšířena o podporu nějakého rámce. Pro tyto účely byla vytvořena třída StripesWebModuleExtender, která implementuje především tyto dvě metody: abstract JComponent getcomponent(); abstract Set<FileObject> extend(webmodule webmodule); První metodu zavolá průvodce vytvořením nového projektu v okamžiku, kdy potřebuje zobrazit konfigurační dialog daného rámce. Druhá metoda je průvodcem vyvolána, pokud vývojář daný webový rámec zahrne do své aplikace a ta se tak rozšíří o jeho podporu. Kontrakt této metody říká, že návratovou hodnotou je kolekce souborů, které mají být po úspěšném vytvoření projektu otevřeny v editoru vývojového prostředí. Metoda extend() má možnost získat nastavení provedená v konfiguračním dialogu, její chování tedy může být naprogramováno v závislosti na provedených nastaveních. Třetí stěžejní třída, která byla vytvořena pro potřeby konfigurace rámce Stripes v projektu webové aplikace, nese název StripesConfigPanel. Je potomkem třídy JPanel z rámce Swing, jde o grafický panel zobrazující ovládací prvky pro konfiguraci rámce. Instance této třídy je návratovou hodnotou metody getcomponent(). Pro ilustraci, jak tento konfigurační dialog vypadá v průvodci vytvořením nového projektu, může sloužit obrázek 5.1. Dialog má tři záložky, v první lze nastavit parametry pro Stripes Dispatcher a Filter, jejichž význam byl popsán v kapitole 3. Uživatel si v současné verzi modulu nemůže zvolit v konfiguračním dialogu obsluhu požadavků pomocí dynamického filtru. To je způsobeno faktem, že v době tvorby modulu nebyla k dispozici stabilní verze Stripes verze 1.5 (vydána až v průběhu března 2009), ale pouze 1.4.3, ve které se tato funkcionalita nevyskytovala. Možnost zvolit dynamické mapování by měla být zcela určitě přidána v některé z dalších verzí modulu, například ve formě drop-down menu v první záložce dialogu. Vložená data tedy obsah dvou textových polí jsou při každé změně automaticky validována pomocí regulárního výrazu. Uživateli se tak nepodaří vložit neplatný vstup například prázdný řetězec znaků. Druhá záložka poskytuje možnosti zvolit, zda k projektu přidat ResourceBundle, ze 49

57 5.1. IMPLEMENTOVANÁ FUNKCIONALITA Obrázek 5.1: Konfigurační dialog kterého Stripes budou brát lokalizované zprávy pro názvy polí, validační chyby apod. Také je možné nastavit, jaké lokalizace zahrnout (aktuálně je dostupná anglická a česká), a která lokalizace bude pro rámec v dané aplikaci výchozí. Třetí a momentálně poslední záložka konfiguračního dialogu slouží k přidání dodatečných knihoven vedle standardních.jar archivů nezbytných pro běh rámce v aplikaci. Momentálně je možné využít automatického připojení knihovny značek JSTL verze 1.2. Pokud tvůrce nového projektu zvolil podporu rámce Stripes ve své aplikaci, zavolá se metoda extend(). Ta provede atomicky následující sekvenci akcí: změní se obsah deployment deskriptoru tvořené webové aplikace vytvoří se servlet a filtr pro Stripes a dle konfiguračního dialogu se namapují na dané URL; k aplikaci se připojí knihovny rámce Stripes případně i jakékoliv další vybrané v třetí záložce konfiguračního dialogu; pokud uživatel zvolil přidání lokalizovaných souborů, podle zadaného nastavení se tyto vytvoří na korektním místě (kořenový balík zdrojových souborů Java) a naplní správným obsahem. 50

58 5.1. IMPLEMENTOVANÁ FUNKCIONALITA Všechny třídy vytvořené pro správnou funkčnost této části modulu jsou umístěné pro přehlednost v podbalíku config Nové šablony souborů Platforma NetBeans umožňuje definovat šablony souborů, ze kterých lze generovat výsledné instance. V šablonách lze používat syntaxi jazyka Freemarker a využívat proměnných, které jsou při vytvoření každého souboru k dispozici. Těmi jsou například název nového souboru či jeho autor. V šabloně je tak lze nahradit zástupnými symboly ${user} respektive ${name}, které jsou při vytvoření výsledného souboru nahrazeny korektními hodnotami platnými pro nový soubor. Vývojář, který tvoří aplikaci stavějící na podpoře rámce Stripes, nejčastěji vytváří tři druhy souborů související s rámcem. Prvním typem jsou action bean instance, tedy zdrojové soubory tříd pro obsluhu požadavků. Druhým jsou Stripes šablony sloužící k definování rozložení JSP stránek a posledním JSP soubory užívající jako základ svého rozložení některou z dříve vytvořených šablon knihovny Stripes. Modul přidává šablony pro všechny tři jmenované typy souborů. Ke každé šabloně je možné v prostředí platformy NetBeans rovněž zaregistrovat průvodce (konfigurační dialog zobrazený při vytváření nového souboru ze šablony), který může obsahovat další nastavení specifické pro daný typ souboru. Specializovaný průvodce byl vytvořen pro novou JSP stránku založenou na šabloně rozložení a pro nový action bean. První průvodce umožňuje zadat cestu k použité Stripes šabloně či tuto vybrat pomocí dialogu, jak ilustruje obrázek 5.2. Pro vytvoření šablony rozložení nebyl specifikován speciální průvodce, je tedy použit standardní, který je v NetBeans IDE používán k vytváření běžných JSP souborů. Průvodce, který je uživateli zobrazen, pokud chce vytvořit novou action bean instanci, má složitější chování. Umožňuje zadat následující parametry výsledného souboru Java: zda bude vytvořená třída implementovat / překrývat metody getcontext() a setcontext(), případně jaká třída se má použít jako implementace kontextu (pokud má třída předka, nemusejí se tyto již generovat, pokud jsou implementovány a pro použití nové třídy vyhovují); zda bude třída mít nějakého předka (například jinou action bean instanci); možnost přidat a specifikovat vzor URL, kterou bude třída obsluhovat. Předka i třídu kontextu je možné zadat bud vyplněním jejího plně kvalifikovaného jména (název souboru a balík, ve kterém je umístěna), či ji vybrat mezi existujícími zdroji v projektu. Vzhled průvodce je zachycen na obrázku 5.3. Prostředí NetBeans IDE poskytuje jednoduchý nástroj, jak sdružovat šablony nejrůznějších zdrojových souborů. V menu Tools -> Templates je budována struktura typu les, do které jsou umíst ovány jednotlivé šablony. Kolekci dostupných šablon lze obohatit bud přidáním nového modulu, který nějaké šablony definuje, či vytvořením šablony z existujícího 51

59 5.1. IMPLEMENTOVANÁ FUNKCIONALITA Obrázek 5.2: Průvodce vytvořením JSP obsahující využití šablony rozložení souboru. Zároveň je možné libovolnou existují šablonu přímo v IDE změnit. Pokud tedy vývojáři webové aplikace nevyhovuje formát generovaného souboru (například preferuje jiné pořadí polí generovaných ve výsledné třídě nebo si přeje vkládat do hlavičky vlastní licenci), může si danou šablonu upravit přesně k obrazu svému. Při jejím příštím využití již bude vygenerovaný soubor odpovídat provedeným změnám. Veškeré šablony musejí být registrovány v souboru layer.xml příslušného modulu, pod klíčem Templates. Šablony je možné dále organizovat do složek, aby se na jednom místě nacházely vždy šablony jednoho zaměření. Bylo tak více než rozumné zařadit všechny tři vytvořené šablony do společné složky a jsou tedy definované pod klíčem Templates/Stripes. Tím je zabezpečeno, že vývojář při vytvoření nového souboru najde šablony týkající se rámce Stripes vždy v jedné složce pojmenované Stripes, která je vždy umístěna na stejném místě mezi ostatními složkami šablon Nové položky JSP palety Platforma NetBeans má mnoho užitečných nástrojů pro editaci souborů. Vedle samotných editorů, kterých může být nepřeberné množství a mohou se lišit dle druhu souboru, existuje i nástroj zvaný paleta. Nejčastěji má formu dialogového okna, které se nachází vpravo 52

60 5.1. IMPLEMENTOVANÁ FUNKCIONALITA Obrázek 5.3: Průvodce vytvořením nové action bean instance od editovaného textu. Na paletu je možné umíst ovat jednotlivé položky, které reprezentují krátké úseky kódu, které je možné poté umíst ovat do editovaného kódu. Princip je velmi podobný šablonám, které byly probrány v předešlé podkapitole 5.1.2, nově vytvořeným objektem však není celý soubor, nýbrž pouze krátký úsek textu. Shodným rysem je i možnost definovat dialog s nastavením, který je zobrazen před vložením dané položky a může ovlivnit výsledný vložený text. Obsah palety se mění v závislosti na typu souboru, který je otevřen v editoru. Vývojář tak uvidí zcela jiné položky, když bude editovat HTML soubor, než když si otevře například JSP stránku. Položky lze do palety přidat opět bud nainstalováním nového modulu, který nějaké položky palety definuje, či přes Správce palety. Pomocí něj lze rovněž měnit pořadí existujících položek či je z palety zcela odstranit. Jednotlivé položky lze seskupovat do složek, podobně jako šablony souborů. Modul rámce Stripes přidává do palety celkem tři složky značky pro tvorbu formu- 53

61 5.1. IMPLEMENTOVANÁ FUNKCIONALITA lářů, značky definující rozložení stránky a ostatní značky knihovny Stripes. Všechny jsou definovány v souboru layer.xml pod klíčem, který odpovídá druhu palety, do kterého mají být jednotlivé položky přidány. Všechny nově vytvořené položky vkládají do textu některou ze značek knihovny Stripes. Jejich vložení je relevantní pouze pro JSP soubory, položky jsou tedy registrovány pod klíčem JSPPalette, což zajistí jejich zobrazování pouze pokud je editována nějaká JSP stránka. Každá položka palety má svůj vlastní XML deskriptor. Ten je registrován v konfiguračním souboru layer.xml a obsahuje definici těchto atributů dané položky: která třída reprezentuje chování dané položky palety; jaké ikony mají být v paletě použity pro vizualizaci položky (vedle jejího názvu); jaký ResourceBundle se má použít pro načtení lokalizovaných popisků jednotlivých položek. Třída která definuje danou položku musí implementovat rozhraní ActiveEditorDrop. To obsahuje pouze jednu metodu, která je zavolána, pokud uživatel umístí nějakou položku palety do okna editoru. Její deklarace je následovná: public boolean handletransfer(jtextcomponent targetcomponent); Do palety je novým modulem přidáno celkem více jak 20 položek. Chování při vložení položky je více méně stejné pro každou položku, po jejím umístění do okna editoru je provedena následující sekvence úkonů: 1. pokud byl pro položku definován konfigurační dialog, je tento zobrazen; 2. pokud uživatel nastavení v dialogu potvrdil (stiskl tlačítko OK), je zahájena změna obsahu souboru otevřeného v editoru; 3. do souboru je na zvolené místo vložen definovaný kus kódu, případně upravený podle nastavení vyplněných v dialogu. Z tohoto důvody byla navržena objektová struktura pro jednotlivé položky palety, aby se využilo znovupoužitelnosti jednotlivých částí procesu. Byla vytvořena abstraktní třída CodeSnippet, která reprezentuje jednu položku palety, a která implementuje zmíněné rozhraní ActiveEditorDrop. Třída obsahuje tři abstraktní metody, které musejí být u konkrétní položky implementovány: protected abstract String createbody(int caretpositiononline); protected abstract CodeSnippetCustomizer getcustomizer( CodeSnippet snippet, JTextComponent target); protected abstract String getbundlekey(); 54

62 5.1. IMPLEMENTOVANÁ FUNKCIONALITA První metoda vrací textový řetězec, který má být vložen do těla editovaného dokumentu. Kontrakt druhé metody říká, že vrátí instanci konfiguračního dialogu (viz dále), pokud položka tento využívá, případně prázdný odkaz (null). Poslední metoda vrátí jedinečný klíč, který identifikuje danou položku a je využíván k načítání lokalizovaných řetězců dané položky. Dále byla přidána abstraktní třída CodeSnippetCustomizer, která rozšiřuje JPanel a slouží jako objekt reprezentující konfigurační dialog dané položky palety. Obsahuje jedinou abstraktní metodu evaluateinput(). Ta je zavolána při potvrzení dialogu (stisku tlačítka OK) a jejím úkolem je předání vyplněných nastavení instanci třídy CodeSnippet, pomocí které byl daný dialog vyvolán. Pro jednotlivé položky palety, u kterých je žádoucí konfigurační dialog, je pak vytvořena implementace například ButtonCustomizer. Instance této třídy je pak vrácena metodou getcustomizer() příslušné třídy reprezentující danou položku palety Button. Jak již bylo zmíněno, každá položka má definovány dvě ikony, které jsou zobrazovány vedle jejího názvu v paletě. Některé nové položky palety zvláště ty, které vkládají značky týkající se formulářů mají své ekvivalenty v jazyce HTML. Tyto mají v NetBeans své položky v paletě zobrazované při editaci HTML souborů. Pro část položek tedy byly použity ikony již přítomné v NetBeans. Zhruba polovina značek knihovny Stripes však nemá svůj předobraz v žádném značkovacím jazyce a pro jejich položky v paletě musely být vytvořeny ikony nové. Pro jejich tvorbu se jako velmi užitečným ukázal být nástroj Inkscape. Jde o zdarma šířený grafický software, pomocí nějž lze tvořit a upravovat vektorové obrázky ve formátu SVG. Pro všechny položky, kterým dosud chyběla ikona, byl tak vytvořen vektorový obrázek znázorňující sémantiku dané položky. Z něj pak byly vygenerovány bitmapové verze o velikosti 16x16 a 32x32, které jsou požadováný platformou NetBeans. Výsledné ikony byly poté umístěny do modulu a použity v deskriptoru dané položky jako malá respektive velká ikona. Všechny vytvořené třídy, XML deskriptory a ikony jsou umístěny v balíku palette, respektive jeho podúrovních. Pro ilustraci vzhledu palety a rozsahu vytvořených položek může sloužit obrázek Hypertextové odkazy Velmi užitečným rysem, který platforma NetBeans nabízí, je možnost tvorby aktivních odkazů mezi jednotlivými zdrojovými soubory. Tyto jsou velmi podobně odkazům, které lze tvořit v jazyce HTML pomocí značky <a>. Každý úsek editovaného kódu může sloužit jako odkaz, v NetBeans je standardně aktivován podržením klávesy Ctrl a přejetím myši nad textem. Pokud pro dané místo zdrojového souboru má být aktivován odkaz, je tento zvýrazněn podtržením aktivního textu nebo změnou jeho barvy. Pokud na tento odkaz uživatel klikne levým tlačítkem myši, je provedena definovaná akce nejčastěji otevření odkazovaného souboru v editoru. Zároveň je možné v cílovém souboru specifikovat i určité místo, na kterém je po otevření souboru umístěn kurzor. Celé NetBeans IDE je plné aktivních odkazů, zvláště pro Java soubory či JSP stránky. 55

63 5.1. IMPLEMENTOVANÁ FUNKCIONALITA Obrázek 5.4: Paleta s položkami pro rámec Stripes Pro ukázku si vezměme ukázku Java kódu na obrázku 5.5. V tomto krátkém úseku kódu je k dispozici celkem 6 aktivním odkazů. Aktivním jsou všechny uvedené typy (v tomto případě třikrát třída String a po jejich aktivování je otevřen příslušný zdrojový soubor z knihovny standardních tříd jazyka Java. Aktivování řetězce prefix na 60. řádku přenese kurzor na 58. řádek, tedy na místo, kde byla proměnná deklarována. Podobně je kurzor přemístěn i po aktivování odkazu nad statickou proměnnou BUNDLE_KEY použitou v těle uvedené metody. V případě rámce Stripes bylo vytvoření podpory aktivních odkazů nasnadě. Často jsou z JSP stránek odkazovány jednotlivé action bean instance, například jako obslužné třídy pro formuláře či ve značce <s:url> sloužící k vytvoření URL, pomocí niž lze zavolat danou událost v dané action bean instanci. V jednotlivých metodách action bean instancí je řízení často předáváno na některou JSP stránku, udanou jako parametr konstruktoru příslušného objektu typu Resolution, který je poté vrácen obslužnou metodou. Užití obou typů odkazů ilustrují obrázky 5.6 a 5.7. K přidání podpory pro nový typ odkazů musí být v daném modulu vytvořena třída, 56

64 5.1. IMPLEMENTOVANÁ FUNKCIONALITA Obrázek 5.5: Ukázka aktivních odkazů v jazyce Java Obrázek 5.6: Aktivní odkaz vedoucí z JSP na action bean instanci která implementuje rozhraní HyperlinkProvider, a tato musí být korektně zaregistrována v souboru layer.xml. Použitým klíčem je Editors/text/x-jsp/HyperlinkProviders pro nové odkazy ze souborů JSP respektive Editors/text/x-java/HyperlinkProviders pro odkazy ze souborů Java (action beaninstancí). Rozhraní HyperlinkProvider obsahuje tři metody, které je nutno implementovat: boolean ishyperlinkpoint(document doc, int offset); int[] gethyperlinkspan(document doc, int offset); void performclickaction(document doc, int offset); První je automaticky zavolána, pokud se v editoru nachází daný dokument a je v něm aktivován odkaz. Má-li dané místo sloužit jako aktivní odkaz, vrátí metoda hodnotu true. Druhá vrátí v případě nutnosti aktivovat odkaz počátek a konec textu, který má být jako odkaz zobrazen. A konečně třetí metoda je zavolána v případě, že uživatel na aktivovaný odkaz klikne levým tlačítkem myši. Pro přidání zmíněné funkčnosti byly vytvořeny dvě třídy: Obrázek 5.7: Aktivní odkaz směřující z action bean instance na danou JSP stránku 57

65 5.2. POUŽITÉ NÁSTROJE A POSTUPY StripesBeanClassHyperlinkProvider pro odkazy z action bean instancí; StripesActionBeanToJspHyperlinkProvider k přidání odkazů směřujících z JSP stránek obsahujících značky Stripes. Tyto byly registrovány v souboru layer.xml. K implementaci metod ishyperlinkpoint() a gethyperlinkspan() rozhraní HyperlinkProvider bylo využito Lexer API, jak již bylo zmíněno v předešlé části Aktivní odkazy jsou v souboru JSP aktivovány u všech značek, které mají atribut beanclass. Jeho hodnotou je plně kvalifikovaný název action bean instance. Druhý druh odkazů je aktivován v případě, kdy se kurzor nachází na prvním parametru konstruktoru jednoho z typů ForwardResolution, OnwardResolution či RedirectResolution. Prvním parametrem je vždy textový řetězec, který určuje název souboru, na který se má předat řízení. Pokud je tímto parametrem literál typu String (tedy například řetězec /WEB-INF/jsp/user-detail.jsp uzavřený do uvozovek), může uživatel přejít přímo na soubor daného jména. 5.2 Použité nástroje a postupy V této podkapitole budou popsány postupy a nástroje, které byly použity k úspěšnému splnění vytyčených cílů. Mezi ně nepatří pouze nástroje použité přímo k tvorbě kódu, ale také prvky projektového řízení vývoje NetBeans IDE Základním nástrojem použitým k implementaci nového modulu je NetBeans IDE. Jedná se o standardní vývojové prostředí pro tvorbu aplikací, které je založeno na platformě NetBeans. A mimo jiné také obsahuje typ projektu Modul pro platformu NetBeans. Bylo tedy logické a nejjednodušší odstartovat práci na modulu právě vytvořením projektu tohoto typu. NetBeans IDE poté poskytuje vývojáři mnoho užitečných prostředků k obohacování modulu novou funkcionalitou. Především je to několik průvodců pro vytvoření typický prvků aplikace například nové položky v menu, nového typu souboru či nové položky v nastavení aplikace. Průvodce vytvoří všechny nezbytné třídy a konfiguraci v souboru layer.xml, což ve výsledku implementuje požadovanou funkcionalitu. Kolekce průvodců ovšem nepokrývá veškeré možnosti platformy NetBeans, ani požadavky na novou funkcionalitu, jak byla popsána v předešlé podkapitole Ta byla v takovém případě vytvořena na základě některého z výukových cvičení (viz [NBTUT]) a postupně obohacována a optimalizována pro pokrytí všech potřeb. NetBeans IDE také umožňuje jednotlivé moduly testovat a ladit. Modul je možné spustit v nové instanci NetBeans, do zdrojového kódu lze umíst ovat místa přerušení (breakpoints) a poté chod aplikace krokovat jako jakoukoliv jinou aplikaci. Velmi efektivní možností je schopnost platformy zavádět nové moduly za běhu aplikace, tedy bez nutnosti jejího restartu tzv. hot-deploy. To otevírá možnosti k rapidnímu zkrácení iterační cyklu, kdy vývo- 58

66 5.2. POUŽITÉ NÁSTROJE A POSTUPY jář během několika málo sekund může vidět či otestovat efekt jím přidaného kódu v běžící aplikaci Řízení projektu Základními pilíři pro úspěšné dokončení projektu jsou v zásadě tyto tři nástroje: systém pro správu verzí; nástroj pro sledování změn, jejich správu a kategorizování; veřejně přístupná webová prezentace, která shrnuje cíle a stav vývoje celého projektu. Po krátkém pátrání na internetu byl jako nejvhodnější kandidát na pokrytí všech požadavků zvolen systém Google Code 1. Systém nabízí prostor pro uchování zdrojových souborů v repositáři Subversion s veřejným přístupem z jakéhokoliv místa. Zároveň je přístup autentizován a probíhá přes zabezpečený protokol HTTPS. Dostupný prostor pro zdrojové soubory má aktuálně velikost 1024 MB na jeden projekt, což vytváří dostatečnou volnost v tvorbě jakékoliv struktury a obsahu repositáře. Dále je možné využívat jednoduchý systém na sledování změn. Registrovaní uživatelé tak mohou vkládat požadavky na novou funkcionalitu (či nalezené defekty) a poté sledovat, zda byl návrh přijat a v jakém stadium je jeho implementace (respektive oprava). Třetí bod, tedy možnost prezentovat cíle projektu, splňuje jednoduchá wiki 2, kterou lze obohacovat libovolnými informacemi vztahujícími se k projektu. 12 Systém také obsahuje stránku, na kterou lze umístit soubory ke stažení, tedy například binární distribuce vytvořené sestavením určité verze zdrojových souborů. To je velmi užitečné pro koncové uživatele, kteří se nechtějí starat o zdrojové soubory a zajímá je pouze výsledek, tedy sestavený modul připravený k instalaci do jejich systému. V prvních fázích projektu byl celý systém využívám především autorem celého modulu, v první řadě ke sběru požadavků a nastavování jejich priorit. Postupně byla rozšiřována wiki s popisem jednotlivých rysů nového modulu a také umíst ovány sestavené binární distribuce jednotlivých verzí modulu. V pozdějších fázích začali do systému rovněž přispívat jednotliví uživatelé modulu, především pak promítali do systému své návrhy na zlepšení a chyby nalezené při používání modulu ve svých vývojových prostředích Publikování nových verzí modulu Celý modul byl vyvíjen iterativně, implementovaná funkcionalita tedy přibývala postupně v jednotlivých cyklech. Tím vznikl požadavek jak, nové verze modulu poskytnout uživatelům novým či těm, kteří již mají nainstalovanou některou z předchozích verzí modulu. 1. Systém Google Code běží na adrese Stránky projektu modulu pro rámec Stripes lze navštívit zadáním 2. Wiki je jednoduchá on-line databáze znalostí, kterou mohou uživatelé měnit a obohacovat pouze prostřednictvím svého webového prohlížeče. Podrobnější definici termínu wiki lze nalézt například v [WIKI]. 59

67 5.2. POUŽITÉ NÁSTROJE A POSTUPY NetBeans IDE obsahuje ve standardní edici správce modulů, pomocí nějž lze přidávat, odebírat či měnit instalaci jednotlivých částí NetBeans IDE. Vývojáři tedy stačí poskytnout ke stažení binární soubor obsahující daný modul, uživatel si archiv uloží na svůj lokální disk a poté je možné (po spuštění NetBeans IDE ) nový modul nainstalovat. Pokud se v systému modul již nachází, avšak jeho verze je starší než ta specifikovaná v nově staženém archivu, je provedeno odstranění starší verze a její nahrazení modulem novým. Pro realizování popsaného postupu tak zpočátku vyhovovaly možnosti nabízené aplikací Google Code. Po přidaní nové funkcionality a jejím otestování byla pomocí NetBeans IDE vytvořena binární distribuce a tato prostřednictvím formuláře nahrána na server. Od té chvíle měli všichni návštěvníci webových stránek projektu tuto verzi k dispozici. Postupem času, v přibývajícími verzemi, přestalo být řešení dostačující. Stereotypní posloupnost jednotlivých manuálních akcí tak byla nahrazena automatizovaným procesem. K realizaci přenosu nového archivu na server bylo využito služeb zásuvného modulu z projektu ant-googlecode (viz [GCUP]). Ten umožňuje pomocí nástroje Ant (který je standardním nástrojem pro sestavování všech projektů v prostředí NetBeans IDE) nahrát libovolný soubor na zvolené místo na serveru Google Code. V deklaraci daného úkolu pro nástroj Ant stačí uvést platné údaje název projektu, přihlašovací jméno, heslo a popis souboru a daný archiv je automaticky umístěn na server. Zvolený postup byl velkým přínosem pro zefektivnění práce, avšak pouze ze strany vývojáře. Uživatelé modulu museli nové verze stále manuálně stahovat ze stránek projektu a instalovat do svých NetBeans. Platforma NetBeans naštěstí nabízí možnost, jak zautomatizovat i proces přenosu nové verze modulu ke všem uživatelům, kteří ho mají nainstalovaný. Slouží k tomu NetBeans Update Center. Do libovolné aplikace založené na platformě NetBeans je možné registrovat jedno či více aktualizačních center. Standardně jsou nainstalována 4 oficiální centra, která obsahují moduly certifikované a testované společností Sun. Uživatel může ale přidat libovolná další centra, kterých je na internetu k dispozici nepřeberné množství. Při startu NetBeans je pak provedena kontrola všech nainstalovaných modulů oproti všem definovaným aktualizačním centrům a pokud je nalezena nová verze modulu, je tato nabídnuta ke stažení a nainstalování přímo v prostředí NetBeans, bez nutnosti manuálního stahování v webových stránek. Zároveň není vůbec obtížné nové aktualizační centrum vytvořit. Netvoří ho žádná složitá webová aplikace, nýbrž pouze jeden konfigurační soubor. Ten obsahuje aktuální seznam všech modulů, které jsou přes toto centrum dostupné. Vždy je uvedena aktuální verze a místo, kde lze daný modul získat. Deskriptor a všechny archivy s jednotlivými moduly musejí být veřejně přístupně, například přes protokol HTTP. K jednoduchosti celého konceptu přispívá i fakt, že NetBeans IDE obsahuje jednoduchého průvodce, který umožňuje vytvořit modul, po jehož instalaci je do NetBeans přidáno nové aktualizační centrum. Pro pokrytí výše popsané funkcionality byl tedy vytvořen nový modul pro platformu NetBeans, nezávislý na modulu přidávajícím podporu pro rámec Stripes. Tento modul obsahuje jedinou deklaraci v souboru layer.xml je jí přidání nového aktualizačního centra. Deskriptor pro toto centrum je umístěn na stránkách projektu v systému Google Code, 60

68 5.3. PROBLÉMY A JEJICH ŘEŠENÍ stejně jako jednotlivé archivy modulu s podporou rámce Stripes. Pokud si uživatel stáhne ze stránek projektu modul obsahující aktualizační centrum a nainstaluje si ho do svého IDE, nemusí již kvůli novým verzím navštěvovat stránky projektu. O nových verzích je automaticky informován prostřednictvím svého IDE. Nový modul byl rovněž umístěn na server Plugin Portal, tedy do oficiálního úložiště modulů provozovaného firmou Sun 3. Jde o webovou aplikaci, která po bezplatné registraci umožňuje uživateli nahrát jím vytvořený modul a tím ho zpřístupnit široké veřejnosti. Pro každý modul lze zadat jeho popis, klíčová slova a seznam podporovaných verzí platformy NetBeans. Zároveň je vytvořen prostor pro diskuzi, přihlášení uživatelé mohou přidávat své reakce a zkušenosti s instalací či provozem modulu. Tato možnost slouží vývojářům daného modulu k získání základní zpětné vazby od zainteresovaných uživatelů. Pro jednotlivé moduly je evidován také počet jejich stažení Problémy a jejich řešení Při práci na modulu, o němž pojednává tato práce, se vyskytla řada překážek, které dosud v textu nebyly zmíněny vůbec či pouze okrajově. Ty nejzajímavější z nich shrnuje tato podkapitola Dialogy pro výběr souboru Na mnoha místech nově vytvořeného modulu je požadováno zadání plně kvalifikovaného jména nějaké třídy (například action bean instance pro obsluhu formuláře) či cesty k JSP souboru (například šabloně rozložení). Vždy je k dispozici klasický textový vstup, do kterého je možné požadovaný řetězec vypsat, žádný z těchto ovládacích prvků však standardně nenabízí kontextové doplňování konce rozepsaného řetězce. Proto byla ke každému takovému vstupu přidána možnost zadat soubor jeho zvolením v souborové struktuře projektu. Byl tedy vytvořen generický dialog, který ve svém okně zobrazí stromovou strukturu zdrojů určitého typu v daném projektu. Inspirace byla čerpána ze standardního modulu přidávajícího podporu pro tvorbu a editaci HTML souborů. Navíc byla však implementována možnost předat dialogu filtr, který je aplikován na zobrazované soubory a složky. Pomocí něho je možné zobrazovat pouze soubory určitých přípon či určitého obsahu. Bylo implementováno několik filtrů, například pro zúžení výběru pouze na JSP stránky, obrázky (.png,.gif.,.jpg či jinou kolekci grafických souborů) či soubory Java. Navržená architektura dává možnost implementovat v budoucnu další typy filtrů a tím dále omezit zobrazovanou kolekci souboru. Například nezobrazovat všechny soubory Java, ale pouze ty, které obsahují deklaraci nějaké action bean instance a podobně. Jedna z instancí dialogu (zde pro vybrání JSP souboru) je zahrnuta na obrázku Plugin Portal běží na adrese PluginPortal/. Stránka s modulem pro rámec Stripes se nachází na stránce org/pluginportal/faces/plugindetailpage.jsp?pluginid=

69 5.3. PROBLÉMY A JEJICH ŘEŠENÍ Pro soubory nacházející se v dokumentové struktuře webové aplikace tedy například JSP či HTML soubory se zdá být navržené řešení dostačující. Avšak pro zdrojové Java soubory zřejmě bude nutné v budoucnu dialog nahradit jiným řešením. Zde je příklad několika důvodů, které k tomuto závěru vedou: Dialog může procházet pouze soubory fyzicky se nacházející v aktuálním projektu. Často by však bylo užitečné rozsah výběru rozšířit na celou ClassPath daného projektu, tedy zahrnout například veškeré třídy definované v připojených knihovnách. Obsah jednotlivých balíků je zobrazován, i když neobsahuje žádný soubor Java. K nalezení třídy com.my.web.stripes.action.auth.useractionbean je tak nutné postupně šestkrát levým tlačítkem myši expandovat obsah jednotlivých podsložek (com, com/my, com/my/web atd.) než může být zvolen příslušný zdrojový soubor. A to i přesto, že jednotlivé podložky žádné soubory Java neobsahují a bylo by rozumné rovnou zobrazit obsah nejvíce zanořené složky tedy nejvíce specifického balíku. Nejlepším řešením by zřejmě bylo kompletní nahrazení dialogu pro soubory Java jiným, který by se choval stejně jako standardní dialog Go to Type. Ten slouží k otevření zdrojového souboru Java zadáním jeho jména (či jeho části). V NetBeans IDE se tento dialog zobrazí po stisknutí kombinace kláves Ctrl + O. Obsahuje celkem tři ovládací prvky. Prvním je textové pole, do kterého je možné vepsat název hledané třídy. Ve druhé části se vypisuje seznam tříd, které vyhovují zadanému názvu. Posledním prvkem dialogu je informační pruh zobrazující umístění aktuálně vybrané třídy. Tedy zda se tato nachází mezi zdrojovými soubory projektu či pochází z některé z připojených knihoven. Vzhled tohoto dialogu ilustruje obrázek 5.8. Otázkou však zůstává, zda by tento nový dialog byl dostatečné efektivní a prohledávání netrvalo příliš dlouhou dobu. U velkých projektů webových aplikací, které využívají služeb velkého množství knihoven, by mohla prohledávaná kolekce Java tříd čítat řádově deseti až sta tisíce souborů. I v případě Go to Type dialogu bylo v minulosti reportováno několik výkonnostních a funkčních chyb, není tedy zřejmě jednoduché danou funkcionalitu spolehlivě a efektivně implementovat i pro velké kolekce tříd Refactoring V projektu je často nutné, aby se radikálně změnila struktura zdrojových souborů. Například se přejmenoval některý z balíků, změnilo se umístění dané třídy či některá metoda se přesunula do jiné třídy. Takový proces se nazývá refactoring. Jeho důležitým rysem je, že chování aplikace před a po změně se nijak neliší, navenek se chová stále stejně. Ptáte se, jaké pohnutky vedou vývojáře k provedení často radikální obměny kódu, aniž to má nějaký viditelný efekt? Důvody ke změnám mohou být různé, od snahy o větší čitelnost kódu až po naplnění struktury předepsané některým z nově použitých návrhových vzorů. Více o tomto tématu a jeho abstraktním pozadí lze nalézt v [REFACT]. 62

70 5.3. PROBLÉMY A JEJICH ŘEŠENÍ Obrázek 5.8: Návrh budoucího vzhledu dialogu pro výběr souboru Java Změny by bylo možné provádět i manuálně, vývojář by se ale v záplavě tříd často ztratil a nakonec by stejně nedosáhl kýženého výsledku. Proto dnešní moderní vývojová prostředí, mezi než se počítá i NetBeans IDE, poskytují řadu nástrojů na automatické provedení rozsáhlých změn. Struktura projektu se tak může změnit k nepoznání během několika vteřin. V NetBeans IDE refactoring celkem spolehlivě funguje pro soubory Java. Kdybychom podrobněji zkoumali zdrojové soubory modulu, který podporu pro refactoring přidává, zjistili bychom, že se jedná téměř vždy pouze o posloupnost následujících operací: 1. nalézt všechny výskyty (užití) editované třídy; 2. pokud se mění fyzické umístění souboru (je požadována například změna názvu balíku), vykonat danou diskovou operaci; 3. provést řadu po sobě následujících operací nahrazení jednoto textového řetězce jiným tak, aby výsledný kód vyhovoval zadání a byl přeložitelný Java překladačem. Pokud však dojde na refactoring složitějších objektů, vývojové prostředí začne selhávat. Je celkem pochopitelné, že nelze refactoring provést nad XML či JSP soubory, které obsahují reference na jiné soubory či Java třídy. Vyžadovalo by to separátní podporu pro jednotlivá 63