Masarykova univerzita Fakulta informatiky Portálová aplikace pro plánování motivačních pohovoril Diplomová práce Petr Menšík Brno, podzim 2010 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 pri vypracování používal nebo z nich cerpal, v práci rádne cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Ing. Petr Adámek ii Poděkování Na tomto míste bych rád poděkoval vedoucímu mé diplomové práce Ing. Petrovi Adámkovi za skvelé vedení, obrovskou obetavost, vstřícnost a podnetné připomínky k této práci. Rovnež bych chtel podekovat zamestnancum firmy IBA CZ, kterí mi poskytovali cenné rady. iii Shrnutí V práci je popsána problematika vývoje portletů a aplikací pro portály. Součástí je definice a popis portálů, jejich rozdelení a nejpoužívanejší implementace. Jsou zde také popsány stežejní cásti standardů JSR 168 a JSR 286. Práce se dále venuje aktuálním technologiím používaným pro z'ednodušení vývoje portletu jako Spring framework nebo knihovny pro Javacript. Jsou také znímeny casté problémy, se kterými se lze setkat behem vývoje portletu, a je navrhnuto jejich možné řešení. iv Klíčová slova Portál, Portlet, Java, Spring, MVC, Motivační pohovor v Obsah 1 Portály............................................ 3 1.1 Horizontální portály................................. 3 1.2 Vertikální portály................................... 3 1.3 Portlet ......................................... 4 1.4 Hlavní společné rysy portálů............................ 4 1.5 Nejznámejší portálová rešení............................ 5 1.5.1 Liferay..................................... 5 1.5.2 IBM Websphere................................ 6 1.5.3 Microsoft Sharepoint............................. 6 1.5.4 Apache Pluto................................. 6 1.6 Standardy JSR 168 a JSR 286 ............................. 6 2 Vývoj portletu podle JSR 168............................... 10 2.1 Definice portletů podle JSR 168........................... 10 2.2 Portletový kontejner................................. 10 2.3 Portletové módy.................................... 10 2.4 Stavy okna portletů .................................. 11 2.5 Životní cyklus portletů................................ 11 2.5.1 Inicializace................................... 11 2.5.2 Zpracování požadavku ........................... 12 2.5.3 Ukoncení životního cyklu portletu..................... 13 2.6 Struktura požadavků................................. 13 2.6.1 Atributy požadavku ............................. 14 2.6.2 Parametry požadavku............................ 14 2.6.3 Session ..................................... 15 2.6.4 Portlet Preferences .............................. 15 2.6.5 Informace o uživateli ............................. 15 2.6.6 Cookies a lokalizace............................. 16 2.6.7 Kontext portletu ............................... 16 2.6.8 Použití výjimek při zpracování požadavku................ 16 2.7 Knihovna JSP značek pro portlety.......................... 16 2.8 Nové fůnkce z JSR 286 ................................ 17 3 Technologie pro vývoj portletu.............................. 18 3.1 Java Anotace...................................... 18 3.2 Spring framework................................... 18 3.2.1 Inversion of Control............................. 19 3.2.2 Dependency injection............................ 19 3.2.3 Moduly Springu ............................... 20 3.2.4 Core kontejner ................................ 20 3.2.5 Data Access/Integration........................... 21 3.2.6 Test....................................... 22 vi 3.2.7 AOP...................................... 23 3.2.8 Instrumentation................................ 23 3.2.9 Web....................................... 23 3.2.10 Návrhový vzor MVC............................. 23 3.2.11 SpringWebMVC............................... 24 3.2.12 Spring Portlet MVC ............................. 25 3.3 Bean Validation.................................... 26 3.4 Knihovny a technologie pro javascript....................... 27 3.4.1 jQuery..................................... 27 3.4.2 jQuery UI................................... 28 3.4.3 Datepicker................................... 28 3.4.4 Datatables................................... 29 4 Popis problémové domény................................ 30 4.1 Výhody plánování motivačních pohovorů..................... 30 4.2 Struktura motivaCních pohovorů.......................... 30 4.3 Aplikace pro plánování motivacních pohovorů.................. 31 4.3.1 Textová specifikace.............................. 31 4.3.2 Diagram prípadu užití............................ 32 4.3.3 Rozdelení prípadu užití podle portletových módu............ 34 4.3.4 Diagram tríd ................................. 34 4.3.5 Plánované rozšírření aplikace ........................ 34 5 Problémy pri implementaci aplikace.......................... 37 5.1 Použití JSR 303 validace ve Spring Portlet MVC ................. 37 5.2 Použití formátování výstupů pomoci anotací................... 37 5.3 Řešení rolí v portletů nezávislém na Liferay.................... 38 5.4 Poůžití externích Javacriptových knihoven v Liferay verze 6.......... 39 5.5 Selhávání nahrávání portletů na Tomcat...................... 39 6 Záver............................................. 40 Literatura............................................. 43 Rejstrřík .............................................. 44 vii Úvod Nejenom v dnešní dobí? se ukazuje, že jednou z nejdražších a nejcennejších vecí jsou informace. Současně je to ale artikl, který velmi rychle ztrácí na aktuálnosti. Proto ten, kdo má k dispozici informace presné a aktuální, má velký náskok pred ostatními. Potreba efektivní práce s informacemi si vynutila rozvojinformacních technologií. Velký prelom v efektivite zpracování informací nastal s príchodem prvních pocítacu. Uživatelské rozhraní výpocetní techniky se postupne vyvinulo od derných štítku, přes príkazové rádky, až po sofistikované systémy, jako je napríklad zpracování řeci, komunikace pocítace s clovekem pomocí zpracování neurobiologických signálu atd. Masove se ale rozšírilo pouze grafické uživatelské rozhraní (GUI) díky své jednoduchosti a intuitivnosti. Dusledkem rychlého vývoje a zlevííování výpocetní techniky se moderní pocítace s grafickým uživatelským rozhraním staly dostupné a uživatelsky prříveřtivé pro veřtšinu populace. Potrřeba efektivneř komunikovat vedla k vývoji pocřítacřových sítí a k jejich pozdeřjšímu propojení, címž vznikla celosvetová sít' internet. Stále se zvyšující dostupnost výpocetní techniky umožnila, aby se internet stal hlavním a celosveřtovým informacřním kanálem. Nej-využívanejší internetová technologie World Wide Web (zkratka www, casto oznacovaná pouze jako web) se vyvinula od jednoduchých webových stránek ciste statického rázu, až po plne interaktivní webové aplikace. Tyto webové aplikace mají celou radu výhod oproti tradicním pocítacovým programum bežícím na uživatelove pocítaci. Není potreba žádná jejich instalace, nebot' jsou umísteřny na webovém serveru, a proto má uživatel k dispozici aktuální verzi aplikace i dat, se kterými pracuje. Uživatel komunikuje s webovými aplikacemi pomoci webového prohlížecře, který je v dnešní dobeř standardní soucřástí v podstateř každého operacřního systému. Proto není trřeba instalovat žádný dodatecřný software. Mezi webové aplikace patrí také (podnikové) portály, kterým se venuje tato práce. Portálové technologie v posledních patnácti letech zaznamenaly velký rozmach. Typický dnešní portál tvorří sada samostatneř fungujících aplikací, které spolu mohou spolupracovat a každá z nich je zameřrřena na poskytování urcřitého typu informací. Portály jsou postaveny na celé rade platforem. Jednou nejpoužívanejších je platforma Java s portálovými specifikacemi JSR 168 a JSR 286. Nejenom rada výzkumu, ale i praktické zkušenosti manažeru mnohých firem ukazují, že jeden z hlavních faktorii ovlivnujících pracovní výkon jejich zamestnancu, predstavují dobré pracovní podmínky a kvalitní kolektiv. Každý clovek je jedinecný, má specifické potreby a vlastní žebrícek hodnot. Proto nelze ke všem zamestnancum přistupovat stejne. Casto stací zmeřnit malá drobnost, která dokáže výrazneř zvýšit nebo snížit spokojenost zameřstnance. Proto si dobrý manažer uveřdomuje, že zodpoveřdnost je obousmeřrná. Snaží se naslouchat potrebám zamestnancu a zajímá se o jejich návrhy, ze kterých se casto vyklube zajímavý a podnetný nápad, prínosný pro celou firmu. Jednou z možností, jak komunikovat se zameřstnanci, je provádeřt pravidelné motivacřní pohovory. Vést povovor tak, aby vedl ke zvýšení motivace, je jedním z nejnárocřneřjších manažerských úkolu. Manažer jejmusí vést tak, aby si získal zamestnancovu duveru a za-meřstnanec nemeřl pocit, že je motivacřní pohovor jenom zbytecřná formalita. Proto je klícřové 1 dodržovat pravidlo, že co se řekne na pohovoru, to nijak nesmí ovlivnit osobní hodnocení ani kariéru zamestnance. Takovýmto přístupem se buduje cenná oboustranná duvera mezi zamestnancem a jeho nadrízeným. Pokud manažer motivacní pohovor dobre zvládne, je hodnocený pracovník motivován nejen k vysoké výkonnosti v nárocných podmínkách pracovního procesu, ale i k ochote? rozvíjet svůj potenciál. Motivacní pohovory jsou však casto opomíjeny, nebot' manažeri mají spoustu jiné práce na úkolech, jejichž rešení je pro firmu primární. Proto mají motivacní pohovory nezrídka minimální prioritu. Navíc je to emotivne celkem nárocná cinnost a manažeri se do ní príliš nehrnou. Proto je ve firme vhodné zavést jednotný systém pro plánování motivacních pohovoria, který manažerum pripomene blížící se datum techto pohovorů a umožní tyto pohovory naplánovat. Systém zároven poskytne kontrolu nad celým procesem ze strany manažera lidských zdroju nebo vrcholového managementu. 2 Kapitola 1 Portály Portály jsou webové aplikace, které agregují informace z různých samostatných zdroju a poskytují je pohromade v jednom celku[36]. Tyto zdroje jsou casto komplexní, obsáhlé a složité. Casto daný portálový uživatel potřebuje pouze cást techto informací a jejich prehledné zobrazení. Toto umožnuje duležitá vlastnost portálu, kterou je konfigurovatelnost. Uživatel si muže casto sám nakonfigurovat, jaké cásti a v jaké podobe je bude používat. Jednotlivé dílcří funkcřní cřásti portálu se nazývají portlety. V soucasné dobe mnoho stredních a velkých firem využívá výhod svých intranetových firemních portálu, které si nechají vyvíjet na zakázku podle svých specifických potreb. Portály jim slouží jako jednotný prístupový bod pro všechny zamestnance. Centralizace a agregace informací umožnuje zamestnancum jednotný prístup k firemní agende? a usnadnuje firemní komunikaci a její rízení. Podle šíre záberu mformacního spektra se portály delí na horizontální a vertikální[36]. 1.1 Horizontální portály Horizontální portály pokrývají široký záber oblastí, které spolu nemusí vubec souviset. Uživatel má díky nim vše na jednom místeř. Typickým prříkladem takového portálu je ya-hoo.com, nebo seznam.cz (viz obr. 1.1), který pusobí prevážne v Ceské republice. Tyto portály poskytují informace z oblasti jako například pocasí, zpravodajství, financ-nictví. Casto také poskytují další služby jako napríklad email, datové úložište nebo vyhledávání v internetu. 1.2 Vertikální portály Vertikální portály (nekdy nazývané oborové portály, prípadne vortály[9]) jsou specializované pouze na urcřitou tématickou oblast. Veřtšinou se kolem nich vytvárřejí uživatelské komunity, jejichž clenové takto mužou mezi sebou komunikovat. Proto mezi casté služby poskytované teřmito portály naprříklad patrří posílání zpráv v reálném cřase, blogy, novinky z oblasti atd. 3 1.3. PORTLET Obrázek 1.1: Ukázka typického horizontálního portálu seznam.cz[29]. 1.3 Portlet Portlet je samostatná komponenta umístitelná na portálový server, na kterém po umístění funguje jako Část výsledné webové stránky generované portálem[27]. Vystupuje zde jako prezentaCní vrstva aplikace. Uživatel si muže podle potreby jednotlivé portlety pridávat a na stránce rozvrhovat. Jednu aplikaci muže prezentovat více než jeden portlet. Naopak, na stránce portálu muže být umísteno více instancí jednoho portletu. 1.4 Hlavní společné rysy portálů Mezi spolecné rysy všech portálu patří[21]: • jednotná autentizace uživatele (Single Sign On)- prihlasuje se pouze jednou do celého systému; • konfigurovatelné komponenty s možností pridávání ci odebírání; • nabídka komunikacních nástroju jako napríklad emailové a chat systémy; cřleneřní informací do adresárřové struktury; 4 1.5. NEJZNÁMEJŠÍ PORTÁLOVÁ REŠENÍ • možnost nastavení vzhledu zvlášť pro každého uživatele; • pokrocilé vyhledávání v rámci portálu. 1.5 Nějznámější portálová řěšění Na trhu existuje mnoho portálových rešení od různých spolecností a to jak open-source, tak proprietárních. Snaha sjednotit rozhraní pro vývojportletu vedla k vytvorení nekolika standardu, jako napríklad Portlet Specifícation 1.0 a 2.0 (JSR168 a JSR 286) nebo WSRP verze 1.0 a 2.0. Tato práce se venuje portálum založeným na platforme Java EE. 1.5.1 Lifěray Liferay je portál distribuovaný pod LGPL licencí a podporuje specifikace JSR 168, JSR 286, WSRP1.0i2.0[40]. Je k dispozici ve dvou verzích[20]: • Community edition - volne dostupná verze vydaná pod licencí MIT, vcetne zdrojových kódu. • Enterprise Edition - je urcena pro komercní využití, proto je u ní kladen duraz na stabilitu a je k ní poskytována kvalitní servisní podpora. Liferay plne podporuje SOA (Service Oriented Architecture). Komunita kolem nej se neustále rozrustá a v soucasnosti patrí mezi nejpoužívanejší portály ve firemních intranetech a extranetech, protože byl navrhován tak, aby šel bezproblémove zakomponovat mezi ostatní firemní systémy. Poskytuje další robustní funkcionalitu pro ruzné úcely jako napríklad správu dokumentu, LDAP, nástroje pro komunikaci (i v reálném case), tvorbu blogu a integraci se sociálními sítemi (Facebook, Twitter). Výhodná je jeho integrace s Microsoft Office, protože je to momentálne nejpoužívanejší firemní kancelárský software ve firmách. Liferay také poskytuje propracovaný autentizacní a autorizacní systém založený na pojmenovaných rolích, které lze priřazovat jednotlivým uživatelum nebo celým skupinám uži-vatelu. Na základe prirazených rolí pak uživatelé přistupují k aplikacím, nástrojum a jiným zdrojum. Mimo to je možné uživatele seskupovat do organizací a komunit, pricemž clenství v nich také ovlivnuje, jaké informace budou konkrétnímu uživateli prezentovány. Všechen vytvárřený obsah portálu (webový obsah, dokumenty, prříspeřvky na násteřnkách atd.) lze oznacovat štítky, což ulehcuje spolupráci s ostatními uživateli a vyhledávání[19][20]. Zmena rozložení portletu na stránce nebo pridávání aplikací a dalšího obsahu do portálu, jsou v Liferay opravdu snadnou záležitostí, nebot' mohou být pridávány a premisťo-vány pouhým tažením myši, stejneř jako je to beřžné naprříklad v operacřním systému Microsoft Windows. 5 1.6. STANDARDY JSR 168 A JSR 286 1.5.2 IBM Websphere IBM Websphere je pokrocilé portálové rešení, které beží na aplikacním serveru WebSphere Application Server, a je to jedno z nejkomplexnejších portálových rešení na trhu. Je nabízen v nekolika edicích podle použití[38]: WebSphere Portal Server, WebSphere Portal Enable, WebSphere Portal Extend a WebSphere Portal Express. IBM Websphere je tvoren velkou sadou softwarových nástroju, která poskytuje široké možnosti využití. Jeho administrace i samotná instalace jsou dost nárocné záležitosti díky kvuli rozsáhlosti systému a vyžadují podrobnejší znalosti. Firma IBM proto nabízí mnoho typu školení k tomuto nástroji. Je možno využít i velmi kvalitní servisní podporu prostred-nictvím standardních komunikacních kanálu, ale i objednat servisní výkony prímo u zákazníka. Nove jsou do tohoto portálu zakomponovány i tzv. akcelerátory, které lze snadno zapojit do WebSphere portálu a pomáhají zkrátit cas potrebný k dosažení výsledku a snížit náklady nasazení podnikových rešení. IBM Websphere podporuje jak standardy JSR 168 a JSR 286, takiWSRP1.0a2.0[38]. 1.5.3 Microsoft Sharepoint Microsoft Sharepoint je komercní portálové řešení poskytující kolekci nástroju pro sdílení, komunikaci, spolupráci a publikování na webu. zahrnuje produkty Microsoft SharePoint Server, MicrosoftSharePoint Foundation, Microsoft SharePoint Workspace a Microsoft Search Server. První komercní verze Microsoft SharePoint byla uvedena na trh v roce 2001. Je kompletne postaven na technologii ASP. NET. Podporuje pouze rozhraní WSRP 1.0 a 2.0 pro vývojportletu. Specifikaci JSR 168 a JSR 286 nepodporuje. Verze Microsoft Sharepoint 2010 poskytuje nové programové rozhraní založené na technologii Client Object Model, pomocí které je implementovaný kód spoušten na uživatelove pocítaci. Je to vlastne obdoba kombinace technologií javascript a AJAX[30]. 1.5.4 Apache Pluto Apache Pluto není portál jako takový, poskytuje jenom základní funkce a je to v podstateř pouze portletový kontejner. zajímavostí je, že Apache Pluto prředstavuje referencřní implementaci portletové specifikace JSR 168 a jeho nejnovejší verze 2.0 je zároven i referencní specifikací JSR 286. Proto je používán jako testovací prostredí pri vývoji portletu. Casto je integrován s portálem Jetspeed, kterému slouží jako portletový kontejner[25]. 1.6 Standardy JSR 168 a JSR 286 Pro umožneřní dalšího rozvoje portálových technologií na platformeř Java vznikla potrřeba standardizovat rozhraní mezi portletem a portálem. Dalším duvodem byla snaha vytvořit kvalitní alternativu k tehdy nove vydanému standardu WSRP 2.0, kterým se vznikající standard JSR 168 cástecne inspiroval[26]. Proto pod Java Comunity Process (otevrený proces pro 6 1.6. STANDARDY JSR 168 A JSR 286 správu a vytváření nových standardů pro platformu Java) vznikla expertní skupina, která v roce 2003 vydala první verzi portletové specifikace JSR 168. Tato skupina byla složena z tehdejších lídrů na poli portálových rešení založených na platforme Java. Hlavní cíle standardů JSR 168 jsou[10]: • definice prostredí pro beh portletu, realizovaného pomocí portletového kontejneru; • definice aplikacního rozhraní pro komunikaci mezi portletem a portletovým kontejnerem; • poskytnutí mechanizmu pro ukládání konfiguracních dat pro portlety; • možnost využití servietu a Java Server Pages (JSP) pro tvorbu portletu; • definice výsledného formátu aplikace pro umožnení snadné instalace do portálu; • přenositelnost portletu mezi jednotlivými portálovými implementacemi; • možnost použití portletu i v rámci protokolu WSRP. Pozdeji se ukázalo, že standardu JSR 168 chybí nekterá potrebná funkcionalita a vývoj nekterých typu portletu je zbytecne težkopádný. Proto se zacalo v roce 2006 vyvíjet rozšírení tohoto standardu, které bylo vydáno v roce 2008 pod oznacřením JSR 286. Tento nový standard prináší[39]: • podporu pro sdílení stavu a zdroju mezi portlety (napríklad možnost použít technologii AJAX); • rřízení událostí, na které portlety mohou reagovat; • možnost použití anotací zjednodušujících vývoj. Díky definici komunikacních prostredku mezi portlety je umožnena nová funkcionalita portálu jako celku, nebot' jednotlivé portlety takto mužou kooperovat a tudíž nevystupují pouze jako samostatné celky. Je také možno pomocí technologie AJAX nacříst pouze obsah jednoho portletu, aniž by byla obnovena celá portálová stránka, a dosáhnout tak zrychlení. Nové funkce z JSR 286 jsou podrobneřji rozebrány v sekci 2.8. 7 1.6. STANDARDY JSR 168 A JSR 286 PAR KV DISKUSE KALENDÁR SHOFY SPOTY propagační: F re e s tyl eZ O O s now kem pv 2011 Zima je tady a freestyleZQQ přichází se zimními kempy a ta rovnou se dvěma - v Rokytnici nad Jizerou a v sousedním Slovensku, v nejlepsím slovenském parku v Donovalech. Pod dohledem fsZOO kaučú je rozhodně na co se ... včera, napsal 0 komentáru H report: Iren Jib Železná Ruda Můžu se zeptat, co se tady bude dít? Kdy seto pojede? Oni tady budou jezdit na snowboardech po tom autě, že jo mami? Presnétakhleto vypadalo den před akcí. když se připrav cval park na Iren Jifc 2G1G uprostřed měst... i. _. 2-í" ■, rapsal Risl-ar-a Brož , Fotka Filip Brož 3 komentár j Q LOKňLrrr: St. Jakob in Defferegental V Alpách se nachází spousta resortů, které jsrju sice menšia mediálně měně provařené, ale presto zaslouží pozornost, už kvůli tomu, že sem nejezdítolik lidí a jsou tu kvalitní podmínky jak pro freestyle, tak pro fr... 5. 1. 2011. n.ap= = '.' = - n geaka 1 k.orŕntáŕ 1 j buyers1 guide HP! Právě se prodáváashání... FReview-Prosinec Už i naše FRedakce se probrala po silvestro vskěm veselí a stejně jak; každ} rak i letos vám budeme přinášet to nejlépe i ze snovjboardového déníu nás i za hranicemi. Snowboarding jde dopředu mílovými kroky a ani my n... 4. 1. 2011. napsal FReerife-ca B komentár j Q propagační: Freeride.cz Just Riďe! 2011 startuje Většina z vás si loni určité všimla série akcís názvem Just Ride, kterou jsme ve Freeride.cz vymysleli a připravili pro všechny zvás. Tenhle kolotoč víkendových 'demofestů' se ve spolupráci s Jagermeisterem a £wis... a. 1. 2011, napsal FReeriJe.cz S kprriEnt;ŕú <~} Prodává: Snowboardy - ELir ANSWER [" bh}, 4 000 Kc Prodává: OUečeri - Kulich RIDE, 300Kč Prodává: Snowtoardy - BURTON DOMINANT 154, 7 000 Kc scuTÉš Vyhrajte hodnotné ceny od Nugget 5 příchodem nového roku tu máme i dalsídvcutýdennísoutéž. Tentokrát proběhne boj o hodnotné ceny od brněnské značky Nugget. Pokud správně odpovňe na tri jednoduché otázky, máte možnost vyhrát pánskou snb bundu i. 1. 2011. napsal FReerife.c Obrázek 1.2: Ukázka typického vortálu freeride.cz[7], sdružujícího ceskou snowboardovou komunitu. 8 1.6. STANDARDY JSR 168 A JSR 286 Kapitola 2 Vývoj portletu podle JSR 168 2.1 Definice portletu podle JSR 168 Podle specifikace JSR 168 je portlet každá trída, která implementuje rozhraní Portlet, je také možnost vytvorit portlet rozšírením trídy GenericPortlet. Třída je prímo soucástí specifikace JSR 168 a implementuje rozhraní Portlet. Navíc poskytuje základní funkcionalitu pro vývojportletu[10]. 2.2 Portletový kontejner Portletový kontejner zajišťuje životní cyklus portletu a poskytuje mu potrebné aplikacní rozhraní. Prřijímá z portálu požadavky uživatele, zpracovává je a prředává dále konkrétním portletum. Poskytuje také úložište dat pro každý portlet, které se nazývá Portletpreferences. Portletový kontejner rídí životní cyklus portletu pomocí metod init, processAction, render a destroy, které jsou soucástí rozhraní Portlet. Tyto metody jsou podrobneji popsány v rámci následující kapitoly životni cyklus portletu[35]. 2.3 Portletové módy Portletové módy jsou typy úloh, podle kterých portlet zobrazuje svuj obsah. Specifikace definuje následující tri standardní módy[31]: • VIEW - portlet zobrazuje standardní obsah v závislosti na svém aktuálním stavu; • EDIT - slouží obvykle pro nastavení chování portletu; • HELP - slouží pro zobrazení nápoveřdy, prřípadneř pro popis funkcí portletu a jeho úcřelu. Podpora módu VIEW je povinná pro všechny portlety. Zbylé dva módy EDIT a HELP povinné nejsou. Specifikace také dovoluje definovat vlastní systém portletových módu, avšak pouze ty, které jsou podporovány portálem, na kterém bude portlet beřžet. V prřípadeř použití abstraktní třídy GenericPortlet je nutno prekrýt metodu doDispatch. Použití vlastního systému portletových módu ale není doporucováno z hlediska přenositelnosti[31]. 10 2.4. STAVY OKNA PORTLETU 2.4 Stavy okna portletu Oknoportletu predstavuje oblast stránky portálu, kterou pokryje obsah vygenerovaný port-letem. Podobne jako u portletových módu, je možno vytvorit i vlastní stavy okna portletu, nicméneř musí být tyto stavy opeřt portálem podporovány. Standard JSR 168 definuje následující stavy okna[31]: NORMAL - okno portletu zabírá standardní plochu na stránce portálu, na které je zobrazeno spolu s ostatními portlety. MINIMIZED - podle nastavení portálu portlet bud'to nezobrazuje nic, nebo malé záhlaví. MAXIMIZED - portlet zabírá celou plochu stránky portálu. Portál muže být nastaven tak, aby portlet v tomto módu nemohl prekrýt okna ostatních portletu. Je videt, že je zde jistá podobnost techto módu s chováním oken aplikací v operacních systémech s grafickým uživatelským rozhraním (s výjimkou prekrývání oken). 2.5 Životní cyklus portletu 2.5.1 Inicializace Inicializace je zajištena pomocí metody void init(PortletConfig config). Tato metoda slouží pro pocřátecřní nastavení instance portletu a musí být zavolána port-letovým kontejnerem prřed voláním dalších metod životního cyklu portletu. Je v ní inicializována aplikacřní logika a jsou provedeny prřípadné další cřasoveř nárocřné operace, jako naprříklad navázání prřipojení k databázi. Trída PortletConfig poskytuje tyto základní informace[31]: Jméno portletu: metoda getPortletName. InicializaCní parametry nebo seznam jejich jmen: metody getInitParameter a getInitParameterNames. Kontext portletu: metoda getPortletContext. 11 2.5. ŽIVOTNÍ CYKLUS PORTLETU Nastavení portletového kontejneru: metoda getContainerRuntimeOptions. Resource bundle pro danou lokalizaci: metoda getResourceBundle. Při neúspešné inicializaci je možno v metode init vyhodit výjimku PortletException nebo UnavailableException, která mUže mít definován Časový interval. V případe neúspešné inicializace mUže portletový kontejner zavolat metodu init znovu (v prípade vyhození výjimky UnavailableException až po uplynutí daného casového intervalu). Pokud ale metoda init neskoncí úspešne, portletový kontejner již nebude volat metodu destroy. Dále je k dispozici výjimka RuntimeException, která zpracovávána stejne jako výjimka PortletException[31]. 2.5.2 Zpracování požadavku Na rozdíl od servletu, který má pouze jednu metodu pro zpracování požadavku, portlet má dve metody[31]: render a processAction. Pro zobrazení obsahu portletu slouží metoda void render(RenderRequest request, RenderResponse response). Jako zobrazovací technologie muže být napríklad zavolána JSP stránka nebo servlet. Výsledek generování závisí na vnitrním stavu portletu, módu portletu a stavu portletového okna, ale tato metoda by nemela tento stav nijak menit. Menit by mela pouze zpťisob zobrazení tohoto stavu. Trída GenericPortlet definovaná v JSR 168 má metodu render již implementovanou a pouze je v ní zavolána další metoda doDispatch, která podle aktuálního módu, ve kterém se portlet nachází, zavolá odpovídající metodu pro daný mód. Standardneř je to neřkterá z metod doView, doEdit nebo doHelp. Pokud používáme vlastní systém portle-tových módu, je doporuceno metodu doDispatch prekrýt. Pro zpracování akcí, které meřní vnirřní stav portletu, se používá metoda void processAction(ActionRequest request, ActionResponse response). Typickou akcí mtiže být odeslání formuláre nebo modifikace dat v databázi. V této metode lze zmenit i stav portletového okna nebo mód portletu. Portlet muže mít definováno více akcí, je však nutno mezi nimi rozlišit napríklad pomocí parametru v promenné request (popsané dále). Po metode processAction je vždy zavolána metoda render u všech portletu, které se vyskytují na dané stránce portálu (s výjimkou portletui , které mají nastavené kešování). Poradí volání metody render portletovým kontejnerem není nijak urceno, dokonce nvuže být volání provedeno i paralelne[31] (viz obr. 2.1). 12 2.6. STRUKTURA POŽADAVKU Portál ■ Portiet ent P ord etovv kontejner A Požadavek Stránka portálu Portlet Pordet B C. proces eA cti oní) RenderQ Fragment stránky RendeiD Fragment stránky RendetT) Fragment stránky Obrázek 2.1: Poradí volání metod render a processAction portletovým kontejnerem[31]. 2.5.3 Ukoncení životního cyklu portletu Pro ukoncření práce slouží metoda void destroy(), ve které by meřly být uvolneřny všechny alokované zdroje jako naprříklad ukoncření prřipojení k databázi. 2.6 Struktura požadavku Rozhraní PortletRequest definuje základní funkcionalitu, která portletum poskytuje informace o uživatelském požadavku. Portletový kontejner používá pri komunikaci s port-letem dve základní specializované verze tohoto rozhraní[10]: ActionRequest (argument metody processAction) a RenderRequest (parametr metody render). Nejduležitejší informace z tohoto rozhraní jsou[31]: 13 2.6. STRUKTURA POŽADAVKU • Atributy požadavku. • Parametry požadavku. • Session. • Portletový mód. • Portlet Preferences. • Informace o uživateli. • Cookies a lokalizace. • Kontext portletu. 2.6.1 Atributy požadavku Atributy se využívají v rámci požadavku k predávání vetších objemu dat, k nimž muže prímo pristupovat JSP stránka nebo servlet pri generování obsahu portletu. Zpusob zprí-stupnení techto dat JSP stránce je popsán v 2.7. Atributy požadavku jsou hodnoty typu Object, takže lze ukládat v podstateř cokoliv. Metody PortletRequest pro práci s atributy jsou[28]: Object getAttribute(String name); void setAttribute(Object o); void removeAttribute(String name); Enumeration getAttributeNames(). 2.6.2 Paramětry požadavku Parametry požadavku jsou hodnoty posílané jako soucřást HTTP požadavku a jsou zakódované bud' prřímo v URL (u metody GET) ,nebo v teřle požadavku (u metody POST). Požadavek obsahuje pouze textové rřeteřzce, proto jsou i parametry požadavku typu String. Pokud po sobeř následují dva požadavky na stejný obsah portletu, jsou parametry v obou požadavcích stejné. Typický prříklad tohoto typu je obnovení stránky v prohlížecři. Díky teřmto vlastnostem jsou parametry veřtšinou používány pro rřízení vnitrřního stavu portletu. Parametry z požadavku zpracovávaného metodou processAction nejsou dostupné v následujícím požadavku zpracovaném metodou render, proto je nutno je uložit do odpovedi portletu pomocí metody setRenderParameter z rozhraní ActionResponse[10]. Metody rozhraní PortletRequest pro práci s požadavky jsou [28]: String getParameter(); Enumeration getParameterNames(); String[] getParameterValues(); Map getParameterMap(). 14 2.6. STRUKTURA POŽADAVKU 2.6.3 Session Session slouží jako úložišti? atributu, které jsou sdíleny v rámci uživatelského sezení (relace, angl.session) a jejichž doba platnosti odpovídá dobe platnosti sezení. Vytváří se zvlášť pro každou portletovou aplikaci a uživatele. Do session je doporuCeno ukládat co nejmín dat, protože velké objemy portlet velmi zpomalují[31]. Session získáme metodou PortletSession getPortletSession(); void setAttribute(String name, Object value, int scope). Argument scope urcuje viditelnost parametru a má dve volby[28]: APPLICATION_SCOPE - atribut je prístupný všem portlehim a JSP stránkám v rámci jedné portletové aplikace. PORTLET_SCOPE - atribut je prístupný pouze portletu, který je do sezení umístil. 2.6.4 Portlet Preferences Rozhraní PortletPreferences zvlášť pro každý portlet definuje perzistentní úložište dat a je spravováno portletovým kontejnerem. Výchozí hodnoty Portlet preferences mohou být definované v portlet.xml pomocí párové znacky . Pro každé port-letové okno se nastavují samostatne[31]. Portlet preferences lze získat metodou[28]: PortletPreferences getPreferences(), pro manipulaci s preferencemi slouží metody[28]: String getValue(String key, String def); String[] getValues(String key, String[] def); void setValue(String key, String value); void setValues(String key, String[] values); void store(). Po nastavení hodnot je nutno vždy zavolat metodu store, jinak preference nebudou uloženy. Nastavené hodnoty lze validovat pomocí třídy PreferenceValidator[28]. 2.6.5 Informace o uživateli Portlet muže z'išťovat podrobné informace o uživateli ze speciálního atributu USER_INFO[10] predaného jako argument metody getAttribute popsané v 2.6.1. Jedinecřné ID uživatele prřihlášeného do portálu, je možno zjistit metodou 15 2.7. KNIHOVNA JSP ZNACEK PRO PORTLETY String getRemoteUser(). Toto ID je výhodné používat v databázi. Zpťisob jeho generování je závislý na konkrétním portálu, proto nelze o neřm nic prředpokládat. Následující metoda slouží pro kontrolu, jestli prihlásený uživatel má danou portálovou roli[28]: boolean isUserInRole(String role). Tyto role se musí nejprve namapovat na portletové role. 2.6.6 Cookies a lokalizace Portlet muže samozrejme také pracovat s klasickými HTTP cookies. Muže také generovat svuj obsah v závislosti na nastavení lokalizace, které je vetšinou zišteno z nastavení prohlížece[10]. 2.6.7 Kontext portletů Kontext portletu definuje pohled portletu na portletový kontejner, který portletu takto zprí-stupnuje další zdroje. Portlet prípadne rrmže tímto zpťisobem predat rízení jinému portletu[10]. 2.6.8 Použití výjimek pri zpracování požadavků V obou metodách render i processAction mohou být vyvolány výjimky pro ošetrení nestandardních situací[31]: PortletException - signalizuje obecnou chybu pri zpracování požadavku. Po jejím vyhození prřestane portletový kontejner zpracovávat požadavky pro daný portlet. PortletSecurityException - signalizuje, že daný uživatel nemá dostatecná práva UnavaibleException - se používá pri casove nárocném zpracování požadavku a signalizuje, že portlet je (docasne) nedostupný. Je pnpadne možno specifikovat délku intervalu nedostupnosti. 2.7 Knihovna JSP značek pro portlety JSP stránky jsou cřasto používány pro generování obsahu portletu. V rámci standardu JSR 168 je proto zahrnuta knihovna znacek pro usnadnení vývoje portletu. Pro její zprístupnení je nutno do záhlaví JSP stránky přidat deklaraci[17]: <%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>. 16 2.8. NOVÉ FUNKCE Z JSR 286 Vytváření URL[17]: V rámci definice obou typu URL je možno definovat parametry (popsané zde), pomocí znacky . Príklad použití: . Vytváření jmenného prostoru[17]: V HTML stránce musí mít všechny elementy jedinecné ID, jinak stránka není validní. Tento nežádoucí stav nastane naprříklad prři výskytu více instancí portletu na portálové stránce. Proto doporuceno v názvech ID používat znacku , která vygeneruje unikátní kód zvlášť pro každou instanci portletu. Príklad použití: . Přístup k objektům RenderRequest, ActionRequest a PortletConfig [17]: VJSP stránce tyto objekty zprístupníme pomocí znacky , která musí být umísteřna prřed dalšími znacřkami používajícími tyto objekty. Nejlépe je ji proto umístit prímo na zacátek JSP stránky[31][10]. 2.8 Nové funkce z JSR 286 Standard JSR 286 rozšíril životní cyklus portletu o dve nové metody. K metodám init, render, processAction a destroy z JSR 168 přibyly dve nové metody processEvent a serveResource . Metoda void processEvent(EventRequest request, EventResponse resource) slouží portletum pro vyvolávání událostí a také pro reakci na ne. Portlety mohou takto mezi sebou komunikovat a posílat si zprávy. Je nutno ale definovat v souboru portlet.xml, na které události portlet reaguje a které vytvárří. Další novinkou je metoda void serveResource(ResourceRequest request, ResourceResponse resource), která rřeší neřkteré nedostatky starší verze standardu JSR 168. Pomocí ní lze poskytovat dynamické zdroje. Je vhodná pro použití technologie AJAX, pomocí které lze například nacřítat na pozadí obrázky, soubory javascriptu apod. Do knihovny JSP znacřek byla také prřidána znacřka resourceURL umožnřující vytvorření URL, které je zpracováno metodou serveResource . Pro komunikaci mezi portlety lze využít i tzv. verejné parametry. Po jejich deklaraci jsou prístupné stejným zpusobem jako standardní parametry požadavku. Oproti použití metody processEvent mají verejné parametry tu výhodu, že nemusí být na ne nijak reagováno, protože nejsou zpracovány zvláštní metodou[39]. 17 Kapitola 3 Technologie pro vývoj portletu 3.1 Java Anotace I když nejsou Java anotace technologií pro vývojportletu v pravém slova smyslu, zaslouží si samostatnou pasáž z duvodu jejich duležitosti. Ostatní technologie je široce využívají. Anotace byly poprvé uvedeny v Java SE verze 5.0, Umožnují do kódu vkládat speciální metadata, které poskytují další informace pro zacházení s anotovanými elementy. Tyto elementy mužou byt napríklad metody, trídy, Java balíky, promenné a parametry metod. Vetšinou znacná cást kódu aplikace neplní žádnou prímou funkci a slouží pouze jako obslužný kód pro razné typy nastavení, inicializace atd. Aplikace s velkým množstvím kódu, který plní pouze podpurné úcely, se stává velmi neprehledná a obtížne udržovatelná. Navíc se tento kód casto v razných podobách opakuje. Anotace reší tento problém tak, že obslužný kód presune mimo funkcní kód aplikace. Priřadí danému elementu metainformaci. Tímto způsobem se pro cloveka velmi zvýší citelnost kódu[1]. Je možno definovat také vlastní anotaci. Soucástí definice je seznam atributů anotace, množina elementu, na které muže být anotace použita a, zda budou informace vložené pomocí anotace dostupné i za beřhu aplikace. V soucřasnosti je velký trend využívat sílu anotací. I samotné generické nástroje Javy ,jako naprříklad Java Persistence API, jsou toho prříkladem. Spring jde stejnou cestou a jeho vývojári se snaží co nejvíce jeho funkcí zpnstupiíovat také pomocí anotací[1]. 3.2 Spring framework Spring framework je pokroälý podpurný aplikacní rámec pro vývojaplikací v Jave. Jeho tvurcem je Rod Johnson, který jejvydal jako prílohu své knihy Expert One-on-One J2EE Design and Development v říjnu 2002. Za pomoci Juergena Hoellera byl Spring pozdeji rozšíren a v cervnu 2003 uvolnen jako open-source pod názvem Spring Framework s licencí Apache 2.0[34]. V dobe psaní této diplomové práce byla jeho aktuální verze 3.0.5. Spring se ukázal také jako výborná alternativa k Java technologii Enterprise Java Beans (EJB), která je v dnešní dobe díky nemu spíše na ústupu. Komunita vývojáru kolem Springu stále narustá velkou rychlostí, což umožnřuje další rozvoj Springu a zvyšování jeho kvality. Spring také získal ocenení JAX Innovation Award a Jolt productivity award[34] za jeho jednoduchost a užitecřnost. Spring je navržen jako plneř modulární a neinvazivní systém, proto je možno použít 18 3.2. SPRING FRAMEWORK pouze ty jeho cřásti, které jsou aktuálneř potrřebné. Mohou být také v prřípadeř potrřeby nahrazeny úplne jinou technologií (napríklad použití webového frameworku Jakarta Struts místo Spring Web MVC). Jedním z cílu Springu je usnadnení rešení typických problému, se kterými se vývojári potýkají pri vývoji moderních (webových) aplikací. Jsou to napríklad[34][33]: • špatná strukturovatelnost kódu; • opakující se kód; • testovatelnost; • udržovatelnost; • rřízení toku aplikace; • bezpecřnost; • aplikace návrhových vzoru. Spring poskytuje kostru aplikace, kde programátor poskytuje jenom konkrétní funkcní celky a jejich kód aplikace je Springem pouze v razných chvílích volán. Toho je dosaženo pomocí aplikace návrhového vzoru Inversion of Control a jeho podvzoru Dependency injection. 3.2.1 Inversion of Control Inversion of Control (zkratka IoC) je návrhový vzor usnadnující správu objektu a závislostí[6]. V beřžné aplikaci je rřízení výpocřtu provádeřno aplikací samou. Typicky je v ní cřást kódu zodpoveřdná za celou cřinnos, která provádí start aplikace, prřirřazení instancí promeřnným, volání metod jednotlivých objektu, ukoncení aplikace atd. Cř asto ale nastane situace, kdy je nutno vymeřnit jednotlivé cřásti kódu za jiné, což nelze jinak, než prřímo zmeřnou cřásti aplikace. Tento problém rřeší práveř návrhový vzor Inversion of Control, který prřenáší rřízení toku aplikace na externí rřídící strukturu provádeřjící jednotlivé akce. Puvodní aplikace tak predstavuje pouze samotnou funkcionalitu a nestará se o seberízení[11]. Duležitým aspektem aplikace Inversion of Control je kontrola procesu instanciace spravovaných objektu. Je možno takto napríklad zajistit, že daný objekt bude jedinácek bez do-datecného kódu uvnitr jeho trídy[11]. 3.2.2 Dependency injection Návrhový vzor Dependency Injection je speciální prřípad návrhového vzoru Inversion of Control a jeho princip aplikuje v prípade zodpovednosti za provázání objektu. Definuje zpusob, jakým se toto provázání provádí[6]. Spring používá dva zpťisoby injekce závislosti[33]: 19 3.2. SPRING FRAMEWORK • injekce pomocí konstruktoru; • injekce pomocí metod set. 3.2.3 Moduly Springu Spring se skládá asi z dvaceti modulů, které jsou seskupeny do následujících skupin podle jejich zamerení[34]: Core, Data Access/Integration, Web, AOP (Aspect Oriented Programming), Instrumentation a Podpora testování. Viz obr. 3.1. Obrázek 3.1: Moduly Springu[33]. 3.2.4 Core kontejner Core kontejner - predstavuje základní funkcionalitu Springu a zajišťuje životní cyklus jím spravovaných objektu. Je navržen podle vzoru Inversion Of Control a zároven i Dependency Injection, pro který nabízí dva zpťisoby injekce[33]. 20 3.2. SPRING FRAMEWORK Spring Běans -jsou objekty spravované Core kontejnerem jsou nazývány a jsou to klasické POJO (Plain Old Java Object) objekty. Název Spring Beans je trochu zavádející, nebot' se na první pohled nabízí spojitost s technologií EJB (Enterprise Java Beans), se kterou Spring Beans nemají nic spolecného. Instanciaci Spring Beans objektu zajišťuje Core kontejner pomocí trídy BeanFactory, která implementuje návrhový vzor Factory. Díky ní odpadá nutnost programového rešení singletonu a prototypu[33]. Contěxt - je nadstavba Core a Beans modulu. Core kontejner se samostatne nepoužívá a je používán práveř pomocí Context modulu, který zajišt'uje další potrřebné základní služby. Ty zajišťují další duležité funkce jako napríklad internacionalizaci nebo zpracování událostí[ ApplicationContěxt - je prístupovým bodem celého Core kontejneru. Tato trída muže být volána bud'to programoveř, nebo deklarativneř pomocí zaregistrování do classpath aplikace. Samotná konfigurace třídy ApplicationContext muže být provedena i pomocí anotací, což je hodne rozšírená a výhodná možnost[33]. Exprěssion Languagě - poskytuje speciální jazyk pro manipulaci s objekty a jejich vazbami prři inicializaci nebo za beřhu Core kontejneru. Je navržen jako rozšírření jazyka EL (Expression Language), který byl specifikován jako soucást technologie Java Server Pages verze 2.1. Jazyk EL podporuje operace jako napríklad nastavování a získávání hodnot promenných, volání metod, ruzné logické a aritmetické operace, získávání Spring Beans z Core kontejneru a další[33]. V aplikaci by se nemeřlo programoveř prřistupovat k Java Beans pomocí Core kontejneru, protože je to porušení principu návrhového vzoru Inversion Of Control, jehož použití bylo jedním z hlavních duvodu vzniku Core kontejneru. 3.2.5 Data Accěss/Intěgration Tento balík poskytuje nástroje pro práci s daty a obsahuje tyto moduly: JDBC - slouží pro spojení a komunikaci aplikace s databází. Jeho použití vyžaduje v aplikaci spoustu obslužného kódu jako naprříklad prřipojení konkrétního databázového ovladacře, nastavení adresy databáze, založení prřipojení, prřipravení trřídy Statement, uzavrení pripojení a ostatních zdroju. Dále je pri komunikaci nutno ošetrovat složitou hierarchii výjimek a prřípadneř zarřizovat transakcřní zpracování databázových požadavku. Spring proto obsahuje JDBC modul, který prředstavuje abstrakci od aplikacřního rozhraní technologie JDBC a rřeší výše uvedené problémy. Prři jeho použití je nutno pouze 21 3.2. SPRING FRAMEWORK specifikovat požadovanou funkcionalitu, jako napríklad definici SQL dotazu nebo nastavení parametru. Ostatní provede Spring na pozadí[33]. ORM (Object Relation Mapping) -je technika zabývající se zpusoby prevodu objektového modelu na model relacřní a opacřneř. Modul ORM poskytuje snadnejší integraci pro nejpoužívanejší ORM nástroje. Podporuje napríklad Hibernate, Java Persistence API (JPA), Java Data Objects (JDO) a IBATIS SQL. Integruje funkcionalitu techto nástroju s dalšími nástroji Springu jako naprříklad deklarativním transakcřním zpracováním, ošetrřením hierarchie výjimek, nebo snadnejším testováním aplikace[33]. OXM - prináší abstraktní vrstvu pro OXM mapování, která má snadno nastavitelné rozhraní. To je technika zabývající se zpusoby prevodu XML dokumentu na objekt a opacřneř. Neřkdy se také tento proces nazývá XML serializace. Spring zde také rřeší tradicřní problémy se zachytáváním a zpracováváním hierarchie výjimek. Podporuje implementace AXB, Castor, XMLBeans, JiBX a XStream[33]. Transactions - poskytuje transakcní zpracování a je to jedem ze silných nástroji! Springu, které jejdelají ješte užitecnejším. Transakcní zpracování muže být nastavováno pro-gramove za behu aplikace nebo deklarativne (pomocí XML souboru). Vetšina vý-vojáru používá deklarativní zpusob, kvuli jeho neinvazivnosti a prehlednosti. Ve Springu jsou transakce navrženy s využitím principu aspektove orientovaného programování, nicméneř tento princip není nutno znát a lze bez problému transakce používat prímo. Transakce Springu mužou být také využívány spolecne s JTA (Java Transaction API), nebo v rámci lokálních transakcí používaných nástroji jako JDBC, JPA, Hibernate nebo JDO. Tato integrace Spring transakcí do všech vrstev umožnuje jejich snadné použití[33]. JMS - poskytuje abstraktní rozhraní, které zjednodušuje použití JMS (Java Messaging System). Obsahuje funkce pro príjem a tvorbu zpráv[33]. 3.2.6 Test Jedním z cílů vývojáru Springu bylo usnadnení testování Java EE aplikací. Spring proto poskytuje modul pro zajištení testovacího procesu pomocí knihoven JUnit nebo TestNG. Poskytuje konzistentní spuštení komponenty ApplicationContext a jejího kešování. Poskytuje i tzv. mock objekty, které mužou být použity pro testování urcité cásti kódu v izolovaném prostrředí. Pokud je aplikace rozvržena do jednotlivých vrstev, je možno otestovat pouze jednu její vrstvu bez nutnosti volání vrstvy nižší. Modul Test podporuje jednotkové 22 3.2. SPRING FRAMEWORK i integracřní testování. Pro jednotkové testování je použit samotný Core kontejner pomocí komponenty ApplicationContext, takže vývojář muže využít výhod správy realizované podle návrhového vzoru Inversion of Control[33][6]. 3.2.7 AOP Spring AOP (Aspect Oriented Programming) usnadnuje práci vývojárum v prípadech, kdy se pri volání metod ruzných tríd volá vždy stejný kód - napríklad pri autorizaci, otevírání a uzavírání transakce, atd. Spring má vlastní AOP modul, který je jednou z jeho klícřových cřástí. Je používán naprřícř celým frameworkem, kde je využíván hlavneř jako poskytovatel deklarativního transakcního zpracování a tvorby uživatelských aspektu. Pro objekty spravované Core kontejnerem je zahrnuta automatická inicializace AOP proxy objektu a vývojář se o nic nemusí starat[33]. Aspects modul umožnuje integraci AspectJ, je specializovaný nástrojsloužící jako rozšírení Javy o koncept AOP programování[34]. 3.2.8 Instrumentation Modul Instrumentation poskytuje kontrolu a zpracování metrik výkonu Core kontejneru. Dále poskytuje komplexní statistiky pro JDBC operace a transakcní zpracování, ORM nástroje Hibernate a Java Persistence API, nebo modul Spring Web MVC[32]. 3.2.9 Web Balík Web poskytuje služby pro prezentacní vrstvu. Jeho hlavní moduly jsou[33]: Spring Web MVC a Spring Portlet MVC. Dále nabízí možnost integrace dalších webových fra-meworku jako napríklad Serviet a Struts , podporu pro View technologie jako například JSF, Spring Web Flow, JSP atd. Také obsahuje podpurné nástroje pro usnadnení vývoje webových aplikací jako napríklad multipart upload souboru, nebo podporu remotingu ve webovém prostředí[33]. 3.2.10 Návrhový vzor MVC MVC (Model View Controller) je návrhový vzor, který rozdeřluje datový model aplikace, uživatelské rozhraní a rídicí logiku do trí nezávislých komponent tak, že modifikace ne-které z nich má minimální vliv na ostatní[22]. Nekdy je ale oznacován jako architektonický vzor namísto návrhového, protože definuje základní dekompozici celé aplikace a ne její konkrétní návrh. Tento vzor se v dnešní dobeř používá nejcřasteřji práveř u webových aplikací. Komponenty MVC mají následující funkcionalitu[24]: Model: - reprezentuje business logiku a data, s kterými aplikace pracuje a jsou prostrednic-tvím uživatelského rozhraní zprřístupneřny uživateli. 23 B.2. SPRING FRAMEWORK View: - je konkrétní zpťisob zobrazení dat modelu a dalších prvku prostrednictvím uživatelského rozhraní. Controller. - reaguje na požadavky uživatele a podle nich aktualizuje model a vybírá některý view. View Model Obrázek B.2: Provázání jednotlivých komponent v návrhovém vzoru MVC[24]. Controller má prřímý odkaz na model, aby mohl upravit jeho data. Vazba na View je pouze neprřímá a typicky je View vybírán pomocí pomocné komponenty. View má prřímý odkaz na Model, aby mohl jeho data zobrazit. Model ani View nesmí mít referenci na Controller. MVC je casto implementován jako tzv. Model 2, což je architektonický vzor, který navrhla firma Sun Microsystems. Model 2 je zameren na architekturu webových aplikací. Má navíc definován tzv. Front Controller, což je Controller, který přijímá požadavky od uživatele a deleguje je na jemu podrízené Controllery[2B]. 3.2.11 Spring Web MVC Spring Web MVC je vyvinut pro usnadneřní vývoje webových aplikací a je v soucřasnosti jeden z nejlepších a nejpopulárnejších frameworku vyvinutých pro tento úcel. Známý softwarový architekt Matt Raible zverejnil porovnání nejpoužívanejších webových frameworku a Spring Web MVC se umístil na prvním míste[2]. Jeho velkou výhodou je snadná nastavitelnost a plná konfigurovatelnost s možností použití anotací. Také plneř spolupracuje s ostatními komponentami Springu jako Core kontejner, transakcřní zpracování, AOP atd. 24 3.2. SPRING FRAMEWORK Základní funkcní jednotkou Spring Web MVC je trída DispatcherServlet, která zpracovává vstup od uživatele a predává jejkonkrétním metodám, které jejzpracují. Mapování komponenty View a lokalizace jsou plne konfigurovatelné. Jednotlivé komponenty z architektury MVC jsou plneř separované a jsou reprezentovány specializovanými objekty, proto mužou být zpravovány Core kontejnerem. Casto vyzdvihovanou predností Web MVC je možnost použít jakýkoliv objekt s get a set metodami jako tzv. form-backing objekt. To znamená, že po odeslání dat z formulárře je prřímo z teřchto dat vytvorřen tento objekt a není nutno implementovat nejaké specifické rozhraní, jako v jiných webových frameworcích. Spring (Web) MVC má totiž výborne vyřešen prevod objektu na řetezce a opacne. Data z formu-lárře jsou totiž v principu prřijata pouze jako rřeteřzce a je nutno je neřjak prřevést na konkrétní objekty. Naprříklad se dá jednoduše nastavit namapování výjimek vyhozených beřhem chybného prřevodu na konkrétní internacionalizovanou hlášku, tu pohodlneř zpracovat pomocí objektu Errors a poté zobrazit u formuláre. Výjimky vyhozené behem tohoto procesu se zpracovávají pouze lokálneř a nedostanou se mimo objekt, který chyby z formulárře zpracovává. Také zpusob výberu View je plne konfigurovatelný pomocí rozhraní ViewResolver. Model (myšleno M z MVC) je navržen jako kolekce Map. Jako View technologii je možno jednoduše použít například Java Server Pages, Velocity nebo Freemaker. Pri použití technologie Java Server Pages je možno použít knihovnu tagu (soucást Springu), která poskytuje podporu pro snadnou tvorbu formuláru, zobrazení chybových hlášek, namapování hodnot z formulárře prřímo na objekty z modelu atd. Pro řízení a kontrolu pruchodu jednotlivými webovými stránkami aplikace je možno použít externí nástrojSpring Web Flow[33]. Na následujícím obrázku je videřt zpracování požadavku základními komponentami Spring Web MVC. Front Controller prřijme požadavek a deleguje jej podle jeho parametru na konkrétní Controller, který jej zpracuje a vytvorří Model. Ten je zpátky poslán Front Cont-rolleru, který vybere konkrétní View a prředá mu Model. View data z Modelu zobrazí, prředá rřízení zpátky Front Controlleru a celý proces se opakuje, viz obr. 3.3. 3.2.12 Spring Portlět MVC Spring nabízí také modul pro vývojportletu podle standardu JSR168 a 286 s názvem Spring Portlet MVC. Ten je navržen tak, aby se maximálneř podobal Spring Web MVC, všude, kde je to možné a vhodné. Používá proto stejné koncepty a vetšina jeho tríd má svuj protejšek u klasického Spring Web MVC. Je také plneř provázán s ostatními komponentami Springu. Proto vývojárř znalý Spring Web MVC nebude mít veřtší problémy prři prřechodu na Spring Portlet MVC. Klícovou trídou ve Spring Portlet MVC je trída DispatcherPortlet, která vystupuje jako Front Controller. Hlavním bodem, ve kterém se Spring Web MVC a Spring Portlet MVC frameworky liší, je, že portlet muže mít na rozdíl od servletu dve rozdílné fáze zpracování uživatelských požadavku - action fázi a render fázi. Zásadní dusledek je ten, ze action fáze je zavolána jednou a po ní muže následovat jedna nebo více render fází. Vetšina portletových 25 3.3. BEAN VALIDATION Obrázek 3.3: Zpracovávání požadavku základními komponentami Spring Web MVC [33]. frameworku se snaží maximálne skrýt odlišnosti mezi portletem a klasickou Javovou webovou aplikací tak, aby se vývojportletu co nejvíc podobal vývoji servletu. Vývojári Spring Portlet MVC si ale myslí, že je to chyba. Nedovoluje to totiž využít výhody a sílu obou typu portletových fází, ve kterých se muže portlet nacházet. Spring Portlet MVC se také nestará o rozpoznávání lokalizace, nebot' tato oblast je v režii portálu, ve kterém portlet beží[33]. Tento framework také byl použit pro vývojaplikace v rámci této diplomové práce. 3.3 Bean Validation Spring od verze 3.0 podporuje standard JSR 303 (Beán Validation), který definuje validaci instancí JavaBeans pomocí anotací. Prímo u každého atributu, který má být validován, se pomocí anotace urcí validacní podmínky, které musí daný atribut splnovat. Tím odpadá nutnost implementovat oddelený kód, který by rešil tuto validaci, což je navíc spojeno s další režií - volání tohoto kódu a predávaní objektu, který má být validován. Další velkou výhodou je přehlednost kódu, protože atributy i podmínky, které musí splnovat, jsou přímo u deklarace atributu[i8]. Do classpath aplikace je ale nutno ješte pridat nejakou konkrétní implementaci JSR 303 anotace, protože zatím to není prímo soucást Java Runtime Environment. Momentálne nej- 26 3.4. KNIHOVNY A TECHNOLOGIE PRO JAVASCRIPT používanejší implementací je Hibernate Validator. Další informace k nemu viz.[8]. Příklad použití JSR 303 validace: Public class Person { @NotNull priváte String name; @Min(value=0) @Max(value=250) Private int age; Naopak klasickou metodou validace je nutno: i implementovat validátor pro každou trídu, jejíž instance je nutno mít validní (validátor je trída implementující rozhraní org.springframework.validation.Validator); ii validovat objekt pomocí validátoru (metoda validate); iii v prřípadeř, že objekt obsahuje chybné data zadané ve formulárři, je nutno zajistit, že se v následující metodeř render znovu neprřidá do modelu nový objekt této trřídy a mohly se ve formulárři zobrazit prříslušné chybové hlášky. 3.4 Knihovny a technologie pro javascript 3.4.1 jQuery jQuery je framework, který usnadnřuje práci s javascriptem. Jeho autorem je John Resige, který ji vydal v roce 2006 pod duální licencí GPL a MIT. Od té doby se kolem nej vytvorila velká komunita. Také proto je neustále ve vývoji a jsou pridávány další funkce. Pri jeho vývoji byl kladen duraz na jednoduchost, citelnost, rychlost. jQuery je navržen tak, aby fungoval na všech nejpoužívaneřjších prohlížecřích, proto je plneř multiplatformní. Prři jeho použití se snižuje objem napsaného kódu prumerne casto až o dve tretiny a výsledný kód je pre-hlednejší a expresivnejší[i4]. Má podrobne zpracovanou dokumentaci vcetne nejnäznejších tutoriálu usnadnujících zacátky. jQuery také umožnřuje používat javascript bez jeho detailní znalosti a je na neřm postavena spousta dalších javascriptových pluginu. Jeho hlavní filozofií je ucinit javascript nein-vazivním nástrojem a umožnit abstrakci od konkrétní struktury webových stránek. Toho je v jQuery docíleno pomocí implementace snadného vyhledávání a manipulace s elementy DOM (Document Object Model) pomocí technologií CSS nebo XPath. Hlavní funkce, které jQuery poskytuje, jsou[16]: • výber DOM elementu pomocí otevrené cross-browser knihovny Sizzle, což je odnož projektu jQuery; 27 3.4. KNIHOVNY A TECHNOLOGIE PRO JAVASCRIPT • funkce pro procházení a zmeřnu DOM; • zpracování a generování událostí; • manipulace s CSS; • efekty a animace; • zjednodušení použití technologie AJAX; • rozširřitelnost; • nabídka pomocných funkcí jako naprř. informace o prohlížecři; • podpora javascriptových pluginu. 3.4.2 jQuery UI jQuery UI je oficiální jQuery knihovna pro podporu tvorby uživatelského rozhraní. Je tvo-rena sadou interaktivních pluginu rízených událostmi. Je kladen duraz na nastavitelnost vzhledu, kompatibilitu s prohlížecři a se standardy pro vývoj webových aplikací. Nabízí také vlastní CSS framework Themeroller[15]. Pluginy jQuery UI se dají rozdeřlit na Interakce: jakémukoliv DOM elementu je možno prřirřadit dodatecřné chování, jako naprří-klad zmeřnu velikosti, možnost prřetahování myší na jiné místo na stránce a zmeřnu velikosti. Skupinu DOM elementu je možno také trídit. Widgety: jsou to znovupoužitelné a nastavitelné komponenty uživatelského rozhraní. jQuery UI nabízí: accordion (horizontální záložky), autocomplete (našeptávacř), button (tla-cítko), datepicker (vyber data z kalendáre), dialog (hlášky a komponenty formuláre), progresbar (ukazatel vývoje procesu), slider (posuvník) a tabs (záložky). Efekty: jsou to ruzné animované efekty pro prvky webových stránek, jako například animované skrytí a zobrazení elementu nebo widgetu. 3.4.3 Datepicker Datepicker je soucástí jQuery UI a nabízí snadné zobrazení kalendáre a jeho zadání. Muže být nastaven pro stálé zobrazení, svázání s urcřitým elementem nebo tlacřítkem. V základním nastavení také automaticky zakazuje zadávat písmena do pole s datumem [4]. 28 3.4. KNIHOVNY A TECHNOLOGIE PRO JAVASCRIPT 3.4.4 Datatables Datatables je widget postavený na jQuery a umožnuje jednoduché vytvorení interaktivní tabulky s mnoha nastavitelnými funkcemi jako napríklad razení pro všechny sloupce, filtrování obsahu, nastavení poctu zobrazených rádku nebo stránkování. Data pro tabulku mohou byt dodávány z ruzných zdroju jako Document Objekt Model, javascriptové pole, AJAX soubor atd. Datatables také podporuje nastavení vzhledu pomocí knihovny jQuery UI ThemeRoller. Podrobné informace lze nalézt v [3]. 29 Kapitola 4 Popis problémové domény 4.1 Výhody plánování motivaCních pohovoril Motivacní pohovory jsou casto opomíjeny, nebot' manažeri mají spoustu jiné práce na úkolech, jejichž rešení je pro firmu primární. Navíc je to emotivní? celkem nárocná cinnost, proto ani nemají motivaci pohovory pravidelneř provádeřt. Proto je ve firme vhodné zavést jednotný plánovací systém motivacních pohovoril, který by manažerui m prřipomínal blížící se data teřchto pohovorui . Dále by umožnřoval kontrolu provádení pohovorů osobou za to ve firme zodpovednou, napríklad manažerem lidských zdrojui nebo generálním rředitelem. 4.2 Struktura motivaCních pohovoril Motivacřní pohovory jsou veřtšinou dvou typui : Hlavní motivacní pohovor: je obvykle konán jednou za rok. Je na nem prítomen zamestnanec, jeho prímý nadrízený (který se nazývá liniový manažer) a nadrízený liniového manažera, který se nazývá reprezentant. Prítomnost reprezentanta je výhodná i pro zameřstnance, který mui že zmínit nedostatky ve vedení jeho prřímého nadrřízeného. Na hlavním motivacřním pohovoru se rřeší problémy dlouhodobého rázu, naprříklad zvýšení mzdy. Naopak manažer sdeřlí zameřstnanci své možné výhrady k jeho práci a navrhne možné rřešení. Prubežný motivacní pohovor: je konán až trikrát rocne. Tohoto pohovoru se zúcastní pouze zamestnanec a jeho prímý nadrízený. Zamestnanec zde se svým nadrízeným v soukromí probere své prřání a vize do budoucna. Dalším tématem mui že být spokojenost s kolektivem a pracovními podmínkami. Samozrřejmeř je take probrána spokojenost manažera se zameřstnancem. 30 4.3. APLIKACE PRO PLÁNOVÁNÍ MOTIVAČNÍCH POHOVORŮ 4.3 Aplikace pro plánování motivačních pohovoril 4.3.1 Textová specifikace Cílem je navrhnout aplikaci pro firmu IBA CZ, která by umožňovala liniovým manažerům organizovat a plánovat hlavní i vedlejší motivaCní pohovory. Mela by také zobrazovat pre-hledy provedených a plánovaných motivaCních pohovoria. Základní reprezentací je tabulka, kde prihlásený liniový manažer vidí seznam svých prímých podrízených a termíny jejich plánovaných a posledních probehlých hlavních a vedlejších motivacních pohovorů a prípadné reprezentanty. Tabulka se dá radit podle všech sloupců. Nekteré predem dané osoby mající roli s názvem Supervisor (napríklad manažer lidských zdrojů a generální reditel) si mohou zobrazit tabulku všech zamestnancu firmy. Pohovory by mely probíhat ve stanovených intervalech a mely by být naplánovány nej-pozdeji stanovený pocet dní pred jejich ocekávaným termínem. Stav naplánování hlavního i vedlejšího pohovoru je rozlišen barvou pozadí příslušného polícka: • Pohovor je naplánován nebo ješte neuplynula doba do první urgence. • První stupen urgence - pohovor není naplánován, ackoliv do jeho ocekávaného termínu zbývá méneř, než stanovený pocřet dní. • Druhý stupen urgence - pohovor není naplánován a již byl prekrocen jeho ocekávaný termín. Dále je možno vybranému zamestnanci pridávat, rušit, nebo editovat termíny pohovorů. Aplikace pracuje pouze s daty pohovoru a zatím nereší zadávání casu schůzky. Při zadávání termínu hlavního motivacního pohovoru lze navíc vybrat reprezentanta. Je také možno zobrazit kalendárř se zvýrazneřnými dny, kdy už má vybraný reprezentant neř-jaký hlavní motivacní pohovor naplánován. Dále se zobrazí zpráva s preferencemi daného reprezentanta (napríklad: „neplánujte mi prosím vice než jeden pohovor denní?"). Domluva termínu mezi reprezentantem, liniovym manažerem a zameřstnancem probeřhne samostatneř a není soucástí aplikace. Aplikace nacítá strom rízení zamestnanců pres definované rozhraní z externího zdroje (firemní adresárová služba, tzv. GreenPages). Termíny pohovorů a nastavení jednotlivých reprezentantů si aplikace ukládá do vlastní databáze. Možnosti nastavení aplikace: • přihlášený liniový manažer se může přidat do skupiny reprezentantů; • text informující o preferenci reprezentanta; • interval maximálního poctu dní mezi pohovory (nastavitelné zvlášť pro oba typy pohovorů); • nastavení, kolik dní prřed ocřekávaným termínem pohovoru zacřne platit stav první urgence; 31 4.3. APLIKACE PRO PLÁNOVÁNÍ MOTIVAČNÍCH POHOVORŮ • barva stavu první urgence; • barva stavu druhé urgence. Do budoucna mohou být pridány tyto funkce: • integrace s plánovacím kalendárem (Lotus Notes, Microsoft Exchange, apod.) usnad-nující plánovaní a umožnujíví vložení naplánovaného termínu do kalendáre všech úcastníku pohovoru; • implementace domluvy casu pohovoru mezi jednotlivými úcastníky pohovoru; • generování výsledné zprávy o prubehu motivacního pohovoru. 4.3.2 Diagram připadli užití PRípad ůžití: Zobraz tabůlků pRímých podřízených. Aktéři: liniový manažer. Vstupní podmínky: zamestnanec je prihlášen. 1. Tento prípad užití zacíná automaticky po spuštení aplikace, nebo po zadání odpovídajícího uživatelského požadavku. 2. Systém nacte z firemního adresáre Green Pages seznam prímých podrízených prihlá-šeného liniového manažera. 3. Pro každého zamestnance systém nacte termíny posledních i naplánovaných moti-vacních pohovoria obou typu. 4. Pokud má zamestnanec naplánován i hlavní motivacní pohovor a je pro nej zadán reprezentant, systém nacte reprezentantovo jméno. 5. Systém zobrazí tabulku s rádky odpovídajícími jednotlivým zamestnancum. Pro každého zamestnance jsou zobrazeny termíny posledního i plánovaného motivacního pohovoru (pokud existují). Ů termínu hlavního motivacního pohovoru je zobrazen případný reprezentant. PRípad ůžití: Zobraz tabůlků všech podřízených. Aktéři: liniový manažer. Vstupní podmínky: zameřstnanec je prřihlášen. 1. Tento prípad užití zacíná po zadání odpovídajícího uživatelského požadavku. 2. Systém nacte z firemního adresáre Green Pages seznam všech podrízených prihláše-ného liniového manažera. 32 4.3. APLIKACE PRO PLÁNOVÁNÍ MOTIVAČNÍCH POHOVORU 3. Pro každého zameřstnance systém nacřte termíny posledních i naplánovaných moti-vacních pohovorů obou typů. 4. Pokud má zameřstnanec naplánován i hlavní motivacřní pohovor a je pro neřj zadán reprezentant, systém nacřte reprezentantovo jméno. 5. Systém zobrazí tabulku s rádky odpovídajícími jednotlivým zamestnancům. Pro každého zameřstnance je zobrazeno jméno jeho prřímého nadrřízeného a také termíny posledního i plánovaného motivacřního pohovoru (pokud existují). U termínu hlavního motivacřního pohovoru je zobrazen prřípadný reprezentant. PRípad užití: Zobraz tabulku všech zamEstnancU firmy. Aktéri: supervizor. Vstupní podmínky: zameřstnanec je prřihlášen. 1. Tento prřípad užití zacříná po zadání odpovídajícího uživatelského požadavku. 2. Systém nacte z firemního adresáre Green Pages seznam všech zamestnanců firmy. 3. Pro každého zameřstnance systém nacřte termíny posledních i naplánovaných moti-vacních pohovoril obou typů. 4. Pokud má zameřstnanec naplánován i hlavní motivacřní pohovor a je pro neřj zadán reprezentant, systém nacřte reprezentantovo jméno. 5. Systém zobrazí tabulku s rádky odpovídajícími jednotlivým zamestnancům. Pro každého zameřstnance je zobrazeno jméno jeho prřímého nadrřízeného a také termíny posledního i plánovaného motivacřního pohovoru (pokud existují). U termínu hlavního motivacřního pohovoru je zobrazen prřípadný reprezentant. Prípad užití: Správa pohovoru. Aktéri: liniový manažer. Vstupní podmínky: zameřstnanec je prřihlášen. 1. Uživatel vybere zameřstnance. 2. Systém zobrazí probehlé i plánované termíny motivacních pohovorů daného zamest-nance. 3. U hlavního motivacního pohovoru systém zobrazí seznam reprezentantů. 4. Uživatel může zadat ci zmenit termíny plánovaných pohovorů obou typů. Pro zadávání termínů má k dispozici interaktivní kalendár. 5. Extension Point: jedná o hlavní motivacní pohovor. Uživatel může vybrat reprezentanta a po jeho výbeřru je zobrazen interaktivní kalendárř se zvýrazneřnými dny, kdy už má reprezentant nejaké termíny hlavních motivacních pohovorů naplánovány. 33 4.3. APLIKACE PRO PLÁNOVÁNÍ MOTIVAČNÍCH POHOVORU 6. Uživatel muže provedené zmeny uložit. PRípad užití: Správa nastavení. Aktéri: liniový manažer. Vstupní podmínky: zamestnanec je prihlášen. 1. Systém zobrazí aktuální nastavení uživatele. 2. Uživatel muže provést zmeny nastavení. 3. Uživatel muže zmeny uložit. 4.3.3 Rozdělění prípadu užití podlě portlětových módu VIEW: Zobraz tabulku prímých podrízených, Zobraz tabulku všech podrízených, Zobraz tabulku všech zamestnanců firmy, Správa pohovoru. EDIT: Správa nastavení. HELP: v soucasnosti není potrebný, nebot' portlet je urcen pouze pro úzkou komunitu uživatelů. Nicméne je v plánu portlet rozšírit i o tento mód. 4.3.4 Diagram tríd Diagram tríd je na obrázku 4.2. 4.3.5 Plánované rozšírění aplikacě Je plánováno rozšírřit stávající verzi aplikace o neřkteré další funkce. Meřly by být optimalizovány v aplikaci javascriptové funkce tak, aby fungovaly i v prřípadeř, že je nasazena více než jedna instance aplikace na stránce. Momentálne tento způsob nasazení není předpokládán, nicméne se to může zmenit. Aplikace bude také rozšírena o komponentu komunikující s plánovacím softwarem (naprříklad Lotus Notes). Další možnost se nabízí využít možnosti odeslat email všem úcastníkum pohovoru informující o naplánovaném termínu pohovoru. Pro usnadneřní procesu domluvy termínu pohovoru mezi jednotlivými úcřastníky by bylo vhodné také doplnit funkci umožnřující každému úcastníkovi navrhovat termíny pohovorů a postupne dojít ke spolecné shode. 34 4.3. APLIKACE PRO PLÁNOVÁNÍ MOTIVAČNÍCH POHOVORŮ 35 4.3. APLIKACE PRO PLÁNOVÁNÍ MOTIVAČNÍCH POHOVORŮ Obrázek 4.2: Diagram tříd. 36 Kapitola 5 Problémy pri implementaci aplikace 5.1 Použití JSR 303 validace ve Spring Portlet MVC Podle referencní specifikace Spring Web MVC a Spring Portlet MVC od verzí 3.0 je možnost využít koncept JSR 303 validace, kterou jsem plánoval použít. V dobeř psaní této diplomové práce byla aktuální verze Springu 3.0.5. Nakonec ale použití validace dle JSR 303 nebylo možné, protože v této aktuální verzi modulu Spring Portlet MVC byla objevena chyba zne-možnřující použití tohoto typu validace Tento problém bude opraven až v budoucí verzi 3.1[12]. Tato chyba se týká pouze modulu Spring Portlet MVC. V klasickém Spring Web MVC funguje tento zpusob validace bez problému. Kvuli tomuto zjištení bylo nutno použít klasický koncept validace. 5.2 Použití formátování výstupu pomoci anotací Chyba v aktuální verzi Spring Portlet MVC, která byla popsána v prředchozí kapitole, také znemožnřuje použití konvertování vstupu z rřeteřzce na objekt trřídy Date pomocí anotací. Proto bylo nutné použít starší koncept využívající implementaci rozhraní PropertyEditor, protože Spring Portlet MVC nemá pro trřídu Date formátování implicitneř nastaveno. Je nutno zaregistrovat bud' vlastní implementaci rozhraní PropertyEditor pro trídu Date, nebo je možno použít predpřipravenou trídu CustomDateEditor, což je snadnejší možnost. Registrace se provádí pomoci metody s anotací InitBinder. Príklad registrace pred-pripravené trídy CustomDateEditor: @InitBinder public void initBinder(PortletRequestDataBinder binder) { SimpleDateFormat df = new SimpleDateFormat("dd.MM.yyyy"); df.setLenient(false); binder.registerCustomEditor(java.util.Date.class, new CustomDateEditor(df, false)); 37 5.3. Rešení rolí v portletu nezávislém na liferay 5.3 Řešení rolí v portletu nezávislém na Liferay Bylo potreba zajistit, že portlet bude zobrazovat urcité data pouze uživatelům s daným oprávnením. Portál Liferay, pro který byl portlet vyvíjen, má propracovaný model autorizace a autentizace uživatelui a také poskytuje bohaté aplikacřní rozhraní pro autorizaci uži-vatelui a jejich správu. Portlet by meřl být teké co nejsnadneřji prřenositelný mezi jednotlivými portály. Proto bylo upušteno od použití aplikacního rozhraní portálu Liferay. Portletový standard JSR 168 umožnuje portletu zjistit pouze, jestli v portálu práve pri-hlášený uživatel má urcitou roli. Rozhraní PortletRequest poskytuje metodu: boolean isUserInRole(java.lang.String role), která vrací true, práveř když má uživatel roli, prředanou jako parametr. Tato metoda stacří pro základní rřízení autorizace a funguje tak, že abstrahuje od konkrétní struktury rolí v portálu a používá mapování na role definované v aplikaci. Proto je nutno provést následující kroky: i Do souboru portlet.xml (definovaném ve standardu JSR 168) do sekce odpovídajícího portletu e nutno prřidat seznam názvui rolí, které chceme aplikaci zprřístupnit. Tyto názvy mohou být libovolné. Prříklad: SUPERVISOR LINEMANAGER . ii V korřenovém adresárři portletové aplikace je potrřeba najít nebo vytvorřit soubor liferay-portlet.xml. Tento soubor obsahuje nastavení portletové aplikace pro beřh v portálu Liferay. Definici struktury tohoto souboru lze nalézt v dokumentaci portálu. V tomto souboru namapujeme názvy rolí, které jsme nadefinovali v souboru portlet.xml, na sku-tecřné role, vyskytující se v portálu Liferay. Mapování zajistíme pomocí párového tagu . Príklad definice rolí v liferay-portlet.xml: 38 5.4. POUŽITÍ EXTERNÍCH JAVACRIPTOVÝCH KNIHOVEN V LIFERAY VERZE 6 SUPERVISOR Administrator LINEMANAGER Power User . Tímto postupem je zajišteno, že pokud je v portletu zavolána metoda isUserInRole s argumentem SUPERVISOR, vrátí hodnotu true, práveř když má prřihlášený uživatel portálovou roli Administrator. Analogicky to funguje i u druhé role. 5.4 Použití externích Javacriptových knihoven v Liferay verze 6 V Liferay verze 5.2 a starších byl prímo dostupný javascriptový framework jQuery UI popsaný v 3.4.2. V aktuální verzi Liferay 6 byl jQuery UI nahrazen frameworkem Alloy UI, proto, pokud jej chceme použít, musíme jej explicitneř zprřístupnit (jako kteroukoliv jinou externí javascriptovou knihovnu) následujícím zpui sobem: i Zkopírujeme soubor s javascriptovou knihovnou do požadovaného adresárře webové aplikace. Správneř by ale meřly být všechny javascriptové knihovny v jednom adresárři z důvodu přehlednosti. Složka se souborem navíc nesmí být ve složce WEB-INF, protože z ní nelze prřímo cříst soubory beřhem beřhu portletu. ii Relativní cestu k javascriptové knihovneř prřidáme do souboru liferay-portlet.xml jednou z teřchto párových znacřek: použijeme, pokud chceme, aby se daný javascript nacetl na zacřátku portálové stránky. použijeme, pokud chceme, aby se daný javascript nacřetl na konci portálové stránky. Liferay poté automaticky do každé stránky prřiloží absolutní cestu k danému javascriptu a klientui v prohlížecř si jej stáhne a spustí. 5.5 Selhávání nahrávání portletu na Tomcat Pro vývoj aplikace byl použit portál Liferay beřžící na servletovém kontejneru Tomcat. Prři nahrávání portletu do Tomcatu se obcřas stalo, že se nezaktualizovaly všechny soubory a nepomohlo ani opakované nahrání portletu. Bylo nutno Tomcat zastavit, smazat složku s názvem portletu v adresárři webapps a znovu portlet nahrát. Poté už nahrávání fungovalo. 39 Kapitola 6 Záver Tato práce se venovala portálům a vývoji portálových aplikací. V dnešním mformacním veřku je cřloveřk nucen pracovat s obrovským množstvím informací a práveř portálové technologie usnadnřují jejich efektivní prezentaci, proto je toto téma velmi aktuální. V první kapitole jsou popsány druhy portálů, výhody jejich použití a jejich odlišný princip fungování oproti klasickým vebovým aplikacím. Dále byly popsány klícřové cřásti standardu JSR 168, který sjednocuje způsob vývoje portálových aplikací pro platformu Java. Tato pasáž také dobře poslouží zacátecníkům, kterým usnadní seznámení se s touto problematikou. Velká cást specifikace JSR 168 se totiž týká témat (napríklad komunikace mezi portálem a portle-tovým kontejnerem), které vývojárř portálových aplikací nevyužije. Také jsou zde popsány nejpoužívaneřjší technologie pro vývoj portálových aplikací jako naprříklad Spring framework. V práci je popsán také koncept motivacních pohovorů, jejich typická struktura a delení. Je zdůvodneno, proc je to výhodný a silný manažerský nástrojpro rízení komunikace ve firmách a doporučeno jejich plánování. V rámci této práce byla také vyvinuta portálová aplikace pro plánování motivacřních pohovorů pro firmu IBA CZ. Je postavena na již zmíneném frameworku Spring, zejména jeho prezentacřní vrstva využívá modul Spring Portlet MVC. Probeřhly již akceptacřní testy této aplikace a skoncřily úspeřšneř. Předpokládá se další rozšírení aplikace o funkce popsané v sekci 4.3.5. 4G Literatura [1] Jemný úvod do anotací, Scream, 2007, . 3.1 [2] Comparing JVM Web Frameworks, Raible Designs, 2010, . 3.2.11 [3] DataTables (table plug-in for jQuery), Allan Jardine, . 3.4.4 [4] jQuery UI - Datepicker and Documentation, The jQuery Project, 2010, . 3.4.3 [5] Enterprise portal, Wikimedia Foundation, Inc., 2010, . [6] Inversion of Control Containers and the Dependency Injection pattern, Martin Fowler, 2004, . 3.2.1, 3.2.2, 3.2.6 [7] Freeride.cz - Snowboarding, Freeride.cz, 2011, . 1.2 [8] Hibernate Validator, . 3.3 [9] Internetový portál, Wikimedia Foundation, Inc., 2010, , http://cs.wikipedia.org/wiki/Internetovy_portal . 1.2 [10] Introducing the Portlet Specification, Part 1, JavaWorld.com, 2003, . 1.6, 1.3, 2.1, 2.6, 2.6.2, 2.6.5, 2.6.6, 2.6.7, 2.7 [11] Inversion of control, Wikimedia Foundation, Inc., 2010, . 3.2.1 [12] Portlet MVC - doesn't inject conversion service and validator in WebDataBinder , springsource.org, . 5.1 [13] System Dashboard - Spring Projects Issue Tracker, springsource.org, . [14] : jQuerynávod pro začátecníky i pokročilé, . 3.4.1 [15] jQuery UI, The jQuery Project, . 3.4.2 41 [16] jQuery, Wikimedia Foundation, Inc., 2010, . 3.4.1 [17] Portal and Portlet Management JSP Tags, BEA Systems, Inc., . 2.7 [18] Getting started with JSR 303 (Bean Validation) - part 1 Bookmark and Share, Gun-nar Morling, 2009, . 3.3 [19] Enterprise open source portal and collaboration software - Liferay.com, Liferay Inc., . 1.5.1 [20] Liferay, Wikimedia Foundation, Inc., 2011, . 1.5.1 [21] definition: web portals | Motive Glossary, Motive Ltd, 2010, , . 1.4 [22] MVC, Fi WIKI, 2006, . 3.2.10 [23] Model-View-Controller, Wikimedia Foundation, Inc., 2011, . 3.2.10 [24] : Prezentační vzory z rodiny MVC - Zdroják, Internet Info, s.r.o., 2009, . 3.2.10, 3.2 [25] Pluto - Welcome to Pluto , springsource.org, . 1.5.4 [26] Java Portlet Specification, Wikimedia Foundation, Inc., 2010, . 1.6 [27] Portlet, Wikimedia Foundation, Inc., 2010, . 1.3 [28] Interface PortletRequest, Apache Software Foundation., 2008, . 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.6.5 [29] Seznam - Najdu tam, co neznám, Seznam.cz, a.s., 2011, . 1.1 [30] Microsoft SharePoint, Wikimedia Foundation, Inc., 2011, . 1.5.3 42 [31] JSR-000168 Portlet Specification - Final Release, Oracle Corporation, 2003, . 2.3, 2.4, 2.5.1, 2.5.2, 2.1, 2.6, 2.6.3, 2.6.4, 2.6.8, 2.7 [32] SpringSource Documentation, SpringSource, a division of VMware, 2010, . 3.2.8 [33] Spring Framework - Reference Documentation, springsource.org, . 3.2, 3.2.2, 3.1, 3.2.4, 3.2.5, 3.2.6, 3.2.7, 3.2.9, 3.2.11, 3.3, 3.2.12 [34] Spring Framework, Wikimedia Foundation, Inc., 2010, . 3.2, 3.2.3, 3.2.7 [35] Understanding the Java Portlet Specification, QuinStreet Inc., 2011, . 2.2 [36] Web portal, Wikimedia Foundation, Inc., 2010, . 1 [37] Web Portal software from WebSphere, IBM Corporation, . [38] WebSphere Portal, Wikimedia Foundation, Inc., 2010, . 1.5.2 [39] What's new in the Java Portlet Specification V2.0 (JSR 286)?, IBM Corporation, 2008, . 1.6, 2.8 [40] WSRP- Community Wiki - Liferay.com, Liferay Inc., . 1.5.1 43 Rejstřík 44