MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Portlet pro seznam úkolů BAKAL[ŘSK[ PR[CE Veronika Krajcarov{ Brno, 2010 ii Prohl{šení Prohlašuji, že tato pr{ce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracov{ní používala nebo z nich čerpala, v pr{ci ř{dně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí pr{ce: Ing. Petr Ad{mek iii Poděkov{ní Děkuji slečně Ivě Ž{kové za výbornou spolupr{ci při vývoji aplikace a děkuji také vedoucímu pr{ce Ing. Petru Ad{mkovi a zaměstnancům společnosti IBA CZ za cenné podněty a trpělivost při vývoji aplikace i při psaní samotné pr{ce. iv Shrnutí Cílem pr{ce je sezn{mit se s problematikou podnikových port{lů, s tvorbou portletů a vytvořit portletovou aplikaci pro seznam úkolů. V pr{ci je pops{no co je port{l a portlet, jak se portlety tvoří a jaké existují specifikace pro jejich vývoj. Pr{ce obsahuje také srovn{ní několika aplikací, které s úkoly pracují. N{sleduje popis implementace portletové aplikace pro seznam úkolů, kter{ podporuje agregaci úkolů z různých zdrojů a přenositelnost na různé port{ly. v Klíčov{ slova Port{l, portlet, podnikový port{l, Liferay, úkol, spr{va úkolů, JSR-168, JSR-286, SOAP, Jira, JSP, Java. vi Obsah Úvod ______________________________________________________________________1 1 Port{l a port{lové technologie _______________________________________________3 1.1 Podnikový port{l ___________________________________________________3 1.1.1 Liferay port{l ____________________________________________________4 1.1.2 WebSphere port{l ________________________________________________5 2 Portletový kontejner a portlety_______________________________________________6 2.1 Portlet a servlet_____________________________________________________6 2.2 Portletové specifikace JSR-168 a JSR-286 _______________________________7 2.3 Portletov{ aplikace _________________________________________________8 2.3.1 Portlety a model-view-controller ___________________________________9 2.4 Životní cyklus portletu _____________________________________________10 2.4.1 Vytvoření portletu_______________________________________________10 2.4.2 Zpracov{v{ní požadavků uživatele ________________________________10 2.4.3 Odstranění portletu a garbage collection____________________________11 3 Přehled aplikací pro spr{vu úkolů __________________________________________12 3.1 Outlook __________________________________________________________12 3.2 Remember the Milk (RTM)__________________________________________13 3.3 Rainlendar________________________________________________________14 3.4 IBM WebSphere Portal Unified Task List portlet _______________________15 3.5 Jira ______________________________________________________________16 4 Portlet pro seznam úkolů __________________________________________________19 4.1 Rozdělení vývoje __________________________________________________19 4.2 Popis aplikace_____________________________________________________20 4.2.1 Portlet pro seznam úkolů _________________________________________20 4.2.2 Portlet pro přehled nad úkoly jiných osob __________________________22 4.2.3 Portlet pro přid{v{ní a editaci úkolů _______________________________22 4.2.4 Portlet pro aktu{lní ozn{mení_____________________________________23 4.3 Struktura aplikace _________________________________________________24 4.3.1 Rozhraní Task __________________________________________________25 4.3.2 Rozhraní ProviderInterface _______________________________________25 5 Vývoj portletové aplikace __________________________________________________26 5.1 Vývojové prostředí ________________________________________________26 5.2 Použité technologie ________________________________________________26 5.2.1 SOAP __________________________________________________________26 5.2.2 Apache Maven __________________________________________________26 5.2.3 JQuery _________________________________________________________27 5.3 N{vrh____________________________________________________________28 5.4 Konektor pro systém Jira ___________________________________________29 5.4.1 SOAP klient ____________________________________________________29 vii 5.4.2 Jira backend ____________________________________________________30 5.5 Portlety __________________________________________________________31 5.5.1 Portlet pro seznam úkolů _________________________________________31 5.5.2 Portlet pro přid{v{ní a editaci úkolů _______________________________31 5.5.3 Portlet pro aktu{lní ozn{mení_____________________________________31 5.6 Implementace operací nad úkoly ____________________________________32 5.7 Kask{dové styly ___________________________________________________32 5.8 Vybrané metody ve třídě AggregationPoint ___________________________33 5.9 Podpora úkolů ke schv{lení _________________________________________33 5.10 Rozšíření do budoucna _____________________________________________34 5.10.1 Konfigurační portlet _____________________________________________34 5.10.2 Výběr jednor{zových filtrů _______________________________________34 5.10.3 Notifikační API _________________________________________________34 Z{věr _____________________________________________________________________35 Použit{ literatura___________________________________________________________36 1 Úvod V současné době se klade velký důraz na pr{ci s informacemi. V podnikovém prostředí často pracují zaměstnanci s mnoha aplikacemi, které potřebují během plnění svých pracovních úkolů. Port{ly jsou platformou, kter{ umožňuje koncentrovat informace na jedno místo a tím usnadnit přístup k informacím a orientaci v nich, čímž zvyšují produktivitu pr{ce. Zaměstnanci často pracují s všelijakými úkoly, které jsou jim přidělov{ny různými kan{ly. Zaměstnanec tak čelí každý den z{plavě úkolů, jež musí nějakým způsobem přijmout, roztřídit, napl{novat a nakonec vykonat. Aby byla jeho pr{ce efektivní, musí být schopen odlišit úkoly důležité a urgentní od úkolů, které jsou méně důležité nebo nespěchají. Potřebuje mít nad svými úkoly přehled. M{–li přehled, může si na každý den a týden stanovit pl{n, m{ kontrolu nad svým časem, ve svých úkolech se orientuje a úkoly neztr{cí. Spr{vu úkolů již řeší mnoho aplikací, ale jejich použív{ní může skončit brzy tak, že uživatele přestane bavit nepohodlné přepisov{ní údajů o úkolu ze všech systémů, které použív{, a aplikace pro spr{vu úkolů upadne v zapomnění. Důležité je úkoly agregovat automaticky a zaměstnanci tak poskytnout již připravené pracovní prostředí. Port{ly samotné jsou především agregační platformou, kter{ poskytuje personalizovaný přístup. Port{l m{ každý uživatel šitý na míru, zobrazují se mu pr{vě ty informace, které využív{, a dokonce si může modifikovat i vzhled dle svých požadavků a preferencí. V souladu s konceptem port{lu jako agregační platformy s velkou variabilitou využití je také zad{ní řešené v r{mci praktické č{sti této pr{ce. Vyvíjen{ portletov{ aplikace agreguje úkoly z různých zdrojů tak, aby je uživatel mohl mít přehledně zobrazené na jedné str{nce. Zdroji úkolů mohou být různé systémy používané v podniku, například systém pro řízení projektů, účetní systém nebo třeba systém pro automatizaci firemních procesů. Navíc aplikace podporuje ukl{d{ní úkolů v lok{lní datab{zi. Společnost tak může využít výhod této sady portletů i samostatně, pokud nepotřebuje agregovat úkoly z dalších systémů. V r{mci datab{ze lze úkoly vytv{řet, editovat, delegovat na jiného zaměstnance a při nedodržení termínu zpracov{ní se úkol reportuje určené zodpovědné osobě. Aplikace je velmi variabilní, manažer si tak může například na jednu str{nku umístit několik portletů, z nichž v každém bude mít zobrazené úkoly jednoho ze svých podřízených. Může chtít vidět všechny informace o úkolech, nebo například jen jejich n{zev a aktu{lní stav. Někdo jiný naopak nepotřebuje sledovat vývoj úkolů jiných uživatelů, ale často jsou mu úkoly přidělov{ny. Tato osoba bude mít na str{nce portlet se svými úkoly a str{nku si může nastavit například tak, že v jednom portletu bude mít zobrazené pouze úkoly s vysokou prioritou a blížícím se požadovaným datem ukončení, ve druhém úkoly s vysokou prioritou a vzd{lenějším datem, v dalším s nižší Úvod 2 prioritou a blízkým datem a v posledním portletu by měl úkoly, které nemají ani vysokou prioritu, ani nespěchají. Takové uspoř{d{ní respektuje rozložení do čtyř kvadrantů podle matice pl{nov{ní času, jak ji popisuje Stephen Covey. 1 V první kapitole pr{ce se věnuji port{lům, co to port{l je a jaké existují typy port{lů. Vymezuji podnikový port{l a blíže popisuji port{ly Liferay a WebSphere. Ve druhé kapitole píši o portletovém kontejneru a portletech. Definuji, co to portlet je a jak se liší od servletu. Popisuji, jaké vlastnosti m{ portletov{ aplikace a jaké existují portletové specifikace. V poslední č{sti druhé kapitoly se věnuji životnímu cyklu portletu. Ve třetí kapitole jsem se zabývala průzkumem aplikací pracujících s úkoly. Tento průzkum byl důležitý pro zjištění, jaké aplikace v této oblasti existují a jaké nabízejí možnosti. Popsala jsem několik konkrétních aplikací a zhodnotila výhody a nevýhody jejich nasazení. Čtvrtou a p{tou kapitolu věnuji vyvíjené aplikaci. Nejdříve podrobně popíši chov{ní a možnosti aplikace, v p{té kapitole se věnuji již samotnému vývoji a detailněji popisuji č{sti, které jsem implementovala. 1 COVEY, Stephen R. 7 n{vyků vůdčích osobností pro úspěšný a harmonický život : n{vrat etiky charakteru. 1. vyd. Praha : Pragma, 1994. 329 s. ISBN 8085213419. s. 149 3 Kapitola 1 Port{l a port{lové technologie Port{l je obecně místo, které agreguje informace z různých zdrojů a prezentuje je jednotným způsobem. Všeobecně zn{mé jsou internetové port{ly, které poskytují služby široké veřejnosti. Běžně se setk{v{me také s port{ly st{tní spr{vy a samospr{vy zaměřenými například na dění v obci nebo kraji. Můžeme rozlišit port{ly horizont{lní a vertik{lní. Funkce horizont{lních port{lů spočív{ v tom, že soustřeďují informace z různých oblastí nebo jiných port{lů. Naopak vertik{lní port{ly jsou zaměřené na jednu oblast a té se věnují do hloubky, například jedno průmyslové odvětví nebo jeden trh. Port{ly lze také rozdělit podle toho, komu jsou prezentované informace určené. Existují port{ly Business-to-Business, sloužící pro komunikaci mezi firmami, d{le port{ly Business-to-Customer, které slouží pro z{kazníky společnosti – obvykle se jedn{ o prezentaci produktů, možnost jejich vyhled{v{ní, porovn{v{ní, popř. objedn{ní. Další kategorií jsou port{ly Business-to-Employee, jejichž z{kladní funkcí je poskytnout zaměstnancům společnosti na jednom místě data relevantní pro jejich pr{ci.2 Specifickou a také nejzn{mější kategorií jsou již zmíněné internetové port{ly, poskytují n{vštěvníkům služby vyhled{v{ní, emailu, zpr{v a další. Typickým příkladem internetového port{lu je například Seznam.cz, který uživatelům mimo jiné umožňuje zvolit si portletové aplikace dle vlastního výběru, nastavit jejich rozmístění a vybrat si motiv vzhledu. 1.1 Podnikový port{l Podnikový port{l umožní uživatelům – typicky zaměstnancům firmy – přistupovat k různým typům informací pomocí jednoho webového rozhraní. Port{l je webov{ str{nka, jejíž z{kladní komponentou jsou portlety. V podnikovém prostředí se port{ly využívají tak, že místo použív{ní několika samostatných aplikací je pro každou aplikaci v port{lu jeden nebo několik portletů. Port{l poskytuje uživateli funkcionalitu jednotného přihlašov{ní (single-sign-on), díky čemuž se uživatel nemusí zvl{šť přihlašovat do všech aplikací. Port{l také umožňuje informace vhodným způsobem agregovat a zvyšuje tím přehlednost. Z{kladním atributem port{lů je možnost 2 PHILLIP, Dane. Buzzle.com : Intelligent Life on the Web [online]. 2007 [cit. 2010-05-05]. Web Portals and Web Portals Types. Dostupné z WWW: . 1. PORT[L A PORT[LOVÉ TECHNOLOGIE 4 přizpůsobení – uživatel si může definovat vzhled port{lu a rozložení portletů. Také je důležit{ personalizace – uživateli jsou prezentov{na data relevantní pr{vě pro něj. Port{l mimo jiné poskytuje podporu pro nastavení různých úrovní uživatelských pr{v – od administrace port{lu až po nastavení, kterým uživatelům bude konkrétní portlet přístupný. V devades{tých letech nastal velký rozmach webových port{lů, na konci devades{tých let začaly vznikat také první podnikové port{ly a po roce 2000 již bylo na trhu mnoho podnikových port{lů od různých dodavatelů jako například IBM, Sun nebo Oracle. Port{ly byly ale implementov{ny velmi rozdílně a přejít od jednoho dodavatele port{lu k jinému bylo nemožné bez n{kladných úprav, bylo potřeba vyvíjet nové portlety pro každý port{l. Proto se vedoucí dodavatelé port{lových řešení spojili a v roce 2003 vznikla první port{lov{ specifikace JSR-168.3 Tato specifikace definovala rozhraní mezi port{lem a portlety. Portlety odpovídající této specifikaci je možné nasadit na všech port{lech podporujících JSR-168. 1.1.1 Liferay port{l Liferay 4 je podnikový port{l založený na Java EE technologii. Je možné ho používat s různými aplikačními servery, ke stažení je nabízen již v balíku s vybranými aplikačními servery. Liferay port{l ve verzi Community Edition je nabízen pod open-source licencí MIT. Existuje ještě verze Enterprise Edition, kter{ je nabízena pod komerční licencí. Je k ní možné zakoupit podporu a důraz je u této verze kladen zejména na stabilitu. 5 Po instalaci port{lu je dostupných více než šedes{t portletů z různých oblastí a pro vývoj vlastních portletů jsou podporov{ny obě portletové specifikace JSR-168 a JSR-286 (od verze 5.1).6 Liferay port{l je navržen tak, aby podporoval service-oriented architecture (SOA), což usnadňuje integraci s jinými systémy používanými v podniku. Ihned po instalaci je Liferay lokalizov{n do dvaceti dvou jazyků. Administr{toři port{lu mají možnost nastavit uživatelům různé uživatelské role, podle nichž se řídí jejich přístupov{ pr{va. Liferay je navržen tak, aby byla spr{va str{nek a portletů jednoduch{ a aby bylo možné snadno přid{vat portlety nebo měnit rozložení str{nky, port{l podporuje i změny rozložení tažením myši (drag and drop). Uživatelé mají 3 Java Community Process. JSR-168 Portlet Specification. 2003 [online]. [cit. 2010-05-10]. Dostupné z WWW: . s. 1 4 5 Liferay : Enterprise. Open source. For Life. [online]. 2010 [cit. 2010-05-10]. Portal Features. Dostupné z WWW: . 6 JUAN, Jonas X. Liferay Portal 5.2 Systems Development. Birmingham : Packt Publishing, 2009. 551 s. ISBN 978-1-847194-70-1. s. 45 1. PORT[L A PORT[LOVÉ TECHNOLOGIE 5 k dispozici vlastní webový prostor, který si sami mohou přizpůsobit a definovat, kdo m{ pr{vo vidět obsah. Liferay port{l nabízí také svůj vlastní systém pro spr{vu obsahu (CMS). Každ{ komunita m{ k dispozici svou galerii a knihovnu dokumentů. Liferay podporuje integraci s kancel{řským balíkem Microsoft Office®, což uživatelům umožní automaticky promítnout změny v souboru na lok{lním disku do souboru uloženého v CMS. Uživatelé mají možnost jednoduše vytv{řet a publikovat webové str{nky. Liferay m{ také funkce pro podporu interakce mezi uživateli, které zahrnují například instant messaging, email, sdílený kalend{ř, blogy, n{stěnky a průzkumy. 1.1.2 WebSphere port{l WebSphere Portal 7 je produktem společnosti IBM. Tento port{l se prod{v{ v několika sad{ch, každý balík obsahuje nejen aplikační server, ale také DB2 datab{zi, LDAP, šablony pro webové str{nky a další. WebSphere port{l podporuje obě portletov{ rozhraní JSR-168 a JSR-286 a tato rozhraní rozšiřuje o další možnosti, jejichž použití je ale na úkor přenositelnosti portletu. IBM m{ pro vývoj portletů do WebSphere port{lu vlastní speci{lní vývojové prostředí WebSphere Portlet Factory (WPF). WPF umožňuje tvorbu portletů bez znalosti portletového API, portlet se vyvíjí skl{d{ním předpřipravených komponent, tzv. builderů. Ty stačí snadno nakonfigurovat vyplněním formul{ře. WPF výrazně snižuje n{klady na tvorbu portletů a umožňuje vývoj portletů i osob{m bez předchozí zkušenosti s programov{ním. 7 6 Kapitola 2 Portletový kontejner a portlety Portletový kontejner je běhové prostředí pro portlety. V portletovém kontejneru se vytvoří instance portletů a nach{zí se v něm během svého celého životního cyklu. Portletový kontejner zajišťuje před{v{ní požadavků port{lu jednotlivým portletům a poté před{ní odpovědi portletu zpět port{lu. Port{lové preference, tedy nastavení portletů, ukl{d{ také portletový kontejner. Port{l převezme obsah portletů od portletového kontejneru a sestaví výslednou str{nku pro uživatele. Port{l se star{ o rozložení, agregaci, personalizaci a zajištění single-sign-on přístupu pro uživatele. Port{l a portletový kontejner mohou být dohromady jedna komponenta, nebo mohou být oddělené. Portlety jsou softwarové komponenty port{lu, typicky tvoří port{lovou str{nku několik nepřekrývajících se oken – portletů. Portlety generují fragmenty kódu ve značkovacím jazyce (např. HTML, XHTML, WML), které jsou port{lem zasazeny na spr{vné místo zdrojového kódu celé str{nky. Každý portlet m{ několik módů: view mód, edit mód a help mód. Navíc je možné vytvořit i vlastní nový mód. View mód je z{kladní mód portletu, který zobrazuje portletem prezentovaný obsah, musí ho mít každý portlet. Edit mód je str{nka portletu, kter{ slouží uživateli k nastavení možností týkajících se daného portletu. Help mód poskytuje n{povědu k uživatelskému rozhraní portletu, stejně jako edit mód, není povinný. Okno portletu může být v jednom ze tří stavů: minimalizované (je vidět jen lišta portletu), maximalizované (portlet je zobrazený přes celou str{nku) a norm{lní (portlet m{ velikost dle obsahu a umístění). Portletové aplikace jsou standardní J2EE aplikace, které obsahují portletové třídy a deskriptor portletové aplikace portlet.xml. 2.1 Portlet a servlet Portlety jsou v mnohém podobné servletům, ale jsou mezi nimi jisté rozdíly. Podobnost je zejména v tom, že portlety stejně jako servlety jsou webové komponenty, jsou řízeny a obsluhov{ny kontejnerem, generují dynamický obsah a komunikují s uživatelem na b{zi požadavku a odpovědi. Portlety se ale od servletů liší tím, že generují pouze fragmenty kódu značkovacího jazyka, interakce s portlety probíh{ přes port{l, portlet může být na jedné str{nce mnohokr{t, portlet m{ předdefinované módy a stavy portletového okna a portletový požadavek m{ několik typů, podle nějž je zpracov{v{n. Portlety mají také na rozdíl od servletů přístup k dalším datům 2. PORTLETOVÝ KONTEJNER A PORTLETY 7 souvisejícím především s údaji uživatelů o přizpůsobení a personalizaci. Kvůli těmto rozdílům bylo potřeba oddělit portlety od servletů a proto vznikla specifikace pro portlety. 8 2.2 Portletové specifikace JSR-168 a JSR-286 V současné době existují dvě portletové specifikace, starší JSR-168 (portlet verze 1.0) a novější JSR-286 (portlet verze 2.0). Portlet podle JSR-168 podporuje dvě f{ze zpracov{ní požadavku, jsou to processAction() a render(). Podporuje tři módy portletu (view, edit a help mode) a také tři stavy okna portletu (minimalizované, maximalizované a norm{lní). Umožňuje ukl{dat údaje o vzhledu portletu do tzv. render parametrů a podporuje relace (sessions). JSR-286 vznikla díky potřeb{m zjednodušení a vylepšení původní specifikace, je zpětně kompatibilní a přinesla některé nové možnosti. Portlety v2.0 podporují meziportletovou komunikaci formou událostí (events) a veřejných render parametrů. Nově je také zavedena metoda serveResource(). Díky podpoře ud{lostí v JSR-286 mohou portlety odesílat a přijímat ud{losti a na z{kladě nich měnit svůj stav nebo posílat další ud{losti. Veřejné render parametry umožňují vz{jemnou komunikaci portletů prostřednictvím sdíleného parametru. Ud{losti i render parametry je třeba definovat v portlet.xml deskriptoru a u popisu portletu přidat element, který značí, že konkrétní portlet ud{lost nebo render parametr podporuje. Již zmíněn{ metoda serveResource() slouží pro obsluhov{ní dynamicky generovaných zdrojů, například pokud portlet využív{ technologii AJAX. Další změny se týkají také lokalizace, zatímco ve v1.0 bylo možné lokalizovat portlety pouze v deskriptoru portlet.xml pomocí atributu xml:lang, ve v2.0 je možné ukl{dat lokalizované hodnoty ve zvl{štních souborech (resource bundles). Použití metod render() a processAction() je zjednodušeno díky možnosti použití anotací. Pro metodu render() m{ anotace tvar @RenderMode(name = ‘’nazevModu’’), resp. pro processAction() @ProcessAction(name = ‚nazevAkce‛). V render f{zi, resp. v action f{zi, se proch{zejí nejdříve anotované metody a pokud příslušn{ metoda není nalezena, spouští se standardně doView(), doEdit() nebo doHelp(), resp. processAction().9 8 Java Community Process. JSR-286 Portlet Specification. [online]. 2007 [cit. 2010-05-10]. Dostupné z WWW: . s. 29–31 9 Java Community Process. JSR-286 Portlet Specification. [online]. 2007 [cit. 2010-05-10]. Dostupné z WWW: . s. 19 2. PORTLETOVÝ KONTEJNER A PORTLETY 8 2.3 Portletov{ aplikace Portletové aplikace jsou webové aplikace postavené na J2EE, které obsahují deskriptory web.xml a portlet.xml. Protože každ{ portletov{ aplikace je také webovou aplikací, je potřeba, aby se v adres{ři WEB-INF nach{zel deskriptor webové aplikace web.xml (stejně jako u servletu), v něm jsou údaje nesouvisející přímo s portletem. Deskriptor portletové aplikace portlet.xml by měl být umístěn také v adres{ři WEB-INF, tento soubor obsahuje z{kladní informace o portletech této aplikace. Obsah souboru portlet.xml může vypadat například takto (portlety v2.0): Task list portlet1 Task list portlet1.portlet1 0 text/html VIEW EDIT cs en portlet1.messages Task list Task list taskID taskID xsi:taskID Počet elementů odpovíd{ počtu portletových tříd aplikace, uvnitř je několik elementů (existují i další, zde popíši několik z{kladních elementů z příkladu výše):  je n{zev portletu;  je zobrazovaný titulek portletu;  určuje, kter{ portletov{ třída patří k tomuto portletu;  v tomto elementu jsou definov{ny podporované módy;  je informace o podporované jazykové variantě;  řík{, který soubor se m{ použít při lokalizaci;  obsahuje informace o portletu pro vyhled{v{ní a zobrazov{ní v nabídk{ch port{lu; 2. PORTLETOVÝ KONTEJNER A PORTLETY 9  určuje render parametry, které tento portlet podporuje. D{le je v ještě definov{n veřejný render parametr. Element určuje identifik{tor parametru, pomocí nějž se k němu i přistupuje, je pak glob{lní jméno parametru se jmenným prostorem. Pokud by aplikace pracovala s ud{lostmi, jejich definice by v portlet.xml byla obdobn{. Adres{ř WEB-INF může také obsahovat další xml deskriptory, které se vztahují ke konkrétnímu port{lu. Například pro Liferay port{l je to liferay-portlet.xml, ve kterém je seznam portletů a informace, zda jsou aktivní, a liferaydisplay.xml, který obsahuje n{zev kategorie portletů a titulky portletů. Portletové třídy musí implementovat rozhraní Portlet. Aby nebylo nutné předefinovat všechny metody v tomto rozhraní, použív{ se často abstraktní třída GenericPortlet implementující rozhraní Portlet. Vytvoří se rozšíření této třídy, nov{ třída by měla buď obsahovat jednu z anotací @ProcessAction, @ProcessEvent, @RenderMode nebo předefinovat některé z metod:  processAction() – slouží k obsluze požadavků na akci;  doView() – zobrazení módu view portletu;  doEdit() – zobrazení edit módu;  doHelp() – zobrazení n{povědy v help módu;  init() a destroy() – metody pro spr{vu zdrojů, které jsou potřeba v průběhu životního cyklu portletu.10 2.3.1 Portlety a model-view-controller Portletov{ specifikace je navržena tak, aby se portletov{ aplikace mohla řídit n{vrhovým vzorem model-view-controller (MVC), který předepisuje oddělení datového modelu, uživatelského rozhraní a řídicí logiky. V portletu jsou striktně odděleny metody render() a serveResource(), které slouží pouze pro generov{ní kódu uživatelského rozhraní od metod processAction() a processEvent(), které slouží ke změn{m stavů. Jako model se u portletové aplikace obvykle použív{ instance třídy JavaBean (popř. enterprise JavaBean).11 Funkci komponenty controller zde zast{v{ instance portletu. Komponenta view, kter{ generuje fragment str{nky, je zastoupena většinou technologií JSP (Java Server Pages). 10 Java Community Process. JSR-286 Portlet Specification. [online]. 2007 [cit. 2010-05-10]. Dostupné z WWW: . s. 45 11 MARTINÍK, Ivo. Konference Tvorba Softwaru [online]. 2004 [cit. 2010-05-10]. Technologie model-view-controller a její uplatnění při n{vrhu a implementaci port{lových řešení. Dostupné z WWW: . s. 141 2. PORTLETOVÝ KONTEJNER A PORTLETY 10 2.4 Životní cyklus portletu Životní cyklus portletu se skl{d{ ze tří f{zí:  vytvoření portletu;  zpracov{v{ní požadavků uživatele;  odstranění portletu a vyčištění paměti (garbage collection). 2.4.1 Vytvoření portletu Vytvoření portletu je nejkomplexnější f{ze, zahrnuje tři kroky. Prvním krokem je zav{dění tříd. Portletové aplikace se často skl{dají z mnoha tříd a knihoven mimo portletové třídy a je třeba, aby měl uživatel prostřednictvím portletu přístup k této aplikační logice. Podle specifikace je nutné, aby byl použit stejný zavaděč tříd (classloader) při nahr{v{ní portletové třídy i dalších tříd. Atributy tříd budou inicializované na svých výchozích hodnot{ch. 12 N{sledujícím krokem je vol{ní konstruktoru portletové třídy. Podle specifikace je nutné, aby portletov{ třída měla konstruktor bez parametrů. Vol{ní konstruktoru a tedy i vytvoření instance portletové třídy nastane buď při spuštění portletové aplikace portletovým kontejnerem, nebo je–li portlet potřebný pro obsloužení požadavku uživatele. Vytvoření instance portletu až při potřebě užití umožňuje šetřit zdroje, zvl{ště pokud portlet není využív{n často, ale při prvním požadavku uživatele na tento portlet bude prodloužena doba obsloužení tohoto požadavku. Třetím krokem vytvoření portletu je inicializace. Portletový kontejner inicializuje portlet poté, co byla vytvořena instance portletu. Nyní je zavol{na metoda init(), ve které se provede úvodní nastavení, tato metoda je na každé instanci portletu vol{na pr{vě jednou. Typicky se tato metoda použív{ pro nastavení připojení k dalším zdrojům – například pro nastavení datab{zového připojení. Metoda init() m{ jako parametr objekt, který implementuje rozhraní PortletConfig. Tento objekt je pro portlet jedinečný a obsahuje přístup k inicializačním parametrům portletu a k lokalizačnímu balíčku (ResourceBundle) portletu. Před zavol{ním init() není portlet považov{n za aktivní, proto nebudou vol{ny další metody, které předpokl{dají již inicializovaný portlet a mohou potřebovat například připojení k datab{zi. 2.4.2 Zpracov{v{ní požadavků uživatele Po inicializaci je portlet aktivní a připraven plnit požadavky uživatelů. Tyto požadavky mohou být dvou typů – požadavek na vykreslení portletu ve st{vajícím stavu (render()) a požadavek na změnu stavu portletu (processAction()). Když uživatel 12 LINWOOD, Jeff; MINTER, Dave. Building Portals with the Java Portlet API. USA : Apress, 2004. 393 s. ISBN 1-59059-284-0. s. 44 2. PORTLETOVÝ KONTEJNER A PORTLETY 11 vyvol{ požadavek na změnu stavu portletu, nejdříve se zavol{ příslušn{ metoda processAction() portletu a poté se vykon{ render() na všech portletech na stejné str{nce. Pokud uživatel vyvol{ jen požadavek render() na jednom portletu, render() je zavol{no i na ostatních portletech na str{nce. 2.4.3 Odstranění portletu a garbage collection Metoda destroy(), sloužící k odstranění instance portletu, bude zavol{na až po ukončení všech vl{ken inicializace a obsluhy požadavků. Portletový kontejner zavol{ metodu destroy(), není–li portlet nad{le potřeba. Poté tzv. garbage collector odstraní portletový objekt z paměti. Metoda destroy() je zavol{na na každé instanci, proto je možné do ní napsat kód oznamující ostatním č{stem aplikace, že je portlet nedostupný. N{sledující obr{zek zobrazuje životní cyklus portletu a metody, které jsou v jeho průběhu vol{ny. Obr{zek 1 – Životní cyklus portletu 12 Kapitola 3 Přehled aplikací pro spr{vu úkolů V této kapitole se věnuji popisu a srovn{ní aplikací pro spr{vu úkolů. Souč{stí zad{ní praktické č{sti této pr{ce je vytvořit portlet nebo sadu portletů pro spr{vu úkolů a z toho důvodu považuji za důležité prozkoumat již existující aplikace a zjistit jaké funkcionality poskytují. Bylo vybr{no několik zn{mých a používaných aplikací, které se spr{vou úkolů zabývají. Nejdříve popisuji, jak aplikace funguje, jaké je uživatelské rozhraní a také zda nabízí nějaké možnosti interakce mezi uživateli, například před{v{ní úkolů jiné osobě. Na konci popisuji, jaké jsou z mého pohledu výhody a nevýhody dané aplikace. V této kapitole popisuji i systém Jira, což je systém pro řízení projektů, protože pr{ce s úkoly se v něm také vyskytuje. Zde se zaměřím na systém Jira spíše jako možný zdroj úkolů pro vyvíjené portlety. Konektor pro systém Jira byl v r{mci této pr{ce i implementov{n, popis implementace se nach{zí v praktické č{sti pr{ce. 3.1 Outlook Asi nejzn{mější aplikací pro spr{vu úkolů je Outlook 13 z kancel{řského balíku Microsoft Office (ale je možné zakoupit jej i samostatně). Zatím je aplikace Outlook dostupn{ pouze pro operační systém Windows, od verze 2011 ji bude možné využívat i na Mac OS X. Outlook poskytuje mnoho funkcionalit, blíže se nyní podív{m na spr{vu úkolů. Outlook umožňuje vytv{řet úkoly, které mají definov{n předmět, datum zah{jení a termín splnění, stav (výběr z přednastavených hodnot), prioritu (nízk{, střední, vysok{), vlastníka úkolu, opakov{ní, kategorii a indikaci kolik procent úkolu je hotovo. Je také možné nastavit na určitý čas upomínku a vytv{řet úkoly, které jsou přidělené jiným uživatelům. Ten komu je úkol přidělen se stane dočasným vlastníkem úkolu a může ho přijmout, odmítnout nebo přidělit někomu dalšímu. Pouze vlastník úkolu může prov{dět změny a pokud je úkol změněn, aktualizují se všechny kopie úkolu i u jiných osob. 14 Synchronizace jak úkolů, tak dalších funkcí, může probíhat pomocí Microsoft Exchange Server. Úkoly lze filtrovat a vyhled{vat podle různých kritérií. Vlastnosti úkolu lze měnit nejen v detailu úkolu, ale i v příslušném sloupci při zobrazení seznamu úkolů. Samozřejmostí je podpora mnoha jazykových variant a 13 14 Microsoft Office Online [online]. 2010 [cit. 2010-05-10]. Microsof Office Outlook. Dostupné z WWW: . 3. PŘEHLED APLIKACÍ PRO SPR[VU ÚKOLŮ 13 kontrola pravopisu. D{le je výhodou možnost nastavení zasíl{ní informací o úkolu emailem. Outlook nabízí mnoho možností, ale nevýhodou je jeho nezanedbateln{ cena a možnost použití pouze na platformě Windows. Navíc velké množství různých funkcí může uživateli znesnadňovat orientaci. Obr{zek 2 – Zad{v{ní úkolu v aplikaci Outlook 3.2 Remember the Milk (RTM) Jedn{ se o jednoduchou webovou aplikaci pro spr{vu úkolů, použív{ní této aplikace je zdarma. Existuje také ve verzi Pro, kter{ slouží pro použití na Blackberry, Windows Mobile, iPhone nebo android, tato verze je placen{. Přes jednoduché rozhraní nabízí RTM mnoho možností nastavení úkolů, v horní liště je výběr z několika seznamů úkolů, úkol lze označovat tagy, nastavovat prioritu, lokaci a další, jak je patrné v pravém panelu z n{sledujícího obr{zku. Zajímavým způsobem je řešené zad{v{ní data splnění – do formul{řového pole lze zapsat datum v různých tvarech nebo například „zítra“ či n{zev dne v týdnu a automaticky je doplněno příslušné datum. Úkoly lze řadit podle priority, data splnění nebo n{zvu. U úkolu je možné také nastavit sdílení s jiným uživatelem služby RTM, k úkolu pak mají přístup oba uživatelé a mohou připisovat pozn{mky. RTM podporuje také pr{ci v offline režimu a zasíl{ní 3. PŘEHLED APLIKACÍ PRO SPR[VU ÚKOLŮ 14 upomínek různými způsoby. Navíc je možn{ synchronizace s Windows Mobile a Blackberry, prov{z{ní se soci{lními sítěmi Twitter a Facebook a s Google aplikacemi. 15 Hlavní výhodou je intuitivní a jednoduché použití, inovativní design aplikace a možnost využití z{kladní verze zdarma. Obr{zek 3 – úkol v RTM 3.3 Rainlendar Rainlendar 16 je prim{rně kalend{ř na plochu, který umožňuje také zad{v{ní ud{lostí k jednotlivým dnům a vedení seznamu úkolů. Rainlendar je možné použít na Windows, Mac OS X a Linuxu. Existují dvě verze aplikace Rainlendar, verze Lite je zdarma a verze Pro je placen{. Rozdíl mezi variantami spočív{ v tom, že verze Pro navíc umožňuje sdílení kalend{řů po síti, podporu Outlooku, Google Calendar a Remember the Milk. Program je malý a nen{ročný, pro přizpůsobení existuje mnoho variant vzhledu. Ud{losti a úkoly se zad{vají vyplněním formul{ře s údaji, které jsou patrné na obr{zku níže. Rainlendar podporuje zad{v{ní opakovaných úkolů a ud{lostí, upomínky a nastavení kategorií. Aplikace podporuje nastavení různých ikon 15 16 3. PŘEHLED APLIKACÍ PRO SPR[VU ÚKOLŮ 15 a barev úkolům, mohou být také vyznačené u příslušného data v kalend{ři. Lze vybrat řazení podle jednotlivých atributů úkolu, také lze definovat, které stavy úkolu se mají zobrazit. Výhodou je možnost přizpůsobení vzhledu a minimalistický design, ten však může působit nepřehledně při velkém množství ud{lostí a úkolů. Aplikace ve verzi Lite nepodporuje ž{dné možnosti před{v{ní či sdílení úkolů. Možnosti filtrov{ní, řazení a editace nejsou na úvodní str{nce, je třeba se nejdříve dostat do příslušné nabídky. Obr{zek 4 – Rainlendar kalend{ř a zad{v{ní úkolu 3.4 IBM WebSphere Portal Unified Task List portlet Unified Task List portlet je produkt společnosti IBM určený pro IBM WebSphere Portal. Portlet agreguje úkoly a aktivity z různých systémů do jednoho uživatelského rozhraní. Uživatelé WebSphere Port{lu mohou vidět všechny úkoly které potřebují a mohou je označit jako dokončené. V z{kladní verzi obsahuje tento portlet pouze dva zdroje úkolů – uk{zkový zdroj, který úkoly načít{ z XML souboru, a druhým zdrojem je IBM WebSphere Process Server, z něhož lze úkoly v tomto portletu pouze 3. PŘEHLED APLIKACÍ PRO SPR[VU ÚKOLŮ 16 zobrazovat. Podle dokumentace je možné vyvíjet další poskytovatele úkolů a napojit tak portlet na další systémy. 17 Nevýhodou tohoto řešení je, že je určené pouze pro WebSphere Portal a zdrojem úkolů je WebSphere Process Server, výhodou je možnost rozšířit portlet o napojení na jiné zdroje. Tato aplikace je asi nejblíže aplikaci vyvíjené v této pr{ci, ale vyvíjené řešení je sada portletů podle specifikace JSR-286, a je tedy přenositeln{ na různé port{ly. D{le také nov{ aplikace může fungovat i samostatně bez dalších zdrojů úkolů, protože souč{stí je implementace pro datab{zi. Úkoly ve vyvíjené aplikaci lze také přid{vat, upravovat, delegovat atd. Portlet od společnosti IBM je navíc dostupný pouze v anglickém jazyce, vyvíjený portlet je lokalizov{n v českém a anglickém jazyce a snadno lze přidat lokalizaci i do dalších jazyků. 3.5 Jira Jira18 je n{stroj pro projektové řízení od firmy Atlassian Software Systems. Je to aplikace zaměřen{ na efektivní řízení a sledov{ní životního cyklu projektů, úkolů a požadavků v organizaci. Jira je určen{ zejména pro týmy vyvíjející software na zvýšení kvality kódu a rychlosti vývoje. Jira je velmi komplexní aplikace, ale z{roveň je její uživatelské rozhraní jednoduché a snadno se použív{ i bez předchozí znalosti. Kolem systému Jira se také pohybuje velk{ komunita uživatelů, kteří vyvíjejí různ{ rozšíření. Ačkoliv je Jira propriet{rní software, kód systému Jira je open-source. Výhodou je také integrace s dalšími produkty firmy Atlassian, například s podnikovou wiki Confluence. V systému Jira lze vytvořit úkol vyplněním formul{ře (na obr{zku níže), každý problém musí být přiřazený k již vytvořenému projektu. U úkolu se d{le eviduje typ problému a priorita, u nichž je několik předdefinovaných hodnot, ale lze přidat i vlastní. Z osob se u každého problému ukl{d{ zadavatel a přiřazený. Každý projekt m{ definovaného člověka, komu se automaticky problémy přiřazují, nestanoví–li zadavatel problému jinak. Jira umožňuje přidat k úkolu i přílohu formou souboru. Každý problém m{ také stav, ve výchozím nastavení proch{zí problém v průběhu životního cyklu stavy dle obr{zku níže, výchozí stav je Open. 17 IBM Lotus and WebSphere Portal Business Solutions Catalog [online]. 2010 [cit. 2010-05-10]. IBM WebSphere Portal Unified Task List portlet . Dostupné z WWW: . 18 3. PŘEHLED APLIKACÍ PRO SPR[VU ÚKOLŮ 17 Obr{zek 5 – Jira stavy Jira m{ od verze 3.0 integrov{n z{suvný modul RPC, pomocí kterého je možné vzd{leně přístupovat k systému Jira přes SOAP a XML–RPC, což může sloužit k získ{v{ní úkolu ve vytv{řeném portletu. 3. PŘEHLED APLIKACÍ PRO SPR[VU ÚKOLŮ 18 Obr{zek 6 – Vytvoření problému v Jira Obr{zek 7 – Vytvoření problému v Jira 2 19 Kapitola 4 Portlet pro seznam úkolů 4.1 Rozdělení vývoje Tato bakal{řsk{ pr{ce je řešena v r{mci průmyslového partnerství společnosti IBA CZ s Fakultou informatiky Masarykovy univerzity. Implementaci projektu řeším společně s Ivou Ž{kovou, protože implementační č{st přesahuje rozsah jedné bakal{řské pr{ce. Projekt byl rozdělen na dvě č{sti a d{le v kapitole vývoj se podrobněji zabýv{m pouze č{stí, kterou jsem řešila. Obr{zek 8 – architektura a rozdělení vývoje 4. PORTLET PRO SEZNAM ÚKOLŮ 20 Mou č{stí pr{ce bylo vytvořit konektor pro systém Jira, aby se vyvíjen{ aplikace mohla na systém Jira napojit a získ{vat z ní data. D{le jsem se zabývala vytvořením portletu pro seznam úkolů uživatele, pro přid{v{ní a editaci úkolu, portletu pro aktu{lní ozn{mení a n{vrhu vizu{lní str{nky celé portletové aplikace pomocí kask{dových stylů. Mojí č{stí pr{ce byla i implementace akcí, které lze s úkoly prov{dět (například maz{ní, delegov{ní, atd.). Na úvodní str{nce portletu pro seznam úkolů a pro úkoly jiných osob je implementov{n, s pomocí technologie AJAX, výběr akcí, které jsou u vybraných úkolů povoleny. Také jsem řešila podporu úkolů ke schv{lení (například schv{lení dovolené). Tyto úkoly se liší tím, že se jedn{ pouze o rozhodnutí zodpovědné osoby, kter{ úkol schv{lí nebo zamítne, zatímco standardní úkoly jsou činnosti, které předpokl{dají určitý potřebný čas na své splnění. Č{sti implementace, které řešila Iva Ž{kov{ jsou: konektor implementující backend nad lok{lní datab{zí, portlet pro úkoly jiných osob, lokalizace do českého a anglického jazyka, agregace úkolů a jejich str{nkov{ní, filtrov{ní úkolů podle nastavených kritérií v edit módu portletu pro seznam úkolů a portletu pro úkoly jiných osob, zobrazení historie úkolů a automatick{ eskalace při nesplnění úkolu. 4.2 Popis aplikace Aplikace vyvíjen{ jako praktick{ souč{st této pr{ce se skl{d{ ze čtyř portletů. V prvním portletu se zobrazují úkoly, které řeší pr{vě přihl{šený uživatel port{lu. Druhý portlet zobrazuje přehled nad úkoly jiných uživatelů, nach{zejí se tam tři sekce: úkoly, které jsem zadal, úkoly za něž jsem zodpovědný a úkoly, které řeší moji podřízení. Třetí portlet slouží pro přid{v{ní a editaci úkolů a čtvrtý portlet zobrazuje aktu{lní ozn{mení týkající se úkolů. 4.2.1 Portlet pro seznam úkolů Zde jsou zobrazov{ny úkoly, které řeší pr{vě přihl{šený uživatel port{lu. Na úvodní str{nce portletu je zobrazena tabulka s úkoly, u každého úkolu jsou zobrazené údaje, které si uživatel zvolí. Úkol m{ také na pravé straně vlastní označovací políčko (checkbox) sloužící pro výběr akce, kterou si přeje uživatel s úkolem udělat. Akce lze prov{dět hromadně s několika úkoly z{roveň označením úkolů a výběrem akce v roletovém menu dole. Portlet dovolí vybrat jen ty akce, které podporují všechny vybrané úkoly, pokud tedy některý úkol přes portletové rozhraní podporuje pouze zobrazení, nelze vybrat například akci maz{ní. D{le se tam nach{zejí odkazy, kterými mohu označit všechny nebo naopak ž{dné úkoly, mohu vybrat k označení jen standardní úkoly nebo úkoly ke schv{lení (úkoly jsou rozděleny do těchto dvou skupin podle toho, zda úkol vyžaduje pouze rozhodnutí nebo provedení nějaké činnosti). Portlet podporuje str{nkov{ní, uživatel m{ kvůli přehlednosti a velikosti portletu zobrazený jen určitý počet úkolů a na další str{nky se dostane pomocí odkazů. 4. PORTLET PRO SEZNAM ÚKOLŮ 21 Po kliknutí na n{zev úkolu se uživatel dostane na str{nku s detailem, na níž vidí všechny údaje o vybraném úkolu a m{ možnost úpravy, smaz{ní, delegov{ní a u úkolů ke schv{lení také možnost schv{lení nebo zamítnutí. V detailu úkolu se lze podívat i na historii, kam se ukl{dají veškeré změny úkolu. Portlet podporuje také edit mód, v němž je možné nastavit filtrov{ní zobrazených úkolů. Uživatel si může vybrat ze seznamu, které kategorie, priority, stavy a typy chce zobrazit, může také definovat požadovaný rozsah dat vytvoření a ukončení a nastavit vzestupné či sestupné řazení úkolů podle n{zvu, data vytvoření, data ukončení a priority. Edit mód d{le obsahuje nastavení zobrazených sloupců na úvodní str{nce, povinné je pouze zobrazení n{zvu úkolu, zbytek sloupců si může uživatel zapnout či vypnout podle svých preferencí. Poslední č{stí str{nky s edit módem je nastavení údajů pro připojení k systému Jira, uživatel zde nyní zad{v{ uživatelské jméno a heslo, do budoucna je ale pl{nov{no automatické přihl{šení, pokud bude uživatel z{roveň přihl{šen v systému Jira. D{le se zad{v{ URL adresa WSDL souboru v systému Jira a číslo filtru, který musí být nastaven v systému Jira – tuto č{st pl{nujeme přesunout do samostatného konfiguračního portletu používaného pouze administr{torem, takže by tyto údaje nemusel nastavovat každý uživatel. Různé možnosti nastavení poskytují variabilitu použití portletu. Uživatel může mít například na str{nce v jednom portletu pouze úkoly ze systému Jira s nejvyšší prioritou, ve druhém portletu si může zobrazit jen úkoly ke schv{lení a v dalším může mít své osobní úkoly. Obr{zek 9 – Portlet pro seznam úkolů 4. PORTLET PRO SEZNAM ÚKOLŮ 22 Obr{zek 10 – Detail úkolu 4.2.2 Portlet pro přehled nad úkoly jiných osob Tento portlet slouží uživateli pro přehled nad úkoly, které řeší jiné osoby. V portletu se nach{zejí tři sekce: úkoly, které jsem vytvořil, za které jsem zodpovědný a úkoly, které řeší moji podřízení. Tento portlet funguje obdobně jako portlet pro seznam úkolů, ale pro každou sekci zvl{šť lze označovat úkoly a vybírat akce, také str{nkov{ní je v každé sekci. Detail úkolu je stejný jako u prvního portletu, využív{ i stejné JSP. I edit mód je podobný, ale navíc je možné preference nastavovat pro každou ze tří sekcí, lze nastavit, které sekce si uživatel přeje zobrazovat a úkoly kterých podřízených osob bude sledovat. Uživatel tak může mít na str{nce několik portletů a v každém sledovat úkoly jednoho ze zaměstnanců. 4.2.3 Portlet pro přid{v{ní a editaci úkolů Tento portlet obsahuje formul{ř pro přid{v{ní úkolu. Přid{v{ní je nyní implementov{no pouze pro lok{lní datab{zi, ale pokud bude vytvořen další zdroj, bude možné implementovat přid{v{ní i pro něj. Nahoře je výběr mezi standardním úkolem a úkolem na schv{lení. Při výběru úkolu ke schv{lení je zablokov{n výběr stavu, protože úkol ke schv{lení m{ jen tři možné stavy, buď ček{ na schv{lení, je schv{len, nebo je zamítnut, po vytvoření je vždy ve stavu ček{ní. Níže jsou k vyplnění další položky o úkolu, je nutné vyplnit pouze n{zev úkolu, popis není povinný. Při uložení úkolu proběhne validace vyplněných polí. Je–li úspěšn{, úkol se ukl{d{ do 4. PORTLET PRO SEZNAM ÚKOLŮ 23 datab{ze a uživateli se zobrazí str{nka s potvrzením uložení nebo s chybou. Chyba nastane v případě, že datab{ze není dostupn{ nebo nepovolí uložení úkolu. V edit módu portletu je možnost maz{ní a přid{v{ní nových kategorií. Při smaz{ní jsou zachov{ny úkoly s touto kategorií, ale při vytv{ření a úpravě úkolů se kategorie již nenabízí. Obr{zek 11 – Portlet pro přid{v{ní úkolů 4.2.4 Portlet pro aktu{lní ozn{mení V tomto portletu se zobrazují ozn{mení. Ozn{mení jsou generov{na při přid{ní nového úkolu, úpravě úkolu nebo pokud úkol překročí požadované datum splnění. Ozn{mení jsou zobrazov{na lidem, kterých se daný úkol týk{. V tomto portletu je zobrazeno datum změny a text ozn{mení. Do budoucna je pl{nov{na notifikace také jinými způsoby, například emailem nebo prostřednictvím technologie instant messaging. 4. PORTLET PRO SEZNAM ÚKOLŮ 24 Obr{zek 12 – Portlet pro ozn{mení 4.3 Struktura aplikace Účelem aplikace je agregace úkolů z různých zdrojů. Z toho vych{zí také takový n{vrh architektury, aby bylo možné v případě potřeby bez nutnosti velkých změn přidat poskytovatele pro další zdroj úkolů. Požadov{no bylo, aby aplikace mohla fungovat i samostatně a proto je souč{stí řešení konektor implementující backend sloužící pro připojení k datab{zi. Samotné připojení k datab{zi je řešené pomocí ORM Hibernate, aplikace tedy není omezen{ jen na jeden typ datab{ze. D{le je v aplikaci implementov{n backend pro napojení na systém řízení projektů Jira. Úkoly z tohoto systému jsou zobrazov{ny v seznamu mezi dalšími úkoly a po kliknutí na odkaz je zobrazena str{nka s detailem problému v systému Jira. Ve zdrojových kódech se nach{zí třída AggregationPoint, kter{ slouží k vol{ní jednotlivých konektorů dalších systémů a k získ{v{ní dat z nich. Portletové třídy tak komunikují pouze s touto třídou a nikoliv s konektory samotnými, tedy při přid{ní nového zdroje stačí vytvořit konektor a přidat jeho vol{ní a údaje o něm do třídy AggregationPoint. Aplikace je rozdělen{ do několika balíků podle poskytované funkcionality. Obsahuje balíky:  databaseBackend – obsahuje třídy sloužící pro připojení k datab{zi;  employeesBackend – zde se nach{zejí třídy získ{vající údaje o zaměstnancích, popř. podřízených;  jiraBackend – backend pro získ{v{ní úkolů ze systému Jira;  sharedPortletOperations – zde jsou třídy s operacemi, které je třeba využívat napříč několika portletovými třídami;  main – v tomto balíku jsou třídy a rozhraní využívané v celé aplikaci a properties soubory pro lokalizaci;  portlet1, portlet2, portlet3, portlet4 – balíky obsahující portletové třídy a příslušné soubory lokalizace. 4. PORTLET PRO SEZNAM ÚKOLŮ 25 4.3.1 Rozhraní Task Rozhraní Task je reprezentací úkolu ve vyvíjené aplikaci. Pro každý zdroj úkolů a příslušný backend je vytvořena implementace tohoto rozhraní. Po průzkumu dalších aplikací pro spr{vu úkolů, možných zdrojů úkolů a stanovení požadavků bylo rozhodnuto, že u úkolu budou evidov{ny n{sledující údaje: datum vytvoření, zadavatel, kategorie, požadované datum, priorita, osoba zodpovědn{ za úkol, řešitel, stav, typ úkolu (mohou být různé druhy úkolů, například úkol ke schv{lení), zda je úkol aktivní, n{zev a popis. 4.3.2 Rozhraní ProviderInterface ProviderInterface je rozhraní, které by měl implementovat každý konektor pro další systémy jako zdroje úkolů. Obsahuje operace, které portlety mohou nad úkoly prov{dět. 26 Kapitola 5 Vývoj portletové aplikace 5.1 Vývojové prostředí Aplikace byla vyvíjena v jazyce Java, pro portlety byla zvolena portletov{ specifikace JSR–286, protože je novější a zjednodušuje použití některých metod oproti JSR–168. Portlety se drží specifikace také z důvodu přenositelnosti a možného nasazení na různé port{ly. Při vývoji byl pro testov{ní použív{n port{l Liferay ve verzi 5.2.3 v balíku s aplikačním serverem Tomcat 6. Pro psaní zdrojového kódu bylo použito vývojové prostředí Netbeans se z{suvným modulem Portal Pack 3.0.3. 5.2 Použité technologie 5.2.1 SOAP SOAP (Simple Object Access Protocol) je protokol, který umožňuje přenos XML zpr{v a je z{kladem webových služeb. Webové služby obecně umožňují komunikaci systémů na různých platform{ch standardizovaným způsobem. XML webové služby je výhodné využít díky jejich jednoduchosti a díky tomu, že používají standardní síťové protokoly HTTP a TCP/IP. SOAP podporuje zasíl{ní zpr{v mezi dvěma aplikacemi a funguje na principu peer-to-peer. Většinou je ve webových služb{ch ale potřeba komunikace podle schématu požadavek-odpověď (request-response), jako je například vol{ní vzd{lených procedur (RPC). Rozhraní webové služby je pops{no pomocí WSDL (Web Services Description Language), což je standardní form{t pro popis webové služby. WSDL soubor s popisem je XML dokument, v němž jsou na abstraktní úrovni pops{ny operace a zpr{vy. 19 5.2.2 Apache Maven Apache Maven 20 je n{stroj pro spr{vu aplikací, který usnadňuje jejich sestavov{ní a tvorbu dokumentace. Sestavení se řídí informacemi z projektového deskriptoru 19 KOSEK, Jiří. Inteligentní podpora navigace na WWW s využitím XML [online]. Praha : VŠE, 2002. 72 s. Diplomov{ pr{ce. VŠE. Dostupné z WWW: . s. 28–32 20 5. VÝVOJ PORTLETOVÉ APLIKACE 27 pom.xml. Důležitou souč{stí tohoto deskriptoru jsou elementy , v nichž jsou definov{ny z{vislosti, tedy knihovny na kterých je projekt z{vislý a které je nutné st{hnout před sestavov{ním projektu. 5.2.3 JQuery JQuery 21 je JavaScriptový framework, který usnadňuje vyhled{v{ní elementů v DOM (Document Object Model), jejich modifikaci a vytv{ření. Výběr probíh{ na z{kladě výrazu v jazyce XPath, který umožňuje definovat relativní cestu od jednoho elementu k jinému elementu nebo atributu. Možný je i výběr více položek, pokud všechny splňují danou podmínku. Po vyhled{ní elementů s nimi lze pracovat pomocí různých funkcí, je možné například změnit hodnotu atributu, přidat další element apod. 21 5. VÝVOJ PORTLETOVÉ APLIKACE 28 5.3 N{vrh Obr{zek 13 – Případy užití Pro účely n{vrhu aplikace byly stanoveny jednotlivé případy užití. Diagram výše zobrazuje případy užití pro č{st aplikace vyvíjenou v této pr{ci. Portlet by měl být jednoduchý a poskytovat funkcionality, které spolu souvisejí. Proto byly případy z diagramu rozděleny třech portletů – do portletu pro seznam úkolů, portletu pro přid{v{ní a editaci a portletu pro ozn{mení. Přid{v{ní úkolu je specifick{ operace a úprava úkolu je velmi podobn{ přid{v{ní. Ve stejném portletu je také umístěna spr{va kategorií úkolů, protože uživatel bude chtít pravděpodobně přid{vat nebo upravovat kategorie při vytv{ření 5. VÝVOJ PORTLETOVÉ APLIKACE 29 úkolu. Z důvodu uživatelské přívětivosti ale uvažuji do budoucna o přid{ní možnosti úpravy a vytvoření úkolu také do portletu pro seznam úkolů. Čtení ozn{mení je pro uživatele spíše doplňkov{ možnost a kvůli zachov{ní jednoduchosti portletů je vhodné mít ozn{mení ve zvl{štním portletu. Ostatní případy užití jsou v jednom portletu, protože buď souvisejí se zobrazov{ním úkolů, nebo jsou to jednoduché operace, které nepotřebují zad{v{ní dodatečných dat. 5.4 Konektor pro systém Jira Jira backend poskytuje aplikaci úkoly ze systému Jira. V současné době vyvíjen{ aplikace podporuje pouze zobrazov{ní úkolů, ale je možné implementovat i přid{v{ní nových úkolů, bude–li to při nasazení vyžadov{no. Jira je dod{v{na se z{suvným modulem RPC (remote procedure call), který umožňuje omezený vzd{lený přístup. Je možné použít buď rozhraní SOAP nebo XMLRPC. Výrobce doporučuje v dokumentaci spíše použití rozhraní SOAP, pokud je to možné, protože je úplnější a prim{rně se na něj při vývoji zaměřují. 22 Služba SOAP je zajištěn{ pomocí r{mce webových služeb Apache Axis (Apache Axis framework). K systému Jira je vyvíjeno také rozhraní REST (Representational State Transfer), ale st{le je ve stavu vývoje a zatím není použitelné. Aby byla možn{ vzd{len{ komunikace se systémem Jira pomocí z{suvného modulu RPC, je třeba aby byl spr{vně nainstalovaný a povolený, a navíc se musí povolit akceptace vzd{lených vol{ní API. 5.4.1 SOAP klient K připojení k systému Jira slouží SOAP klient, který se star{ přímo o komunikaci se serverem, na kterém Jira běží. SOAP klient je aplikace, kter{ zajišťuje odesíl{ní požadavků a přijím{ní odpovědí, je sestavena pomocí n{stroje Apache Maven. K portletové aplikaci je pak sestavený JAR soubor i se z{vislostmi přid{n jako knihovna. Pro demonstraci existuje k systému Jira Sample Java SOAP Client 23, který komunikuje s veřejně přístupnou instalací systému Jira. V nezměněné verzi ale tento klient nelze použít, protože jsou v něm již přímo zadan{ data o uživateli a instalaci systému Jira. Proto byl v této pr{ci vytvořen nový SOAP klient obsahující metodu pro vyhled{ní problémů ze systému Jira podle zadaných parametrů. API pro komunikaci se systémem Jira bohužel neumožňuje vybrat například jen ty problémy, které řeší 22 JIRA 4.1 Documentation [online]. 2010 [cit. 2010-05-10]. JIRA RPC Services. Dostupné z WWW: . 23 5. VÝVOJ PORTLETOVÉ APLIKACE 30 vybraný uživatel, musí se vyt{hnout všechny úkoly, které je uživatel opr{vněn vidět, a až poté je filtrovat dle potřeby. Úkoly jsou vybír{ny podle filtru, který musí mít uživatel nastavený v systému Jira, stačí ale aby administr{tor jednou nastavil filtr bez nějakých omezujících podmínek a zpřístupnil ho všem uživatelům. Číslo tohoto filtru se zad{v{ do formul{ře v edit módu portletu pro seznam úkolů a portletu pro úkoly jiných osob. Ve vyvíjené aplikaci je také potřeba mít k dispozici seznam kategorií, stavů a priorit, které jsou v systému Jira aktivní. API poskytuje metody jimiž lze vyt{hnout přímo seznam těchto prvků, v SOAP klientu jsou proto implementov{ny jednoduché metody pro tyto účely. 5.4.2 Jira backend Třída, kter{ využív{ výše popsaného SOAP klienta, implementuje rozhraní pro poskytovatele zdrojů. Vzhledem k tomu, že u úkolů ze systému Jira je podporov{no pouze zobrazení (ne editace, maz{ní, prohlížení detailu, apod.), některé operace vracejí výjimku sdělující, že operace není podporov{na. Toto je ale ošetřeno na vyšší úrovni a uživatel nem{ možnost tyto operace prov{dět. Nejdůležitější metodou je metoda, kter{ podle zadaných parametrů vrací seznam úkolů odpovídající těmto parametrům. Kvůli výše popsanému problému s výběrem úkolů z Jira v této metodě probíh{ i filtrace úkolů. Při vol{ní metody z agregační třídy je zad{no, podle kterého atributu jsou úkoly řazeny, zda sestupně nebo vzestupně, kolik úkolů m{ být vr{ceno a od kolik{té pozice v pořadí. Protože za st{vajících podmínek nelze ze systému Jira načítat úkoly podle těchto kritérií, musí se filtrované úkoly ještě seřadit a vybrat spr{vný počet úkolů na spr{vných pozicích. Autentizace uživatele je v nynější verzi aplikace řešena zadanými přihlašovacími údaji v preferencích portletu, tím p{dem i filtrov{ní podle řešitele a zadavatele probíh{ u daného úkolu porovn{ním jména z preferencí a jména u úkolu. V budoucnu by mělo být k dispozici mapov{ní jmen port{lových uživatelů a uživatelů Jira a autentizace bude automatick{ (je–li uživatel z{roveň přihl{šen k Jira), tím odpadne povinnost uživatele zad{vat do portletu své údaje a udržovat je aktu{lní. Ot{zkou bylo mapov{ní atributů problému v systému Jira na atributy úkolu ve vyvíjené aplikaci. N{zev úkolu je ve vyvíjené aplikaci jednoduché několikaslovné pojmenov{ní, ale v systému Jira m{ úkol shrnutí, což může být několik vět, nebo klíč, který se skl{d{ z n{zvu projektu a čísla. Jira také neeviduje kategorie, u problému je typ (např. chyba, nov{ funkcionalita, atd.) nebo n{zev projektu. Stavy a priority problém z Jira m{, ale priority jsou vyj{dřeny slovně. Bylo rozhodnuto, že problém ze systému Jira bude převeden na úkol n{sledujícím způsobem:  klíč problému je považov{n za n{zev – z{roveň je také patrné, ke kterému projektu úkol patří, detaily se uživatel dozví po kliknutí;  typ problému se převede na kategorii úkolu. 5. VÝVOJ PORTLETOVÉ APLIKACE 31 Pro účely řazení podle priority jsem hledala způsob, jak priority porovn{vat, bohužel API pro SOAP komunikaci nenabízí ž{dný způsob, jak zjistit kter{ priorita je vyšší. Pro účely řazení úkolů tedy pokl{d{me úkoly z Jira za stejně prioritní. 5.5 Portlety 5.5.1 Portlet pro seznam úkolů Tento portlet zobrazuje úkoly přihl{šeného uživatele v port{lu. Souč{stí je portletov{ třída a soubory JSP pro zobrazení str{nek view módu, edit módu a detailu úkolu, toto JSP se použív{ i v portletu pro úkoly jiných osob. Z portletové třídy jsou vol{ny metody na instanci třídy AggregationPoint, kter{ získ{v{ úkoly z různých zdrojů. 5.5.2 Portlet pro přid{v{ní a editaci úkolů Portlet slouží pro přid{v{ní nových úkolů a úpravy úkolů. Skl{d{ se z portletové třídy a str{nek JSP pro módy view a edit. V detailu úkolu v portletu pro seznam úkolů nebo pro úkoly jiných osob se po vybr{ní úpravy úkolu před{ veřejným render parametrem identifik{tor úkolu. Ve formul{ři jsou pak zobrazeny údaje o úkolu a uživatel je může editovat. Po odesl{ní proběhne validace, testuje se délka n{zvu a popisu, spr{vnost zadaného data a zda jsou vyplněné všechny povinné položky. V případě, že validace projde, se úkol ukl{d{ do datab{ze a z{roveň se testuje, jestli vložení proběhne bez výjimky. Podle výsledku se uživateli zobrazí zpr{va o úspěšném uložení nebo nemožnosti uložit úkol. V edit módu tohoto portletu lze přid{vat a mazat kategorie, při přid{ní se testuje, zda kategorie se stejným n{zvem již neexistuje. Při smaz{ní kategorie se kategorie v datab{zi nastaví jako neaktivní a d{le se nenabízí při úpravě a přid{v{ní. U úkolů, které ji již mají nastavenou, ale zůst{v{. 5.5.3 Portlet pro aktu{lní ozn{mení Portlet pro aktu{lní ozn{mení je jedním z integračních bodů, do budoucna pl{nujeme zavést notifikační API, přes které bude možné uživatele notifikovat vybraným způsobem, např. emailem. Ve st{vající verzi se uživateli zobrazují lokalizovan{ ozn{mení s údaji uloženými v datab{zi. Portlet podporuje různé typy ozn{mení, kter{ se týkají překročení data splnění nebo změn v přiřazení úkolů osob{m. Ozn{mení jsou navržena tak, aby nebyla zbytečně notifikov{na osoba, kter{ změnu provedla, a aby se změna úkolu oznamovala každému zúčastněnému uživateli jen jednou (jeden uživatel u úkolu často vystupuje v různých rolích, je například z{roveň zadavatelem i zodpovědnou osobou). 5. VÝVOJ PORTLETOVÉ APLIKACE 32 Pl{nujeme také ke každému ozn{mení přidat odkaz, po kliknutí na něj by se zobrazil detail úkolu. Pr{vě z důvodu zasíl{ní ozn{mení i jinými způsoby než portletem není vhodné použití portletových URL. Pro vytvoření potřebné URL je ale nutné prozkoumat způsob, jakým port{l URL sestavuje, bohužel ž{dný standardizovaný způsob tvorby URL pro Liferay Port{l neexistuje. 5.6 Implementace operací nad úkoly Operace nad úkoly lze prov{dět v portletu pro seznam úkolů a v portletu pro úkoly jiných osob, a to buď na úvodní str{nce výběrem označovacích polí u úkolů nebo v detailu úkolu. Při výběru akce na úvodní str{nce jsou uživateli nabídnuty pouze operace, které lze provést na všech vybraných úkolech. Tato funkcionalita je implementov{na pomocí technologií AJAX a JQuery, výhodou je rychlost a pohodlné použití pro uživatele, protože se neaktualizuje cel{ str{nka a nemusí se vykreslovat všechny portlety. Navíc pohled uživatele zůstane na stejném místě, naopak při obnovení je vždy pohled nastaven na horní č{st str{nky. Pro každý zavedený typ úkolu je definov{no, které podporuje z operací: úprava, maz{ní, delegov{ní, schv{lení, zamítnutí a zobrazení historie. Ve zdrojovém kódu str{nky je do každého elementu obsahujícího úkol přid{n element označující operace, které úkol nepodporuje. Na z{kladě tohoto lze pomocí JQuery ověřit, zda mezi označenými úkoly je nějaký, který danou akci nepodporuje a pokud ano, je s použitím JQuery znemožněn výběr této akce v roletě s akcemi. V detailu úkolu je pro každou akci zvl{štní odkaz, ten se uživateli nabízí podle toho, které akce úkol podporuje. Je také možné označit všechny úkoly, všechny úkoly ke schv{lení apod., tyto odkazy jsou řešené opět pomocí JQuery bez nutnosti obnovení celé str{nky. Zpracov{ní akcí probíh{ prostřednictvím agregační třídy a poté prostřednictvím poskytovatelů jednotlivých úkolů. Při smaz{ní úkolu se úkol nastaví jako neaktivní, ale v datab{zi zůst{v{. Toto řešení bylo zvoleno kvůli možnosti dohled{ní smazaného úkolu a obnovení omylem smazaného úkolu. 5.7 Kask{dové styly Port{l obsahuje mnoho možností přizpůsobení a je možné nastavovat i vlastní témata vzhledu. Aby se vzhled portletu měnil se změnou vzhledu port{lu, je třeba využívat stylů, které jsou v port{lu obsaženy. Tímto způsobem jsou řešené kask{dové styly i ve vyvíjené aplikaci. Elementy zdrojového kódu str{nek jsou označeny třídami a podle nich je zobrazov{n jejich vzhled. Vyvíjené portlety nemají ž{dný vlastní soubor s definicí stylů. 5. VÝVOJ PORTLETOVÉ APLIKACE 33 Vzhledem k tomu, že kask{dové styly nejsou standardizované napříč port{ly, je toto stylov{ní podporov{no v Liferay port{lu, pro který je portlet vyvíjen prim{rně. Při nasazení na jiný port{l by byla aplikace bez dalších úprav funkční v z{kladním vzhledu bez stylů. 5.8 Vybrané metody ve třídě AggregationPoint Třída AggregationPoint je důležit{, protože propojuje č{st aplikace zajišťující uživatelské rozhraní s konektory na různé zdroje. Z{měrem je, aby při přid{ní nového konektoru bylo třeba upravit co nejmenší č{st zdrojových kódů. Aby se nemusel upravovat kód portletových tříd a JSP, v agregační třídě se nach{zí několik metod sloužících k nastavení zach{zení s různými typy úkolů. Stačí tedy přidat zdrojové kódy konektoru a nastavit tyto metody. Nastavit je možné:  zda se jedn{ o úkol standardní nebo ke schv{lení;  jestli se m{ detail úkolu zobrazovat v portletu nebo se otevře okno s úkolem v původním systému;  jak{ je URL adresa detailu úkolu, pokud se nezobrazuje v port{lu;  jaké jsou operace, které úkol podporuje. 5.9 Podpora úkolů ke schv{lení Při n{vrhu aplikace jsme narazily na to, že existují dva typy úkolů – úkol, pro jehož dokončení je potřeba vyvinout určitou činnost, a úkoly, které čekají pouze na schv{lení nebo zamítnutí, například schv{lení n{kupu. Oba typy mají sv{ specifika, proto jsme se je rozhodly v aplikaci odlišovat. Úkoly ukl{dané v lok{lní datab{zi mohou být obou typů, u nově přid{vaného konektoru se v agregační třídě nastaví, zda podporuje úkoly schvalovací, standardní nebo obojí. Při implementaci podpory pro schvalovací úkoly bylo zvažov{no několik variant. Jednou z možností bylo udělat pro schvalovací úkoly nový samostatný portlet. Portlet by byl poměrně jednoduchý a podobný portletu pro seznam úkolů. Na druhé straně ale uživatel, který například něco schvaluje jen jednou za měsíc, by musel mít portlet st{le na str{nce nebo by mu mohl úkol uniknout. Navíc se schvalovacím úkolem se pracuje velmi podobně jako se standardním. Proto bylo zvoleno řešení zobrazovat oba typy úkolů v jednom portletu a v edit módu umožnit nastavení, které typy úkolů se zobrazují. Uživatel si tak může úkoly ke schv{lení vyčlenit do samostatného portletu nebo je mít mezi ostatními úkoly. Další ot{zkou bylo, zda ukl{dat tyto typy úkolů v datab{zi jako jednu tabulku nebo dvě. Došla jsem ale k tomu, že schvalovací úkoly se liší od standardních jen v atributu stav, který je u obou typů úkolu z jiné množiny stavů. Z tohoto důvodu není potřeba schvalovací úkoly ukl{dat do zvl{štní tabulky. 5. VÝVOJ PORTLETOVÉ APLIKACE 34 5.10 Rozšíření do budoucna 5.10.1 Konfigurační portlet Do budoucna pl{nujeme doplnit sadu portletů ještě o portlet pro konfiguraci. Tento portlet by byl dostupný pro administr{tora, který by zde nastavil připojení k lok{lní datab{zi, údaje nutné pro připojení k systému Jira a popř. konfiguraci dalších konektorů na jiné systémy. Administr{tor by mohl vybírat, které zdroje úkolů se budou používat. V tomto portletu by se také mohly přid{vat a mazat kategorie a stavy úkolů. 5.10.2 Výběr jednor{zových filtrů Výběr jednor{zových filtrů se týk{ portletu pro seznam úkolů a portletu pro úkoly jiných osob. Zde pl{nujeme přidat možnost výběru úkolů pomocí ovl{dacích prvků přímo na úvodní str{nce. Tento výběr by byl jednor{zový, na rozdíl od nastavení v edit módu. Pro implementaci ovl{dacích prvků pravděpodobně použijeme technologii AJAX, aby bylo možné ovl{dací prvky skrýt a aby se nemusela obnovovat cel{ str{nka. 5.10.3 Notifikační API Rozhraní pro notifikaci bude popisovat seznam dostupných notifikačních kan{lů. Prostřednictvím tohoto rozhraní budou uživatelům zasíl{ny ozn{mení o úkolech. V úvahu přich{zejí kan{ly: email, samostatný portlet pro ozn{mení a případně RSS, IM (instant messaging). Notifikační API bude navržené tak, aby přich{zelo v úvahu i použití s jinými portletovými aplikacemi, které potřebují zasíl{ní zpr{v. 35 Z{věr Cílem této pr{ce bylo sezn{mit se s problematikou podnikových port{lů a tvorbou portletových aplikací. Praktick{ č{st pr{ce zahrnovala vytvoření sady portletů pro seznam úkolů. Úvodní č{st pr{ce poskytuje z{kladní orientaci v oblasti podnikových port{lů i pro čten{ře, který s nimi nem{ předchozí zkušenost. Port{l může mít mnoho podob, od internetového obchodu přes port{ly telekomunikačních společností až po podnikový port{l, který uživatelům nahrazuje použití mnoha specializovaných aplikací. Port{l je webovou str{nkou, jejíž z{kladní komponentou jsou portlety, typicky býv{ na str{nce několik nepřekrývajících se oken – portletů. Pr{vě portletům se věnuji v n{sledující č{sti pr{ce. Portlety jsou podobné servletům, ale hlavní rozdíl spočív{ v tom, že portlet generuje jen fragmenty kódu str{nky a port{l zajišťuje portletům určité služby, v portletu například není třeba řešit autentizaci uživatele. Pro tvorbu portletů existují dvě specifikace – starší JSR-168 a novější JSR-286. Portletov{ aplikace je webovou aplikací, kter{ navíc obsahuje XML deskriptor portlet.xml. V této pr{ci se také kr{tce věnuji prozkoum{ní jiných aplikací, které s úkoly pracují. Konkrétně se zabýv{m aplikacemi: Microsoft Outlook, Remember the Milk, Rainlendar, IBM WebSphere Portal Unified Task List portlet a Atlassian Jira. Vývoj sady portletů jsem řešila s Ivou Ž{kovou, projekt byl rozdělen na dvě č{sti z důvodu rozsahu. Mojí č{stí pr{ce bylo vytvořit konektor pro systém Jira, portlety pro seznam úkolů, přid{v{ní a úpravu úkolů a ozn{mení, vzhled a implementace operací nad úkoly. Možn{ rozšíření do budoucna jsou: přid{ní konfiguračního portletu, implementace jednor{zových filtrů úkolů a podpora rozhraní pro notifikaci různými kan{ly. Pr{ce je řešena v r{mci průmyslového partnerství Fakulty informatiky a firmy IBA CZ. Ve vývoji budu pokračovat a po dalších konzultacích budou implementov{na popsan{ rozšíření aplikace. 36 Použit{ literatura [1] Java Community Process. JSR-168 Portlet Specification. 2003 [online]. [cit. 2010- 05-10]. Dostupné z WWW: . [2] Java Community Process. JSR-286 Portlet Specification. [online]. 2007 [cit. 2010- 05-10]. Dostupné z WWW: . [3] LINWOOD, Jeff; MINTER, Dave. Building Portals with the Java Portlet API. USA : Apress, 2004. 393 s. ISBN 1-59059-284-0. [4] JUAN, Jonas X. Liferay Portal 5.2 Systems Development. Birmingham : Packt Publishing, 2009. 551 s. ISBN 978-1-847194-70-1. [5] COVEY, Stephen R. 7 n{vyků vůdčích osobností pro úspěšný a harmonický život : n{vrat etiky charakteru. 1. vyd. Praha : Pragma, 1994. 329 s. ISBN 8085213419. [6] PHILLIP, Dane. Buzzle.com : Intelligent Life on the Web [online]. 2007 [cit. 2010-05- 05]. Web Portals and Web Portals Types. Dostupné z WWW: . [7] Liferay : Enterprise. Open source. For Life. [online]. 2010 [cit. 2010-05-10]. Portal Features. Dostupné z WWW: . [8] MARTINÍK, Ivo. Konference Tvorba Softwaru [online]. 2004 [cit. 2010-05-10]. Technologie model-view-controller a její uplatnění při n{vrhu a implementaci port{lových řešení. Dostupné z WWW: . [9] Microsoft Office Online [online]. 2010 [cit. 2010-05-10]. Microsof Office Outlook. Dostupné z WWW: . POUŽIT[ LITERATURA 37 [10] IBM Lotus and WebSphere Portal Business Solutions Catalog [online]. 2010 [cit. 2010-05-10]. IBM WebSphere Portal Unified Task List portlet . Dostupné z WWW: . [11] KOSEK, Jiří. Inteligentní podpora navigace na WWW s využitím XML [online]. Praha : VŠE, 2002. 72 s. Diplomov{ pr{ce. VŠE. Dostupné z WWW: . [12] JIRA 4.1 Documentation [online]. 2010 [cit. 2010-05-10]. JIRA RPC Services. Dostupné z WWW: .