Mendelova univerzita v Brně Provozně ekonomická fakulta
Dostupné komponenty pro vývoj webových aplikací v J2EE Bakalářská práce
Vedoucí práce: Ing. Jan Kryštof, Ph.D.
Ondřej Svoboda
Brno 2011
2 Zadání práce
Děkuji svému vedoucímu bakalářské práce Ing. Janu Kryštofovi, Ph.D. za cenné rady a čas věnovaný konzultacím.
Prohlašuji, že jsem závěrečnou práci vykonal samostatně a za použití literatury, kterou uvádím v seznamu
Brno, 27. května 2011
....................................................
5
Abstract Svoboda, O. Available components for developing J2EE applications. Bachelor’s final project. Brno, 2011 This thesis deals with creating Java web applications and explores available components which can be integrated into those applications. The theoretical part deals with the general problems of web applications development in Java and then focuses on Rich Internet Applications framework Google Web Toolkit. In the practical part were established criteria for evaluation of freely available web application components and was created overwiew of freely available file managers, web forums, photo galleries and WYSIWYG editors. Practical part continues with analysis, draft and implementation of new server file manager component.
Abstrakt Svoboda, O. Dostupné komponenty pro vývoj aplikací v J2EE. Bakalářská práce. Brno, 2011 Tato bakalářská práce se zabývá problematikou tvorby webových aplikací v jazyce Java a dostupnými komponentami, které lze do webových aplikací integrovat. Teoretická část se zabývá obecným vývojem webových aplikací v jazyku Java a dále se zaměřuje na rámec Google Web Toolkit, který slouží k vývoji RIA aplikací. V praktické části jsou vytvořena kritéria pro hodnocení dostupných komponent webových aplikací a sestaven přehled volně dostupných souborových manažerů, webových fór, fotogalerií a WYSIWYG editorů. Praktická část pokračuje analýzou, návrhem a tvorbou vlastní komponenty pro správu souborů na serveru.
6
OBSAH
Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 8 8
2 Webové technologie 2.1 Architektura Java EE . . . . . . . . . . . . . . . . 2.2 Java EE specifikace . . . . . . . . . . . . . . . . . 2.3 AJAX . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Webové kontejnery . . . . . . . . . . . . . . . . . 2.4.1 Apache Tomcat . . . . . . . . . . . . . . . 2.4.2 Instalace JVM a Apache Tomcat Windows 2.4.3 Struktura a konfigurace aplikace . . . . . . 2.4.4 Základní konfigurace Tomcatu . . . . . . . 2.4.5 Spuštění vlastní aplikace . . . . . . . . . .
. . . . . a . . .
. . . . . . . . . . . . . . . . . . . . Linux . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
9 9 10 15 16 16 16 16 17 17
3 Google Web Toolkit 3.1 SmartGWT . . . . . . . . . . 3.1.1 Tvorba GUI . . . . . . 3.1.2 Kompilace . . . . . . . 3.1.3 Remote Procedure Call 3.1.4 Google App Engine . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
18 18 18 19 19 21
. . . . . . . . . . . . . . . . . . .
23 23 23 24 25 25 26 27 27 28 29 30 31 31 32 33 34 34 34 35
. . . . . . . . . . . . . . . (RPC) . . . . . .
4 Přehled dostupných komponent 4.1 Kritéria hodnocení . . . . . . . . . . . 4.2 Online WYSIWYG editory . . . . . . . 4.2.1 TinyMCE 4.3.2 . . . . . . . . . 4.2.2 Open WYSIWYG . . . . . . . . 4.2.3 CK Editor 3.6 . . . . . . . . . . 4.2.4 Xinha 0.96.1 . . . . . . . . . . . 4.3 Online souborové manažery . . . . . . 4.3.1 JSP File Browser 1.2 . . . . . . 4.3.2 FileManager servlet 4.0 . . . . . 4.3.3 WebFileSys 2.6.0 . . . . . . . . 4.3.4 JEExplorer 1.15 . . . . . . . . . 4.4 Webová fóra . . . . . . . . . . . . . . . 4.4.1 Forum servlet 3.0 . . . . . . . . 4.4.2 Message Board Servlet 2.6 . . . 4.4.3 WWWboard servlet 5.0 . . . . 4.5 Fotogalerie . . . . . . . . . . . . . . . . 4.5.1 JGallery . . . . . . . . . . . . . 4.5.2 Pictures publishing ver. 1.9 . . 4.6 Zhodnocení shromážděných komponent
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
OBSAH
7
5 Vlastní aplikace 37 5.1 Analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2 Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.3 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6 Diskuze
48
7 Závěr
49
8 Literatura
50
9 Přílohy
52
1
ÚVOD A CÍL PRÁCE
1
8
Úvod a cíl práce
1.1
Úvod
Obor informačních technologií se každým rokem ohromně vyvíjí a ruku v ruce s tímto vývojem přichází i změny v požadavcích uživatelů a vývojářů na přístup k aplikacím. Ještě před pár lety, v dobách pomalého, drahého a ne všude dostupného internetového připojení, bylo téměř nemyslitelné provozovat složitější webové aplikace. Veškerý výpočetní výkon a datová úložiště se sdružovala v lokálních systémech a ven putovala maximálně elektronická komunikace. Avšak trendem dnešní doby se stávají cloudové aplikace, díky nimž není nutné řešit opakované instalace na množství klientských stanic, odpadají potíže s kompatibilitou jednotlivých systémů a pro chod aplikací postačí pouze internetový prohlížeč s několika základními doplňky. Uživatelé chtějí mít svá data dostupná kdykoliv a odkudkoliv. Při výběru způsobu předání digitálních fotografií z dovolené spousta lidí raději zvolí jednu z online foto galerií, než aby musela zdlouhavě vyměňovat přenosná média. Cloudovým směrem se ubírá i velké množství dalších typů dříve zásadně desktopových aplikací. Příkladem můžou být multimediální přehrávače a editory dokumentů. Hudbu i video není nutné kopírovat na vlastní disk a uživatel ji streamuje přímo z daného serveru, online editory dokumentů poskytují téměř totožné funkce co jejich desktopové verze, ale uživatel má přistup k těmto dokumentům z libovolného zařízení. Velkým průkopníkem v tomto segmentu je společnost Google, která ve svém portfoliu nabízí široké množství webových aplikací, mezi nimiž jsou nejen online foto galerie, email, editor dokumentů, ale v brzké době i kompletní cloudový operační systém Chrome OS.
1.2
Cíl
Cílem této bakalářské práce je zlepšit stav v oblasti volně dostupných komponent pro vývoj webových aplikací v jazyce Java. Řešení práce bude rozděleno do následujících kroků: • Představení problematiky vývoje webových aplikací v jazyce Java. • Sestavení přehledu volně dostupných komponent webových fór, foto galerií, WYSIWYG editorů a souborových správců. • Stanovení kritérií pro hodnocení komponent a zjištění nedostatků. • Navrhnutí vlastního řešení pro vybranou komponentu a řešení implementovat.
2
WEBOVÉ TECHNOLOGIE
2 2.1
9
Webové technologie Architektura Java EE
Počátky programovacího jazyku Java spadají do roku 1991, kdy skupina vývojářů společnosti Sun Microsystems vedená Jamesem Goslingem začala pracovat na novém programovacím jazyku. První verze byla zveřejněna v roce 1995. Dnes tato technologie spadá pod vlastnictví společnosti Oracle. Velkou výhodou Javy je multiplatformnost. Její zastoupení není jen v prostředí webu a počítačů, ale z velké části i v segmentu mobilních zařízení, herních konzolí, Blu-Ray přehrávačů, televizí a podobně. Java se dělí podle funkčnosti a zaměření na jednotlivé edice: Java Standard Edition, Java Mobile Edition, Java FX a Java Enterprise Edition. Každá z těchto platforem poskytuje Virtual Machine a vlastní API. Java Virtual Machine je program, který umožňuje vlastní běh Java aplikace. API je kolekce softwarových komponent, které mohou být použity při vývoji nových komponent nebo aplikací. (ORACLE, 2011) S vývojem J2EE bylo započato v roce 1998, první verze pak byla vydána v roce 1999. Prvotní název této platformy byl ve formátu Java 2 Enterprise Edition 1.2 (J2EE 1.2). Pro zjednodušení značení se od verze 5 zavedlo pojmenování ve formátu Java Enterprise Edition 5 (Java EE 5). Java EE můžeme chápat jako množinu specifikací implementovaných různými kontejnery. Tyto kontejnery vyjadřují jednotlivá Java EE runtime prostředí, která poskytují určité služby hostujícím komponentám. Starají se o řízení životního cyklu komponenty, vkládání závislostí atd. Tyto komponenty se při komunikaci s infrastrukturou Java EE a jinými komponentami řídí přesně stanovenými pravidly. Java EE je rozšířením Java SE pro tvorbu robustních vícevrstvých podnikových aplikací. Jakékoliv API z Java SE může být tedy použito v Java EE aplikaci či komponentě. Applet kontejner zajišťuje bezpečnost při spouštění appletových komponent. Tyto komponenty jsou spouštěny uvnitř sandboxu a nemohou tedy zasahovat vně kontejneru. Aplikační klientský kontejner (ACC) obsahuje množství Java tříd, knihoven a dalších souborů potřebných k zajištění řízení závislostí, bezpečnosti a jmenných služeb. ACC komunikuje s EJB kontejnerem za užití RMI-IIOP, s webovým kontejnerem potom přes protokol http. Webový kontejner poskytuje základní služby pro řízení a spouštění komponent (servlety, JSP, JSF, posluchače událostí). Kontejner je zodpovědný za vytváření instancí, inicializaci a volání servletů za podpory http a https protokolu. Tento kontejner je dále zodpovědný za předání požadovaného obsahu do webového prohlížeče klienta.
2
WEBOVÉ TECHNOLOGIE
10
EJB kontejner je zodpovědný za řízení spouštění EJB. Vytváří nové instance EJB, řídí jejich životní cyklus a poskytuje služby jako jsou například transakce, bezpečnost, souběžnost, distribuce, jmenné služby nebo možnost asynchronního užití. (GONCALVES, 2010)
Obr. 1: Grafické znázornění rozvržení služeb podle jednotlivých kontejnerů (GONCALVES, 2010)
2.2
Java EE specifikace
Z dostupných dokumentů se specifikacemi byl sestaven přehled vývoje a změn jednotlivých verzí Java EE. Tento přehled je zobrazen v tabulce číslo 11 v příloze práce. V následující sekci jsou stručně popsány nejvýznamnější technologie Java EE. Servlety jsou odpovědí technologie Java na programování pomocí CGI (Common Gateway Interface). Jedná se o program, který běží na webovém serveru a působí jako střední vrstva mezi požadavkem přicházejícím z webového prohlížeče nebo od jiného HTTP klienta a databází či aplikací na webovém serveru (HALL, 2008). Jelikož servlety běží čistě na serveru uvnitř Java Virtual Machine, není potřeba řešit problémy s kompatibilitou jednotlivých webových prohlížečů. Základem servletu je balík javax.servlet obsahující základní rozhraní a třídy implementované a rozšiřované všemi servlety. Jádrem této architektury je rozhraní javax.servlet.Servlet, které je vždy potřeba implementovat, ať už přímo nebo formou dědění. Toto rozhraní má definováno pět metod:
2
WEBOVÉ TECHNOLOGIE
11
Init (ServletConfig config): tato metoda je zavolaná bezprostředně po vytvoření nové instance servletu. Jako parametr je jí dán objekt obsahující spouštěcí parametry. Service(ServletRequest req, ServletResponse res): metoda zacházející s požadavky zaslanými klientem. Dokud nebyla zavolána metoda init(), není schopna metoda service() tyto požadavky zpracovat. Destroy(): metoda volaná při ukončování běhu služeb. GetServletInfo(): navrací řetězec s informacemi o daném servletu jako jsou například jméno autora, verze servletu apod. GetServletConfig(): navrací objekt, ve kterém jsou obsaženy inicializační parametry servletu. (PURE JSP) Balík javax.servlet.http obsahuje abstraktní třídu HttpServlet, ve které jsou nejvýznamnějšími metodami doGet() a doPost(). Tyto metody řeší zpracování POST a GET požadavků a bývají volány pomocí výše uvedené metody service(). Více bude o konfiguraci servletu bude napsáno později v této kapitole práce. JSP – Java Server Pages: jedná se o rozšíření technologie Java Servlets. JSP umožňuje směšovat běžné, statické HTML stránky s dynamicky generovaným obsahem ze servletů (HALL, 2008). To znamená, že JSP stránky jsou vyjádřeny statickými textovými částmi v HTML či XML a JSP elementy, které určují výslednou formu dynamické části stránky. JSP je vhodné pro stránky s větším množstvím statických prvků. Pro dynamicky generované stránky je vhodnější užití servletů. JDBC – Java Database Conectivity: jedná se o API sloužící k řízení komunikace Java komponent s databázovými servery. Standardní JDBC obsahuje API pro práci s řádkovými množinami, umožňuje vytvořit spojení s databází, odesílání SQL požadavků a následné vyhodnocení výsledků dotazu. Pro zajištění komunikace je třeba nalinkovat specifickou JDBC knihovnu s ovladači, jež obsahuje API pro konkrétní databázi. EJB – Enterprise Java Beans: komponenty na straně serveru, které oddělují provozní logiku od prezentační, starají se o transakce, bezpečnost, spravování zpráv, plánování, životní cyklus komponent atd. Navíc je možné bez problémů propojit EJB s ostatními Java SE a Java EE technologiemi, jako je například JDBC, JavaMail, JPA, Java Transaction API (JPA), Java Messaging Service (JMS), Java Authentication and Authorization Service (JAAS), Java Naming and Directory Interface (JNDI) a Remote Method Invocation (RMI). (GONCALVES, 2010) JMS – Java Messaging Service: standardní Java EE API, které umožňuje aplikacím asynchronně vytvářet, posílat, přijímat a číst zprávy. Je definováno množinou
2
WEBOVÉ TECHNOLOGIE
12
běžných rozhraní a tříd, které umožňují programům komunikovat s ostatními poskytovateli zpráv (GONCALVES, 2010). Nejedná se však o specifikaci sloužící k emailové komunikaci. Tyto zprávy obsahují řídící informace pro chod vlastní aplikace. Pro emailovou komunikaci slouží JavaMail API. JTA – Java Transaction Api: typická podniková aplikace ukládá a načítá data z jedné nebo více databází. Jelikož tato data jsou velmi důležitá pro podnikový provoz, musí být informace přesné, aktuální a hodnověrné. Proto musí být všechny transakce během komunikace se serverem dokončeny úspěšně. V případě neúspěšného dokončení jsou všechny změny zahozeny a je obnoven původní stav. Transakce končí zprávou commit (proběhne úspěšně, veškeré změny jsou přijaty) nebo rollback (návrat k původnímu stavu, všechny změny ovlivněné transakcí jsou považovány za neplatné). Java Transaction API umožňuje aplikacím přístup k transakcím způsobem, který je nezávislý na způsobu implementace. JTA specifikuje Java rozhraní mezi správcem transakcí a stranami zapojenými v distribuovaném transakčním systému. (JENDROCK, 2010) JTS – Java Transaction Service: jedná se o specifikaci pro sestavení transakčního správce. RMI (Remote Method Invocation) umožňuje vyvolat vzdálené objekty nezávisle na použitém protokolu. Standardním RMI protokolem pro Java SE je Java Remote Method Protokol (JRMP). RMI-IIOP je rozšířením standardního RMI, užívaným pro integraci CORBA. Java Interface Description language(IDL) umožňuje komponentám Java EE aplikací užívat externí CORBA objekty použitím IIOP protokolu. CORBA objekty mohou být napsány v širokém množství programovacích jazyků (C,C++, Java atd.). (GONCALVES, 2010) JNDI – Java Naming and Directory Interface API: zajišťuje funkčnost pojmenovávání prvků a adresářů. Umožňuje aplikacím přistupovat k prvkům pomocí jmen, včetně podpory existujících služeb jako jsou DNS (Domain Name System), NIS (Netvork Information Service) a LDAP (Lightweight Directory Access Protocol). JavaMail API:
je nejčastěji užíváno pro správu následujících funkcí:
• Vytvoření emailové zprávy skládající se z kolekce, která zahrnuje hlavičkové atributy a vlastní blok dat. Typ těchto dat je specifikován v hlavičkové části v poli Content-Type. • Vytvoření nového session objektu pro autentizaci uživatele a řízení přístupů k úložišti zpráv. • Odesílání zpráv podle zadaného příjemce. • Přistupovat ke zprávám v jejich úložišti.
2
WEBOVÉ TECHNOLOGIE
13
• Spouštění nadřazených příkazů nad prvky obdržených zpráv jako je například náhled nebo tisk. O tyto operace se stará JAF. (MANI, 2006) JAF – JavaBeans Activation Framework: získá část dat pro určení jejich typu, zjistí operace, které je možné s těmito daty provádět, a vybere vhodnou JavaBean komponentu, která vykoná dané operace. JAF je užíván JavaMail API. (JENDROCK, 2010) JAXP/B – Java API for XML Processing/Binding: jedná se o specifikace, umožňující práci s XML soubory. Obě tyto API slouží trochu rozdílným účelům. Výběr závisí na požadavcích vlastní aplikace. JAXB poskytuje mechanizmy, které usnadňují tvorbu a údržbu aplikací užívajících schopnosti XML. Užívá kompiler, který XML překládá podle DTD (Document Type Definition) do jedné nebo více tříd. Generované třídy pracují s XML detaily, ověřují syntaktickou korektnost a formátování, díky čemuž je zaručený jen průchod bezchybných XML. JAXB nedokáže pracovat se stromovou strukturou dat. JAXP není závislé na žádném DTD, je možné užít stejný zpracovávající kód pro XML s různými DTD. Umožňuje rozebrat dokumenty, které nemusí být oproti JAXB nezbytně validní. Další výhodou je možnost užití XSLT (Extensible Stylesheet Language Transformation), díky kterému je možné pomocí stylových předloh exportovat XML například do HTML či PDF. (BOND, 2002) JCA – Java EE Connector Architecture: jelikož ERP aplikace bývají velice rozsáhlé a spravují velké množství dat, je zapotřebí získat přístup k těmto datům i z externích aplikací. Java nabízí speciální konektory, které umožňují přístup k těmto aplikacím z Java EE komponent. Principiálně se jedná o obdobu JDBC. (JENDROCK, 2010) JAAS – Java Authentication and Authorization Service: slouží ke dvěma účelům. K prokázání identity uživatelů pro spolehlivé a bezpečné určení, kdo zrovna spouští Java kód, bez ohledu na to, jestli se jedná o aplikaci, applet, bean či servlet nebo pro autorizaci uživatelů a zjištění, zda-li mají potřebná práva k provedení požadovaného úkonu. (ORACLE, 2001) JACC – Java Authorization Service Provider Contract for Containers: určuje vztah mezi Java EE aplikačním serverem a poskytovatelem služeb autorizace. JMX – Java Management Extensions: framework vytvořený za účelem sladění a řízení nesourodých částí kódu v moderní IT infrastruktuře. Do standardních Java EE specifikací přišel až s verzí J2EE 1.4. Před zavedením JMX zde nebyla žádná standardizovaná koncepce, která by řídila, spouštěla a sledovala různé Java komponenty. Díky tomuto frameworku je možné vytvářet řízené Beans (MBeans). Jádrem
2
WEBOVÉ TECHNOLOGIE
14
této architektury je prostředník (agent), kterého lze přirovnat ke sběrnici spojující řídící aplikace s řízeným kódem. Tento agent se stará o načítání nových komponent, plánování načasování životních cyklů jednotlivých komponent, sledování stavu komponent a definuje vztahy mezi různými MBeans komponentami. (LINDFORS, 2000) JSF – Java Server Faces: framework pro tvorbu uživatelského rozhraní (UI) webových Java aplikací. Je navržen pro zásadní zjednodušení tvorbu a údržbu aplikací, které běží na serveru a renderují svá uživatelská rozhraní koncovému uživateli. JSF zjednodušuje práci následujícími způsoby: • Umožňuje vytvořit uživatelské rozhraní ze sady opakovaně použitelných komponent UI. • Usnadňuje migraci aplikačních dat směrem z uživatelského rozhraní i do něj. • Pomáhá řídit stav UI požadavkem na server. • Obstarává spojení klientem generovaných událostí s aplikačním kódem na straně serveru. • Dovoluje jednoduché vestavění a znovu užití upravených komponent UI. (BURNS, 2009) EL – Expresion Language: od verze 2.0 JSP podporuje EL, díky kterému je v JSP stránkách jednodušší přistupovat k aplikačním datům. JSTL – Java Server Pages Standard Tag Library: sbírka základních značek (tagů), díky kterým je možné částečně zamezit míchání Java kódu a XHTML značek. S dynamickými daty uvnitř JSP je možné zacházet užitím XML značek místo Java kódu. Pro možnost užití těchto značek stačí provést import URI dané sbírky (GONCALVES, 2010, s318). Například pro import značek pro práci s SQL a provedení dotazu se provede: <% @ taglib uri = http: // java . sun . com / jsp / jstl / sql > < sql:query var:dotaz1 > SELECT * FROM table sql:query >.
JAX-WS – Java API for XML-Based Web Services: JAX-WS je od verze 2.0 nástupce staršího JAX-RPC 1.1. Tato specifikace poskytuje podporu pro webové služby, které využívají JAXB API pro načítání XML dat do Java objektů. (JENDROCK, 2010) Common Annotations: anotační jazyk umožňuje přistupovat k psaným a strukturovaným meta datům ze zdrojového kódu. Tato data se zapisují nebo připojují před požadované elementy (třídy, metody, pole, proměnné). Pokud provedeme anotaci
2
WEBOVÉ TECHNOLOGIE
15
nějakého elementu, překladač z něj přečte obsažené parametry, provede následné zpracování podle zadaného anotačního rozhraní. Je možné používat sbírku předdefinovaných anotačních rozhraní nebo vytvářet svá vlastní. Zapisují se ve tvaru @Rozhraní(parametry). (KEITH, 2006) JASPIC – Java Authentization Service Provider Interface for Containers: tato specifikace poskytuje rozhraní poskytovatele služeb, díky kterému je možné integrovat mechanismy pro zjištění identity klienta přímo v kontejneru spravujícím zasílání zpráv. JPA – Java Persistence API: slouží ke spojení objektových a relačních modelů. JPA je abstrakcí nad JDBC, jež umožňuje nezávislost na SQL. Základem je balík javax.persistence. • ORM (Object Relation Mapping) slouží k namapování objektů uložených v relační databázi • Entity Manager API pro provedení CRUD (Create, Read, Update a Delete) nad entitami (objekty) • Java Query Language (JPQL) dotazovací jazyk, který je obdobný SQL, ale dotazy provádí nad entitami a ne přímo nad tabulkami databáze. Tyto entity jsou pomocí JPA namapované do tabulkové formy (GONCALVES, 2010)
2.3
AJAX
AJAX je zkratkou pro Asynchronní JavaScript a XML. Stručně řečeno, jedná se o užití XMLHttpRequest objektů pro komunikaci se skripty na straně serveru. Informace mohou být odesílány a zpracovávány v rozdílných formátech, včetně JSON, XML, HTML a dokonce i ve formě textových souborů. Největší výhodou užití AJAX je jeho asynchronnost, díky čemuž pro odesílání a zpracování žádostí není nutné obnovovat stránku. (RICHARDSON, 2006)
2
WEBOVÉ TECHNOLOGIE
2.4 2.4.1
16
Webové kontejnery Apache Tomcat
Pro provoz aplikací napsaných v J2EE je nutný nějaký webový aplikační server. Na trhu je dostupné množství komerčních i Open Source webových kontejnerů. Z komerční sféry jsou to například IBM WebSphere, Oracle WebLogic, mezi Open Source patří JBoss, Jetty, GlassFish a Apache Tomcat. Apache Tomcat bude použit jako kontejner pro testování shromážděných komponent a pro vývoj vlastní aplikace. Tomcat, stejně jako jakékoliv aplikace založené na Javě, vyžaduje pro funkčnost Java Virtual Machine(JVM). Oracle poskytuje zdarma JVM pro operační systémy Windows, Linux a Solaris. Vývojem JVM pro ostatní platformy se zabývají Open Source skupiny nebo třetí firmy. Některé jsou zdarma, některé komerční. 2.4.2
Instalace JVM a Apache Tomcat Windows a Linux
1. Nejprve je nutné stáhnout a nainstalovat Java Development Kit (JDK) 2. Stáhnout a rozbalit z http://tomcat.apache.org/ archiv s jádrem požadované verze Tomcatu. Pro windows je dostupný i automatický binární instalátor. Tento instalátor nainstaluje i jednoduchý manažer, díky kterému je možné spravovat Tomcat pomoci GUI. 3. Vytvořit nové systémové proměnné prostředí s názvem JAVA HOME jejíž hodnotou bude cesta k složce s instalací JDK a CATALINA HOME, která bude obsahovat cestu k instalaci Tomcatu. 4. Spuštění a zastavení služby se provede pomocí CATALINA HOME /bin/startup (shutdown) nebo v případě instalace pomocí automatického instalátoru přes danou nabídku v GUI. 2.4.3
Struktura a konfigurace aplikace
Vlastní aplikace se standardně instalují do složky CATALINA HOME/webbaps. Specifikace servletu vyžadují dodržení určité základní adresářové struktury. Webové aplikace bývají typicky umístěny ve složce se stejným názvem jako je název aplikace, jelikož URL je tvořena podle jména složky. Aplikace s názvem MyApp by tedy byla umístěná ve složce MyApp a následně přístupná na URL http://localhost: 8080/MyApp. Uvnitř složky by se měla nacházet složka WEB-INF a někdy i složka META-INF. Všechen obsah nacházející se uvnitř těchto složek spadá do kategorie soukromých aplikačních zdrojů a nemůže být přímo přístupný klientskou aplikací. Naopak všechno nacházející se mimo tyto složky je veřejné a může být přístupné pod patřičnou URL. Uvnitř složky WEB-INF by se měl nacházet konfigurační soubor web.xml (Deployment Descriptor), dále pak složka lib, do které se umísťují užité externí knihovny, a složka classes, obsahující vlastní třídy. Složka META-INF často
2
WEBOVÉ TECHNOLOGIE
17
obsahuje jediný soubor a to MANIFEST.MF. Tento soubor může obsahovat seznam užitých jar knihoven. (CHOPRA, 2004) Soubor web.xml poskytuje Tomcatu informace o konfiguraci a vlastnostech komponent zahrnutých v dané aplikaci. Jak již bylo zmíněno výše, třídy servletů nejsou přímo přístupné klientskou částí aplikace, a proto je zde možné namapovat třídě servletu určitou URL. Dále se zde nastavují například inicializační parametry, které jsou dostupné jako parametr typu ServletConfig při inicializaci servletu v metodě init(). 2.4.4
Základní konfigurace Tomcatu
Globální konfigurace probíhá úpravou souborů ve složce CATALINA HOME/conf. Nachází se zde jden policy, několik xml a properties souborů. • Opět je zde web.xml, zde jsou však nastavovány hodnoty pro všechny aplikace. • V souboru server.xml se konfigurují vlastnosti Tomcat serveru (například port pod, kterým bude naslouchat je standardně 8080, pokud ale nejsou na provozovány na stroji jiné webové služby a je volný port 80, je možné nastavit tento port). • Soubor catalina.policy obsahuje základní sadu dodržovaných bezpečnostních politik. Je zde možné nastavit specifické pravomoci pro jednotlivé aplikace. • Context.xml definuje položky, které budou načítány pro každou aplikaci. Zde Tomcat například vyčte informaci, kde ve složce aplikace hledat soubor web.xml. 2.4.5
Spuštění vlastní aplikace
Při dodržení struktury aplikace je spuštění velmi jednoduché. Stačí projekt zkopírovat do složky webapps a po spuštění serveru bude aplikace přístupná standardně na portu 8080. War balíky jsou automaticky po startu serveru rozbaleny a zpřístupněny. V tabulce číslo 1 jsou zobrazeny minimální verze specifikace pro spuštění aplikace. Např. pro spuštění servletů ve verzi 3.0 je nutný Tomcat 7.0.x. Tab. 1: Minimální specifikace a verze Javy pro spuštění aplikace (APACHE, 2011) Servlet/JSP spec Verze Tomcatu Poslední vydaná verze Min. Java verze 3.0/2.2 7.0.x 7.0.12 1.6 2.5/2.1 6.0.x 6.0.32 1.5 2.4/2.0 5.5.x 5.5.33 1.4 2.3/1.2 4.1.x 4.1.40 1.3 2.2/1.1 3.3.x 3.3.2 1.1
3
GOOGLE WEB TOOLKIT
3
18
Google Web Toolkit
Pro vývoj aplikací, nejen v jazyce Java, se často užívají externí knihovny a frameworky. Díky tomu je značně jednodušší tvorba uživatelských rozhraní a hlavně rychlejší vývoj, jelikož není nutné začínat od úplného základu a vytvářet všechno vlastními silami. Jedním z těchto frameworků je i Google Web Toolkit, který bude použitý pro tvorbu vlastní aplikace v praktické části této práce.
3.1
SmartGWT
Architektura Smart GWT zahrnuje klientskou i serverovou část aplikace. Umožňuje vytvářet bohaté internetové aplikace (Rich Internet Aplications), které komunikují mezi uživatelskými daty a službami vrstev. Podstatou RIA aplikací je co největší přiblížení aplikacím desktopovým po stránce vzhledu i funkčnosti. V rámci webového prohlížeče Smart GWT poskytuje velké rozpětí služeb a komponent pro HTML5/Ajax aplikace. Pro uživatele serveru založeného na Javě poskytuje smartGWT i framework pro práci s daty na straně serveru. (SHAMSUDDIN, 2010) Google nabízí plugin pro IDE eclipse. Instalace v sobě zahrnuje vlastní plugin, GWT SDK a Google App Engine, o kterém bude psáno níže. GWT SDK obsahuje základní knihovny a vlastní kompiler. Při vývoji je třeba rozlišovat třídy, které budou pracovat na straně serveru a třídy, které budou sloužit pro zpracování a zobrazení dat u klienta. Jelikož na straně serveru se jedná o klasický servlet, je zde možné užívat libovolné Java rozhraní a třídy. Oproti tomu na klientské straně je možné používat jen třídy, které je schopný emulovat GWT. Na straně klienta je sice během vývoje kód psán v jazyce Java, avšak ještě před samotným zprovozněním aplikace se provede kompilace kódu do optimalizovaného JavaScriptu. 3.1.1
Tvorba GUI
Google web toolkit nabízí rozsáhlé množství tříd pro tvorbu grafického uživatelského rozhraní. Smart GWT se sestává z dvou skupin vizuálních komponent: • Nezávislé vizuální komponenty, které jsou vytvářeny a užívány přímo vývojáři (uživateli). • Řízené prvky formulářů, které jsou vytvářeny a řízeny automaticky jejich rodičovskými formuláři nebo editovatelnými tabulkami. Pro vykreslení nezávislé Smart GWT komponenty slouží metoda draw(), komponenty lze následně skrývat a zobrazovat. U každé komponenty je možné nastavit množství parametrů a naslouchačů různých typů událostí. UI komponenty zabudované v základu GWT jsou zobrazovány zavoláním RootPanel.get().add(widget). Tento postup není pro Smart GWT vhodné používat. Celkově není vhodné míchat Smart GWT a GWT komponenty, jelikož není zajištěna jejich interoperabilita. Pro
3
GOOGLE WEB TOOLKIT
19
nastavení umístění Smart GWT komponent jsou užívány vertikální a horizontální Layout manažery. (ISOMORPHIC SOFTWARE, 2010) 3.1.2
Kompilace
Webové aplikace mohou během vývoje v IDE nástrojích běžet v hostovaném režimu. V tomto režimu Java Virtual Machine spouští aplikační kód za pomocí GWT jako kompilovaný binární Java kód a není tedy nutné po každé změně v klientském kódu provádět zdlouhavé kompilace do JavaScriptu, které mohou trvat i několik desítek vteřin. Kompilátor standardně provádí 5 permutací1 . Každá permutace je prováděna pro jiné jádro prohlížeče, a proto pro zrychlení kompilace je toto možné upravit a provádět kompilaci jen pro jedno uživatelem definované jádro. Proto, aby bylo možné GWT projekt zkompilovat, je nutné vytvořit *.gwt.xml soubor, ve kterém jsou specifikovány parametry jednotlivých modulů aplikace. Kompilátor dále potřebuje z tohoto souboru vyčíst informace o umístění všech tříd a knihoven, které budou během kompilace užity. 3.1.3
Remote Procedure Call (RPC)
Klientský kód v GWT aplikaci dokáže asynchronně komunikovat se serverem vzdáleným voláním procedur (RPC), za pomocí JSON nebo vytvořením cross-site žádostí. Mezi klientem a serverem lze pomocí RPC předávat DTO (Data Transfer Objects). DTO třídy musí splňovat následující kritéria: • Implementují serializované rozhraní com.google.gwt.user.client.rpc.IsSerializable. I když není možné v RPC používat žádné java.io třídy a rozhraní, je za splnění určitých podmínek možná implementace java.io.Serializable. • Pokud třída obsahuje vlastní konstruktory, je nutné vytvořit i bezparametrický konstruktor. • Obsahují primitivní datové typy (jako je char, byte, short, int, long, boolean, float nebo double), výčtový typ enum, instance objektů String, Boolean, Date, Byte, Character, Long, Float nebo Double, dále pole uvedených typů nebo serializovaných objektů. Pro funkčnost RPC je nutné vytvořit celkem 3 dodatečné třídy a rozhraní. Princip bude popsán na příkladu. První rozhraní služeb rozšiřuje RemoteService a definuje hlavičku metody, kterou budeme chtít volat na serveru, včetně návratového typu. Vytvořená metoda bude obsahovat parametr typu String s návratovým typem long. Tato metoda bude sloužit k určení velikosti souboru na serveru. Objekt typu java.io.File není přes RPC možné posílat, a proto je nutné vše zpracovat na straně serveru. RemoteServiceRelativePath definuje relativní cestu k servletu, jež bude nastavená v konfiguračním souboru web.xml. 1
Verze Google Web Toolkitu 2.2
3
GOOGLE WEB TOOLKIT
20
@ R e m o t e S e r v i c e R e l a t i v e P a t h ( " myservlet " ) public interface MyService extends RemoteService { long getFileSize ( String path ) }
Druhé rozhraní definuje asynchronní verzi výše uvedené metody s návratovým typem void, pro možnost řízení časových limitů žádostí je místo návratového typu void třeba použít RequestBuilder. public interface MyServiceAsync { RequestBuilder getFileSize ( String path , AsyncCallback < long > sizeRPC ); }
Poslední prvek pro správnou funkčnost RPC je vlastní servlet, který bude metodu obsahovat. Tento servlet musí implementovat předem definované rozhraní služeb, kterým je v tomto případě MyService. public class MyServiceImpl extends R e m o t e S e r v i c e S e r v l e t implements MyService { long getFileSize ( String path ){ File f = new File ( path ) return ( f . length ()); } }
Nakonec zbývá jen konfigurace web.xml, kde se provede namapování třídy servletu podle nastaveného relativního umístění v MyService. < servlet - name > MyServiceImpl servlet - name > < servlet - class > package . MyServiceImpl servlet - class > servlet > < servlet - mapping > < servlet - name > MyServiceImpl servlet - name >
/ myservlet url - pattern > servlet - mapping >
Nyní by měla být klientská strana schopna užívat RPC. Mějme tedy příklad, kdy uživatel chce získat informace o velikosti souboru na serveru. Uživatel zná jeho přesné fyzické umístění. Základem by mohla být jednoduchá třída s názvem Klient, která implementuje rozhraní EntryPoint. Toto rozhraní obsahuje jedinou metodu onModueleLoad(), která je automaticky volána po spuštění aplikace. Jediným úkolem této třídy bude zobrazit velikost souboru, ke kterému získá cestu v parametru. public class Klient implements EntryPoint { private MyServiceAsync async = GWT . create ( MyService . class ); public void onModuleLoad (){ RequestBuilder fSize = async . getFileSize ( " / file . txt " , new AsyncCallback < long > (){ @Override
3
GOOGLE WEB TOOLKIT
21
public void onFailure ( Throwable arg0 ) { // Zpracování události , když došlo k ~ chybě při přenosu dat } @Override public void onSuccess ( long odpoved ) { // požadavek byl úspěšně zpracován a ~ dorazila odpověď SC . say ( " Velikost souboru je: " + odpoved ); } }); fSize . setTimeoutMillis (3000); fSize . send (); } }
Nyní by měl být schopen prohlížeč zobrazit u klienta velikost požadovaného souboru. V tomto případě bývá předáván pouze parametr String a návratovou hodnotou je long, avšak tyto parametry lze nahradit jakýmkoliv DTO objektem. 3.1.4
Google App Engine
Dalším integrovaným doplňkem GWT je Google App Engine. Tento plugin umožňuje propojit Eclipse s vlastním Google účtem a aplikace přímo po kompilaci odesílat na servery infrastruktury Googlu. Je možné takto sdílet až deset vlastních aplikací. Odpadá tedy problém se zařizováním vlastního hostingu a zveřejní aplikace je záležitostí několika vteřin. Aplikace je umístěna na www.appspot.com na doméně třetího řádu dle vlastního výběru nebo je možné v administraci nastavit doménu vlastní. Bohužel App Engine přichází s několika zásadními omezeními, mezi něž patří například zásadní restrikce práce se soubory. Jediné co je zde povoleno, je čtení statických souborů, jež byly společně s aplikací odeslány na server. Toto omezení bohužel nelze obejít žádným způsobem, a proto pro aplikaci pracující se soubory na serveru je App Engine naprosto nevyhovující. Další z nevýhod jsou nastavené kvóty pro užívání systémových prostředků a omezení maximální doby požadavku. Tato doba činí 30 vteřin a není možné ji upravit. Dalším problémem je, že zde nejsou použitelné všechny API standardní J2EE, a proto některé z knihoven třetích stran nemusí korektně fungovat. App Engine se nedrží standardů i co se týče práce s databázemi. Jelikož dalším z omezení je nemožnost vytvářet síťová spojení, není možné provést spojení s vlastní databází nacházející se na jiném serveru a není zde možné vytvořit žádnou jinou SQL databází. App Engine využívá vlastní Datastore (Google Big Table). Datastore uchovává data v objektech zvaných entity. Každá entita má unikátní klíč. Tento klíč obsahuje ID aplikace, druh entity a ID entity. Klíč po vytvoření entity již není možné měnit. Maximální velikost entit je 1 MB. (GUERMEUR, 2010) Na adrese appengine.google.com je po přihlášení pod vlastním Google účtem možné v administraci spravovat již zveřejněné aplikace. Nachází se zde detailní systémový log a přehled čerpaných systémových prostředků. Standardní bezplatný účet
3
GOOGLE WEB TOOLKIT
22
nabízí 6,5 hodin procesorového času, 1GB pro odchozí, 1GB pro příchozí komunikaci a 1GB webového prostoru. Dodatečné prostředky jsou dostupné za poplatek.
4
PŘEHLED DOSTUPNÝCH KOMPONENT
4
23
Přehled dostupných komponent
Následující kapitola obsahuje přehled volně dostupných komponent WYSIWYG editorů, souborových správců, webových fór a foto galerií. Jednotlivé komponenty budou uvedeny do funkčního stavu, otestovány a hodnoceny na základě předem stanovených kritérií.
4.1
Kritéria hodnocení
• Kompatibilita s nejpoužívanějšími prohlížeči: Jednotlivé komponenty budou testovány na nejpoužívanějších prohlížečích postavených na jádrech Webkit (Google Chrome 11 a Safari 5), Gecko (Firefox 4), Presto (Opera 11) a Trident (IE 9). Podíly jednotlivých prohlížečů jsou zobrazeny v tabulce 2. Testování bude probíhat na serveru s operačním systémem Debian GNU/Linux, jako webový kontejner bude použit Apache Tomcat 6.0.32. Jednotlivé komponenty budou uvedeny do funkčního stavu a bude testována korektnost celkového chování komponenty. • Aktualizace: Poslední aktualizace komponenty vývojářem. • Možnosti užití komponenty: Komponenty zahrnuté do přehledu musí poskytovat licence pro volné nekomerční užití, některé komponenty však nabízí i možnost zdarma nebo za příplatek pořídit licenci pro komerční užívání. • Možnosti přizpůsobení vzhledu komponenty: Některé komponenty se nedrží jen jednoho předdefinovaného motivu vzhledu, ale umožňují vytvářet a aplikovat motivy vlastní. Další komponenty zase nabízí možnost přidat vlastní HTML záhlaví čí zápatí anebo provést úpravy pomocí kaskádových stylů.
Tab. 2: Globální zastoupení prohlížečů duben 2011. (W3SCHOOLS.COM, 2011) Chrome Safari Firefox Opera Internet Explorer 25.6% 4.1% 42.9% 2.6% 24.3%
4.2
Online WYSIWYG editory
WYSIWYG je zkratkou anglického výrazu „What You See Is What You Getÿ, doslova „co vidíš, to dostanešÿ. Jedná se nejčastěji o javascriptové doplňky, které umožňují rozšířené možnosti ve správě textu. Díky těmto doplňkům není nutná znalost html tagů. Klasické textarea obsahují prostý text a pro změnu formátování částí textu, který bude výstupem z tohoto pole, je třeba zadávat manuálně jednotlivé tagy. Díky WYSIWYG rozšířením jsou ve výchozím stavu pro uživatele tagy skryty a je zobrazen již formátovaný text. Mezi základní funkce těchto editorů nepatří jen
4
PŘEHLED DOSTUPNÝCH KOMPONENT
24
formátování samotného textu (barva, velikost, řez, zarovnání), ale i možnost vkládání obrázků a tvorba tabulek. Pokročilejší editory nabízí například možnost vkládání flash elementů, videí, užití externích kaskádových stylů, podrobnější možnosti pozicování a přiřazování javascript funkcí jednotlivým prvkům. 4.2.1
TinyMCE 4.3.2
Domovská stránka: www.tinymce.com
Obr. 2: Nástrojová lišta TinyMCE Tento Open Source editor je zdarma ke stažení na webových stránkách projektu. Zde je možné stáhnout doplňky MCImageManager, MCFileManager a Compressor. První dva doplňky jsou placené a jedná se o správce souborů a obrázků na serveru. Bohužel zde není dostupná verze pro jazyk Java. Ke stažení jsou zde jen PHP a .NET balíky. Cena začíná na 32 eurech, kdy se jedná o licenci pro jednu doménu. Licence pro užití do vlastních komerčních projektů stojí 399 euro za jeden doplněk, 900 euro je pak zvýhodněná cena za oba. Compressor je jediný zdarma, dostupný i v JSP. Vývojáři na svých stránkách poskytují velmi dobrou podporu. Nachází se zde kompletní dokumentace, fóra a seznam odpovědí na nejčastější dotazy. Obrázek 2 zobrazuje nástrojovou lištu TinyMCE se všemi dostupnými funkcemi. Je možné sestavit editor jen z požadovaných funkcí, každé tlačítko lze při sestavování editoru přesunout nebo úplně odstranit. Editor je kompletně lokalizován do téměř osmdesáti jazyků, včetně češtiny. Hlavní funkce: formátování textu, práce se schránkou (možné vkládat text z wordu se zachováním formátování), vložení obrázků, propracovaná práce s tabulkami (možnost dodatečně měnit vlastnosti), tisk, emotikony, práce v celoobrazovkovém režimu, přímá editace html, náhled dokumentu, vkládání data a času, vkládání médií (Flash, HTML 5 Video, Shockwave, Windows Media, Real Media), práce s vrstvami (zde je tím myšlena práce s div elementy), hledání a nahrazování řetězců, rozmístění textu podle předdefinované šablony. Jako jediný z editorů umožňuje užívat tabulátor a přímou editaci CSS stylů. • Kompatibilita s nejpoužívanějšími prohlížeči: tento editor neměl problém se zobrazením v žádném z testovaných prohlížečů. • Aktualizace: Projekt je stále vyvíjen. V roce 2011 vydáno několik aktualizací. • Možnosti přizpůsobení funkcí komponenty: Open Source editor pod LGPL licencí.
4
PŘEHLED DOSTUPNÝCH KOMPONENT
25
• Možnosti přizpůsobení vzhledu komponenty: Tento editor umožňuje zvolit vzhled z několika předdefinovaných motivů nebo aplikaci motivu vlastního 4.2.2
Open WYSIWYG
Domovská stránka: www.openwebware.com
Obr. 3: Nástrojová lišta Open WYSIWYG Jedná se o starší, jednodušší, dnes již nevyvíjený editor. Na domovské stránce se kromě výčtu funkcí nenachází žádné doplňující informace ani jakákoliv vývojářská či uživatelská podpora. Neobsahuje lokalizaci do českého jazyka a i po stránce funkčnosti nenabízí žádné specifické prvky. Na obrázku číslo 3 je nástrojový panel tohoto editoru v maximální konfiguraci. • Kompatibilita s nejpoužívanějšími prohlížeči: Jelikož se jedná o delší dobu neaktualizovaný editor, není funkční na novějších prohlížečích postavených na jádře Webkit (Chrome, Safari). • Aktualizace: Poslední aktualizace tohoto editoru proběhla v roce 2006. • Možnosti užití komponenty: Editor pod licencí Open source LGPL. • Možnosti přizpůsobení vzhledu komponenty: V tomto editoru není možné vybírat z předdefinované množiny motivů, avšak úprava je možná editací základního CSS souboru. 4.2.3
CK Editor 3.6
Domovská stránka: http://ckeditor.com/
Obr. 4: Nástrojová lišta CK Editoru CK editor vystupoval do roku 2009 pod názvem FCK Editor. Na domovské stránce se nachází dokumentace pro uživatele i pro vývojáře, diskusní fórum a široký výběr jazykových mutací, včetně podpory češtiny. Je možné k editoru dokoupit doplněk s názvem CKFinder, což je správce souborů. Tento správce dokáže zobrazovat náhledy obrázků, měnit rozlišení obrázků,
4
PŘEHLED DOSTUPNÝCH KOMPONENT
26
editovat textové dokumenty, mazat, přejmenovávat a nahrávat soubory na server. Dostupný je pro php, ASP a Cold Fusion. Cena doplňku začíná na 59 dolarech za licenci pro jednu webovou stránku. Starší FCK editor je stále dostupný včetně souborového správce, který je vytvořen pro php, asp, aspx, cfm, lasso, perl, php a python. Do CK je možné při sestavování nalinkovat vlastního souborového správce nebo alespoň servlet pro nahrávání souborů na server. Od verze 3.6 obsahuje CK editor plugin pro výstup textu v BBCode místo html. Kromě standardní správy textu editor podporuje tvorbu formulářů, výstup v xhtml 1.1 a výstup do flashe. Díky dostupnosti kompletní API dokumentace lze jakkoliv upravovat dialogová okna, přidávat vlastní tlačítka nebo vytvářet vlastní záložky. Na obrázku číslo 4 je nástrojová lišta editoru v maximální konfiguraci. • Kompatibilita s nejpoužívanějšími prohlížeči: Editor neměl problémy se zobrazením u žádného prohlížeče. • Aktualizace: Projekt je stále vyvíjen. V roce 2011 vydáno několik aktualizací. • Možnosti užití komponenty: Editor distribuovaný pod GPL, LGPL a MPL open source licencemi, dále pak pod komerční CK Source Closed Distribution License, která umožňuje libovolně měnit a užívat tento editor. Nejlevnější komerční licence pro jednu webovou adresu stojí 375 dolarů. • Možnosti přizpůsobení vzhledu komponenty: Možnost měnit motivy nebo barevné zabarvení. 4.2.4
Xinha 0.96.1
Domovská stránka: http://trac.xinha.org/
Obr. 5: Nástrojová lišta Editoru Xinha Komunitou vyvíjený editor. Na domovské stránce je dostupná dokumentace pro uživatele i API dokumentace pro vývojáře, fórum a návody pro tvorbu nových pluginů. Editor obsahuje i lokalizaci do českého jazyka, navíc je dostupný návod pro tvorbu vlastní lokalizace. Je zde i plugin pro správu souborů, ale bohužel jen v php. Hlavní funkce: formátování textu, práce se schránkou (možné vkládat text z wordu se zachováním formátování), vložení obrázků, propracovaná práce s tabulkami (možnost dodatečně měnit vlastnosti), tisk, emotikony, práce v celoobrazovkovém režimu, přímá editace html, náhled dokumentu, vkládání data a času, vkládání Flash prvků, hledání a nahrazování řetězců, rozmístění textu podle předdefinované šablony, html formuláře a dokonce nabízí plugin pro práci s hudební notací. Obrázek číslo 5 zobrazuje nástrojovou lištu se všemi dostupnými funkcemi.
4
PŘEHLED DOSTUPNÝCH KOMPONENT
27
• Kompatibilita s nejpoužívanějšími prohlížeči: Editor neměl problémy se zobrazením u žádného prohlížeče. • Aktualizace: Poslední aktualizace v roce 2010. • Možnosti užití komponenty: Editor distribuovaný pod Open Source BSD licencí. • Možnosti přizpůsobení vzhledu komponenty: Předdefinované motivy.
4.3
Online souborové manažery
Následující kategorie obsahuje přehled dostupných komponent souborových manažerů. Tyto komponenty umožňují manipulovat se soubory na straně serveru za užití grafického uživatelského rozhraní. 4.3.1
JSP File Browser 1.2
Domovská stránka: http://www.vonloesch.de/
Obr. 6: JSP File Browser Starší, ale schopný správce s jednoduchým designem. Jedná se o jediný JSP soubor, instalace tedy spočívá pouze ve zkopírování souboru na server. Tento správce dokáže kromě standardních operací, jako jsou přejmenování, přesouvání a odstraňování souborů, rozbalovat archivy, editovat nebo vytvářet nové textové soubory (prostý text), prohlížet, stahovat a nahrávat nové soubory na server. Dále je možné spouštět nad serverem příkazy (například chmod pro nastavení práv). Tento správce umožňuje procházet kompletní adresářovou strukturu serveru a stahovat soubory z libovolného umístění, proto když by si jej někdo nahrál na svůj webhosting a nebyla zde ošetřena práva pro zamezení čtení, bude moci uživatel libovolně procházet
4
PŘEHLED DOSTUPNÝCH KOMPONENT
28
server a stahovat soubory i ze systémových složek. Čeština není přímo obsažena, ale v hlavičce souboru lze jednoduše změnit textové řetězce popisků tlačítek. • Kompatibilita s nejpoužívanějšími prohlížeči: Souborový správce byl funkční ve všech prohlížečích. • Aktualizace: Poslední aktualizace v roce 2006. • Možnosti užití komponenty: Editor distribuovaný pod GPL Open Source licencí. • Možnosti přizpůsobení vzhledu komponenty: Pouze CSS. 4.3.2
FileManager servlet 4.0
Domovská stránka: http://www.servletsuite.com/servlets/fmanager.htm
Obr. 7: File Manager Servlet Vzhledově zastaralý souborový správce. V defaultním nastavení je výpis souborů ve žluté barvě na modrém pozadí. Umožňuje editovat textové dokumenty (pouze prostý text), vytvářet složky, kopírovat, odstraňovat, přejmenovávat a nahrávat soubory. Jedná se o servlet, a tedy instalace probíhá úpravou konfigurace web.xml. V xml souboru je možné jako inicializační parametr předat cestu k externímu konfiguračnímu souboru, ve kterém lze nastavit například kódování, externí CSS styl, zablokovat některé funkce, barvy fontu, heslo pro přístup nebo seznam přípon souborů editovatelných v textovém editoru. • Kompatibilita s nejpoužívanějšími prohlížeči: Souborový správce byl funkční ve všech prohlížečích. • Aktualizace: V roce 2005.
4
PŘEHLED DOSTUPNÝCH KOMPONENT
29
• Možnosti užití komponenty: Produkt je volně k užití pro nekomerční a nevládní účely. • Možnosti přizpůsobení vzhledu komponenty: CSS nebo do záhlaví umístit html banner. 4.3.3
WebFileSys 2.6.0
Domovská stránka: http://www.webfilesys.de/
Obr. 8: WebFilesys Velmi propracovaný souborový správce se spoustou funkcí, který zároveň obstarává funkce webových foto galerií. Nastavení se provádí přes grafické rozhraní, kde administrátor může vytvářet a měnit vícečetné uživatelské účty, každému účtu je možné nastavit přístupné adresáře, diskové kvóty, vlastní motiv, jazyk, nastavit pravomoci a sledovat session všech aktivních uživatelů. Kromě kompletní správy souborového systému je možné zobrazovat statistické grafy (počty souborů podle typu, velikosti, stáří), ke každému souboru je možné přidávat komentáře, k fotografiím potom navíc ještě bodové hodnocení. Je možná editace textových souborů (prostý text). Uživatelské účty, hodnocení a komentáře jsou ukládány do externího XML souboru, není tedy potřeba žádné externí SQL databáze. Se soubory dokáže pracovat nejen přes HTTP, ale přes FTP mohou být vytvářeny zálohy. U obrázků je možné upravit rozlišení, provést otočení, přesunout, převzít jméno dle data pořízení, automaticky vložit textový vodotisk, zobrazit EXIF informace a provést záznam GPS souřadnic pořízení obrázku. Další z unikátnějších funkcí je možnost veřejného publikování jakékoliv složky. Publikovat je možné v klasickém režimu procházení souborů nebo v režimu foto galerie. Zde je možné povolit přidávání komentářů a dobu expirace publikované složky. Po publikování je automaticky vygenerován veřejný odkaz. V režimu foto galerie jsou
4
PŘEHLED DOSTUPNÝCH KOMPONENT
30
zobrazeny miniatury obrázků, lze zobrazit Picture story, kdy jsou obrázky seřazeny vertikálně pod sebou spolu s komentáři, nebo lze spustit slideshow všech obrázků. • Kompatibilita s nejpoužívanějšími prohlížeči: Bez problému funkční ve všech prohlížečích. • Aktualizace: V roce 2011. • Možnosti užití komponenty: WebFileSys je volně k užití a může být použit jak pro soukromé, tak pro komerční účely. Autor jen prosí o zaslání registračního emailu, ve kterém jsou zahrnuty účely užití, verze správce, operační systém a typ servletového kontejneru. • Možnosti přizpůsobení vzhledu komponenty: Předdefinované motivy, css. 4.3.4
JEExplorer 1.15
Domovská stránka: http://www.webworks.dk/jeexplorer
Obr. 9: File Manager Servlet Správce ve stylu průzkumníku známého ze systému Windows. Na levé části se nachází strom dokumentů, vpravo pak výpis souborů z vybrané složky. Obsažené funkce: nahrávání, stahování a odstraňování souborů (možno nahrát zip archiv, ten se automaticky rozbalí), tvorba nové složky a vyhledávání souboru podle jména. Konfigurace se provádí přes externí soubor, ve kterém se nastavuje pouze maximální povolená velikost nahrávaného souboru a výchozí složka. Velkou nevýhodou je, že po každé změně adresáře se vykresluje celý klient nanovo. • Kompatibilita s nejpoužívanějšími prohlížeči: Ve všech prohlížečích se podařilo správce spustit, jediný problém nastal u prohlížečů s jádrem Webkit, kdy ani
4
PŘEHLED DOSTUPNÝCH KOMPONENT
31
v jednom ze dvou testovaných prohlížečů nebylo možné nahrát nový soubor na server. Všechny ostatní funkce byly bez problémů použitelné. • Aktualizace: V roce 2007. • Možnosti užití komponenty: Volně k užití pro nekomerční účely. Pro komerční účely je třeba zaplatit za licenci. Nejlevnější je multi-serverová licence v ceně 140 dolarů. • Možnosti přizpůsobení vzhledu komponenty: Žádné.
4.4
Webová fóra
Webová fóra jsou online diskusní stránky, kde mohou uživatelé přidávat vlastní příspěvky. Příspěvky jsou nejčastěji vztahovány k určitému diskusnímu tématu, ve formě prostého textu. 4.4.1
Forum servlet 3.0
Domovská stránka: http://www.servletsuite.com/servlets/forum.htm
Obr. 10: Forum Servlet - ukázka příspěvků Servlet tvořící jednoúrovňové fórum. Příspěvky jsou řazeny pod sebe dle data vložení a jsou seskupeny po deseti na stránku. Nastavení je prováděno pomocí externího souboru. K souboru se může cesta nastavit přímo v XML jako inicializační parametr nebo se tato cesta předá jako parametr v odkazu na servlet. Forum je ve formě jedné JAR knihovny a obsahuje dva servlety. První je základem fóra a slouží k přidávání nových příspěvků, druhý slouží k administraci. V administraci je možné jen mazání jednotlivých příspěvků. U příspěvků je možno zadávat jméno autora, webové stránky, email a vlastní příspěvek. V konfiguračním souboru lze nastavit kódování, heslo pro administraci, provést lokalizace a hlavně se zde nastavuje způsob ukládání příspěvků. Příspěvky mohou být ukládány do libovolné databáze nebo přímo do souborů. V případě ukládání
4
PŘEHLED DOSTUPNÝCH KOMPONENT
32
do souborů je potřeba nastavit cestu k úložišti, v případě ukládání do databáze se nastaví JDBC ovladač, přístupové údaje k databázi a název tabulky. • Kompatibilita s nejpoužívanějšími prohlížeči: Funkční ve všech prohlížečích. • Aktualizace: 2011. • Možnosti užití komponenty: Produkt je zdarma k užití pro nekomerční a nevládní účely. Dostupná i licence pro komerční užití. • Možnosti přizpůsobení vzhledu komponenty: V konfiguračním souboru lze nastavit přímo barvy písma a pozadí, je možné nastavit cestu k CSS nebo k HTML souborům pro záhlaví a zápatí. 4.4.2
Message Board Servlet 2.6
Domovská stránka: http://www.servletsuite.com/servlets/mboard.htm
Obr. 11: M. Board - přehled diskusních témat
Obr. 12: M. Board - výpis tématu 1 Oproti forum servletu se jedná o dvouúrovňové fórum. Na hlavní stránce jsou vypsána jednotlivá diskusní témata, ke kterým se následně přidávají příspěvky. Konfigurace opět probíhá pomocí externího souboru, stejně jako u forum servletu. Většina parametrů je také shodná. Možnost ukládat příspěvky na disk nebo do databáze, tvorba vlastní lokalizace, navíc je zde možnost zasílat emailová upozornění přes smtp. Tento servlet umožňuje k příspěvkům přikládat přílohy. Po odstranění příspěvku v administraci nedojde k fyzickému odstranění přiloženého souboru z disku.
4
PŘEHLED DOSTUPNÝCH KOMPONENT
33
• Kompatibilita s nejpoužívanějšími prohlížeči: Funkční ve všech prohlížečích. • Aktualizace: 2005. • Možnosti užití komponenty: Produkt je zdarma k užití pro nekomerční a nevládní účely. Dostupná i licence pro komerční užití. • Možnosti přizpůsobení vzhledu komponenty: V konfiguračním souboru lze nastavit přímo barvy písma a pozadí, je možné nastavit cestu k CSS nebo k HTML souborům pro záhlaví a zápatí. 4.4.3
WWWboard servlet 5.0
Domovská stránka: http://www.servletsuite.com/servlets/wwwboard.htm
Obr. 13: WWWboard - přehled diskusních témat Tato komponenta pro tvorbu webového fóra je tvořena jedním servletem. Příspěvky jsou seskupovány podle témat, odpovědi potom řazeny do stromové struktury. Konfigurace pomocí externího souboru, možnost ukládat příspěvky do databáze nebo do souborů, nastavení kódování, vlastní lokalizace. Komponenta neobsahuje vlastní servlet pro administraci a odstraňování příspěvků. • Kompatibilita s nejpoužívanějšími prohlížeči: Funkční ve všech prohlížečích. • Aktualizace: 2009. • Možnosti užití komponenty: Produkt je zdarma k užití pro nekomerční a nevládní účely. Dostupná i licence pro komerční užití. • Možnosti přizpůsobení vzhledu komponenty: V konfiguračním souboru lze nastavit přímo barvy písem a pozadí, je možné nastavit cestu k CSS nebo k HTML souborům pro záhlaví a zápatí.
4
PŘEHLED DOSTUPNÝCH KOMPONENT
4.5
34
Fotogalerie
Komponent pro fotogalerie je dostupné jen mizivé množství. Jako nejschopnější se jevil výše uvedený správce souborů WebFileSys, který dokázal fotografie i upravovat. 4.5.1
JGallery
Domovská stránka: http://java.net/projects/jgallery
Obr. 14: jGallery - náhledy obrázků Po nastavení cesty k fotografiím (ve web.xml souboru) jsou ve složkách automaticky vygenerovány podsložky s miniaturami jednotlivých obrázků. Seznam miniatur složky je standardně přístupný na .../jGallery/nazev slozky/index.html. Po kliknutí na miniaturu se zobrazí obrázek v plné velikosti s EXIF informacemi a náhledy následujících a předchozích fotografií, na které je možné přímo přejít a zobrazit je v plné velikosti. Konfigurace se provádí přes externí soubor, v němž se například nastavuje množství miniatur na stránku, velikost a kvalita miniatur, motiv fotogalerie a způsob řazení fotografií. • Kompatibilita s nejpoužívanějšími prohlížeči: ve všech prohlížečích bylo možné foto galerii spustit a používat, jen u Opery bylo nesprávně vykresleno grafické prostředí a některé miniatury nebyly zobrazeny. • Aktualizace: 2004 • Možnosti užití komponenty: Open Source GPL licence • Možnosti přizpůsobení vzhledu komponenty: Několik předdefinovaných motivů, CSS. 4.5.2
Pictures publishing ver. 1.9
Domovská stránka: http://www.servletsuite.com/servlets/pubpic.htm Konfigurace opět probíhá pomocí externího souboru. Zde se nastavuje cesta ke složce s obrázky, doba cachování obrázků u klienta, velikost miniatur. Tento servlet
4
PŘEHLED DOSTUPNÝCH KOMPONENT
35
Obr. 15: Picture Publishing - náhledy obrázků
opět zobrazí miniatury obrázků ve složce, po kliknutí na miniaturu je zobrazen obrázek v plné velikosti bez jakýchkoliv doplňujících údajů. Bohužel zdarma dostupná verze je omezena tím, že dostupné jsou sice všechny obrázky avšak servlet vygeneruje miniatury jen pro prvních 10 ze složky. • Kompatibilita s nejpoužívanějšími prohlížeči: Ve všech prohlížečích funkční. • Aktualizace: 2008. • Možnosti užití komponenty: Volně k užití pro nekomerční a nevládní účely. • Možnosti přizpůsobení vzhledu komponenty: Html záhlaví, zápatí, CSS, pomocí konfiguračního souboru je možné nastavit barvy a font.
4.6
Zhodnocení shromážděných komponent
U části výše uvedených komponent již delší dobu neproběhla aktualizace a kromě několika WYSIWYG editorů neobsahují lokalizaci do češtiny. Nejlepší podporu nabízí CKEditor, TinyMCE a Xinha, na jejichž domovských stránkách se nachází fóra, dokumentace a ukázková dema těchto editorů. Každá komponenta má však vytvořenu alespoň jednoduchou webovou prezentaci se základními informacemi, občas také s funkční demo aplikací. WYSIWYG editory neposkytují jen dobrou uživatelskou podporu, ale i moderní uživatelská rozhraní a rozsáhlé množství funkcí. Souborové manažery, vyjma WebFilesys, nenabízely žádné pokročilejší funkce, lokalizaci do češtiny a ani zrovna moderní uživatelská rozhraní. WebFilesys byl tím nejlepším souborovým správcem ze shromážděných komponent a hravě zastával i pokročilejší funkce pro správu fotogalerií. Komponenty pro webová fóra obsahují jen základní funkce pro vkládání a odstraňování příspěvků. Každá z komponent nabízí jiný pohled na třídění příspěvků. První komponenta vše vypisovala na jedné stránce bez uvedení tématu, druhá příspěvky seskupovala dle témat, třetí také dle tématu, ale navíc je výpis zobrazen ve stromové struktuře.
4
PŘEHLED DOSTUPNÝCH KOMPONENT
36
Komponenty pro fotogalerie jsou po funkční stránce velmi jednoduché. Jedinou jejich funkcí je vygenerovat miniatury a umožnit prohlížení originálního obrázku. Nevýhodou Picture publishing servletu bylo částečné omezení nekomerční verze a navíc to, že oproti jGallery nedokázal zobrazit EXIF data z fotografií.
5
VLASTNÍ APLIKACE
5
37
Vlastní aplikace
Tato část práce se zaměří na tvorbu vlastního souborového správce. Bude vycházeno z nedostatků komponent shromážděných v předchozí kapitole a ve vlastní komponentě se těchto nedostatků bude nutné vyvarovat. Ani jeden z výše uvedených souborových manažerů nenabízí podporu češtiny, a proto bude vytvořena primárně česká, avšak libovolně lokalizovatelná komponenta. JSP File Browser (JFB) a File Manager servlet (FMS) mají zastaralá uživatelská rozhraní, a proto bude použit pro GUI vlastní komponenty moderní framework Google Web Toolkit. JFB, FMS a JEExplorer po každé změně aktuálního adresáře překreslují celé uživatelské rozhraní a vlastní aplikace bude tedy se serverem komunikovat asynchronně a překreslovat se bude jen samotný výpis souborů. Bylo by vhodné, aby se správa prováděla pod uživatelskými účty a tyto účty by měly mít nastavené specifické pravomoci. Tuto možnost nabízel jedině WebFilesys. Pro zjednodušení bude aplikace obsahovat dva druhy účtů. První bude mít neustálé pravomoci spravovat všechny funkce, druhý typ potom bude možné částečně zbavit pravomocí provádět určité operace. Množství uživatelských účtů obou typů nebude omezeno. WebFilesys je sice po stránce funkčnosti velmi podařený souborový správce, avšak jednotlivé ovládací prvky jsou rozesety po celé aplikaci a pro některé uživatele by toto mohlo být matoucí. Vlastní správce bude tedy většinu funkčních tlačítek seskupovat na jednom ovládacím panelu. Výše uvedení správcové (mimo JEExploreru) dále umožňují editovat alespoň prostý text, ale ani jeden nenabízí integrovaný WYSIWYG editor. Vlastní správce tedy bude obsahovat editor, ve kterém bude uživatel pracovat standardně v režimu úpravy prostého textu, ale tento editor bude možné přepínat do režimu jednoduchého WYSIWYG editoru.
5.1
Analýza
V této sekci budou na základě sestaveného use case diagramu (obrázek 16) sepsány specifikace případu užití se scénáři chování systému. Specifikace případu použití Případ 1 – Výpis souborů Cíl: Zobrazení obsahu nastaveného kořenového adresáře serveru. Popis: Uživatel se chce přihlásit do systému a zobrazit soubory umístěné v kořenovém adresáři. Související případy užití: Login, Výpis souborů, Zpracuj špatné heslo, Oprávnění.
5
38
VLASTNÍ APLIKACE
Obr. 16: use case diagram
Podmínky: Tento use case začíná v případě, kdy uživatel není přihlášen do systému a chce zobrazit obsah hlavní složky. Nefunkční požadavky: • Timeout 1: časová odezva při získávání výpisu souborů nesmí být větší než 60 vteřin.
Tab. 3: Hlavní scénář Systém 1. požadavek na zadání přihlašovacích údajů
Aktér 2. vyplnění a odeslání formuláře
3. 4. 5. 6. 7.
ověření identity aplikace osobního nastavení zobrazení správce zjištění obsahu uživatelovi kořenové složky výpis souborů
Tab. 4: Alternativní scénář 1: Špatné heslo – Uživatel zadal neplatné přihlašovací údaje Systém 1. požadavek na zadání přihlašovacích údajů
Aktér 2. vyplnění a odeslání formuláře
3. ověření identity 4. nesprávné přihlašovací údaje, uživatel nenalezen, opakovat požadavek pro zadání údajů
Případ 2 – Schránka Cíl: Přesunutí souboru z kořenového adresáře do nové složky. Popis: Tento use case začíná po spuštění souborového správce, kdy je uživatel již přihlášen. Uživatel chce přesunout konkrétní soubor do nově vytvořené složky.
5
39
VLASTNÍ APLIKACE
Související případy užití: Výpis souborů, Schránka, Přesunout soubor, Oprávnění, Vytvořit složku Podmínky: Uživatel zadal správné přihlašovací údaje. Uživatel potřebuje přesunout soubor do nového umístění. Nefunkční požadavky: • Timeout 1: časová odezva při získávání výpisu souborů nesmí být větší než 60 vteřin. • Timeout 2: časová odezva při tvorbě nové složky nesmí být větší než 30 vteřin. • Timeout 3: časová odezva při přesouvání souboru nesmí být větší než 30 vteřin.
Tab. 5: Hlavní scénář Systém 1. zobrazení okna správce
Aktér 2. kliknutí na tlačítko pro zobrazení schránky
3. zobrazení schránky souborů 4. drag and drop souboru do schránky 5. zobrazení souboru ve schránce 6. kliknutí na tlačítko pro vytvoření nové složky 7. zobrazení formuláře pro zadání názvu nového adresáře 8. zadání jména a potvrzení 9. vytvoření nové složky 10. zobrazení informace o úspěšném vytvoření složky 11. vstup do nové složky 12. zobrazení obsahu složky 13. stisknutí ikony pro přesunutí u souboru ve schránce 14. přesunout soubor do aktuální složky 15. zobrazení informace o úspěšném přesunu
Tab. 6: Alternativní scénář 1: Složka existuje – Uživatel zadal jméno složky, která v daném umístění již existuje Systém 1. zobrazení okna správce
Aktér 2. kliknutí na tlačítko pro zobrazení schránky
3. zobrazení schránky souborů 4. drag and drop souboru do schránky 5. zobrazení souboru ve schránce 6. kliknutí na tlačítko pro vytvoření nové složky 7. zobrazení formuláře pro zadání názvu nového adresáře 8. zadání jména a potvrzení 9. nelze vytvořit, složka s tímto jménem již existuje 10. zobrazit informaci o problému
5
40
VLASTNÍ APLIKACE
Tab. 7: Alternativní scénář 2: Soubor existuje – Uživatel přesouvá soubor do složky, ve které soubor s tímto jménem existuje Systém 1. zobrazení okna správce
Aktér 2. kliknutí na tlačítko pro zobrazení schránky
3. zobrazení schránky souborů 4. drag and drop souboru do schránky 5. zobrazení souboru ve schránce 6. kliknutí na tlačítko pro vytvoření nové složky 7. zobrazení formuláře pro zadání názvu nového adresáře 8. zadání jména a potvrzení 9. vytvoření nové složky 10. zobrazení informace o úspěšném vytvoření složky 11. vstup do nové složky 12. zobrazení obsahu složky 13. stisknutí ikony pro přesunutí u souboru ve schránce 14. chyba, soubor s tímto jménem již v této složce existuje 15. zobrazení informace o neúspěšném přesunu
Případ 3 – Upload Cíl: Nahrát soubor na server. Popis: Tento use case začíná po přihlášení uživatele ke správci. Uživatel chce nahrát nový soubor na server. Související případy užití: Výpis souborů, Upload, Oprávnění Podmínky: Uživatel chce nahrát nový soubor na server. Byly zadány platné přihlašovací údaje. Nefunkční požadavky: • Timeout: časová odezva při získávání výpisu souborů nesmí být větší než 60 vteřin.
Tab. 8: Hlavní scénář Systém 1. ověření pravomocí 2. zobrazení okna správce 3. zobrazení výpisu souborů
Aktér
4.kliknutí na tlačítko pro zobrazení nahrávacího správce 5. zobrazení nahrávacího správce 6. výběr souboru na disku 7. potvrzení vybraného souboru 8. začátek nahrávání souboru 9. zobrazení a aktualizace status baru 10. obdržen kompletní soubor, uložit do aktuální složky 11. zobrazení informace o úspěšně dokončeném nahrávání 12. obnovit výpis aktuální složky
5
41
VLASTNÍ APLIKACE
Tab. 9: Alternativní scénář 1: Limit velikosti souboru – Uživatel vybral větší soubor než je povoleno. Systém 1. ověření pravomocí 2. zobrazení okna správce 3. zobrazení výpisu souborů
Aktér
4.kliknutí na tlačítko pro zobrazení nahrávacího správce 5. zobrazení nahrávacího správce 5. výběr souboru na disku 6. potvrzení vybraného souboru 7. začátek nahrávání souboru 8. zjištění nepovolené velikosti 9. zrušit nahrávání 10. zobrazení informace o zrušeném uploadu z důvodu překročení povolené velikosti souboru
Tab. 10: Alternativní scénář 2: Nedostatečné pravomoci – Uživatel není administrátor a má zakázáno nahrávat soubory na server Systém 1. ověření pravomocí 2. deaktivace nepovolených funkcí
Aktér
3. nelze spustit správce nahrávání, zakázaná funkce
5.2
Návrh
Obrázek 17 zobrazuje zjednodušený diagram tříd, ze kterého bude vlastní aplikace vycházet. Hlavní třídou klientské části aplikace je zde třída HlavniOkno, obsahující ToolsPanel, Clipboard a FileGrid. Rozhraní BRServiceAsync a BRService jsou nezbytná pro samotnou komunikaci se serverem za užití RPC. O implementaci RPC metod se postará třída BRServiceImpl. Clipboard bude nástroj pro kopírování a přesun souborů, FileGrid bude mít za úkol zobrazit získaný seznam souborů do tabulkové formy, ToolsPanel bude obsahovat funkční tlačítka s naslouchači stisknutí a TextEditor bude nástrojem pro úpravu textů (v režimu prostý text i WYSIWYG). Mimo servletu BRServiceImpl zde bude ještě GWTUpload servlet. Tento servlet nebude komunikovat za užití RPC. Úkolem tohoto servletu bude zpracování nahrávání souborů na server.
5
42
VLASTNÍ APLIKACE
Obr. 17: Diagram tříd správce souborů
5.3
Implementace
Pro tvorbu klientské části aplikace bylo užito výše popsaného frameworku Google Web Toolkit (verze 2.2) s rozšířením SmartGWT (verze 2.4). Hlavní okno aplikace je rozděleno vertikálně na části (obrázek 18). V horní části se nachází nástrojový panel, uprostřed tabulka s vlastním výpisem souborů, pod ní vizuální paměťová schránka pro kopírování a přesouvání souborů a úplně dole jsou zobrazeny základní informace o aktuální složce a přihlášeném uživateli. Majoritní část komunikace se serverem probíhá za užití Remote Procedure Call, u kterého je i ošetřena maximální doba odezvy. Tato doba činí 30 vteřin, u získání výpisu souborů ze serveru potom 60 vteřin. Správce je možné zakomponovat do libovolného html či JSP souboru. Stačí v hlavičce dokumentu nalinkovat jádrový soubor SmartGWTFileBrowser.nocache.js a libovolně na stránce potom přidat div element s id=”mujBrowser”. Přístup ke správci je ošetřen požadavkem na autentizaci, ale kdyby tento přístup byl ošetřen již v kontextu stránky, je možné interní autentizaci aplikace deaktivovat. Nástrojový panel: jeho základem je SmartGWT widget ToolStrip. Na tento panel jsou umístěny tlačítka (com.smartgwt.client.widgets.ImgButton), která mají po stisknutí přiřazeny jednotlivé operace (obnovit výpis složky, zobrazení obsahu nadřazené složky, zobrazení nahrávacího klienta, zobrazit panel nastavení a zobrazit for-
5
43
VLASTNÍ APLIKACE
Obr. 18: Správce souborů
mulář pro vytvoření nové složky nebo nového souboru). Pokud se uživatel nachází v nastaveném kořenovém adresáři, je tlačítko pro vstup do nadřazeného adresáře deaktivováno a díky tomu je zablokován přístup do nežádoucích složek. Výpis souborů: výpis souborů je prováděn do widgetu ListGrid. Jedná se o tabulkový widget, kde každý řádek reprezentuje jeden soubor z dané složky. Řádky jsou rozděleny na šest sloupců. V jednotlivých sloupcích jsou: ikona, název, typ, velikost, datum poslední modifikace a tlačítko pro odstranění konkrétního souboru či složky ze serveru. Výhodou tohoto widgetu je možnost živé editace textových polí. Díky tomu je přejmenování souborů provedeno přímo uvnitř tabulky. Aktivace přejmenování je spuštěna kliknutím na název souboru. Soubory je možné řadit a seskupovat dle dat v jednotlivých sloupcích, sloupce se dají skrývat2 (pro možnost řazení je název souboru typu String, velikost souboru: long a datum modifikace: Date). Otevření souboru či složky je potom provedeno kliknutím na ikonu nebo dvojklikem na řádek. Aplikace automaticky vygeneruje odkaz na soubor a ten je otevírán přímo ve webovém prohlížeči. V případě, že prohlížeč soubor nedokáže zobrazit, dojde ke spuštění stahování souboru. Při získání informace o složce postupuje systém v těchto krocích: 1. RPC obsahující parametr String s cestou k adresáři. 2
Na obrázku 18 je zobrazena i nabídka pro seskupování a řazení
5
44
VLASTNÍ APLIKACE
2. Metoda na serveru zjistí obsah složky, vytvoří DTO, jenž je zde seznam objektů. Každý objekt obsahuje informace o jednom souboru. 3. Na klientské straně jsou data z těchto objektů upraveny a převedeny do objektů typu ListGridRecord, který je kompatibilní s použitým widgetem pro výpis souborů a je proveden samotný výpis do tohoto widgetu. Upload správce: po stisknutí daného tlačítka na nástrojovém panelu dojde k vytvoření instance nahrávacího správce. Tento správce tvoří modální okno, obsahující funkční tlačítka pro výběr souboru, zavření správce a resetování seznamu aktuálně nahraných souborů. Pro upload je zde využito funkcí knihovny GWT Upload. Po výběru souboru je automaticky spuštěno odesílání na server a zobrazí se status-bar s procentuálním ukazatelem stavu nahrávání (obrázek číslo 19). Vedle názvu aktuálně nahrávaného souboru je tlačítko, jímž je možné nahrávání přerušit nebo smazat dříve nahraný soubor. Je možné postupně vybrat libovolné množství souborů, ty jsou řazeny do fronty a jejich nahrávání začne po skončení předchozí operace. Soubory jsou nahrávány do složky, ve které se uživatel nacházel při zařazení souboru do fronty. V současné době knihovna GWT Upload umožňuje soubory přidávat do fronty postupně po jednom, ale dle vývojáře této knihovny by příští verze měla podporovat výběr více souborů zároveň. Je možné správce nahrávání zavřít a znovu otevřít v jiné složce, aniž by došlo k přerušení uploadu. Úspěšné dokončení uploadu je oznámeno zprávou obsahující název a velikost nahrané položky.
Obr. 19: Upload status
Schránka pro přesun souborů (obrázek 20): zde je užito stejného widgetu jako pro výpis souborů, schránka je ale v základním stavu skryta. Soubory a složky jsou do této schránky umístěny drag and drop přímo z tabulky s výpisem souborů. Uživatel se přesune do požadované složky a tlačítkem u souboru ve schránce je spuštěna operace kopírování nebo přesunutí. Možnosti konfigurace: tuto aplikaci je možné konfigurovat přes externí soubor my.properties (java.util.Properties), který se standardně nachází ve složce WEBINF. V souboru je možné nastavit domovský adresář, jenž bude kořenovým adresářem aplikace, požadavek na autorizaci3 , rozměry správce v pixelech a je zde možné provést lokalizaci popisků a informačních zpráv, které jsou v aplikaci zobrazeny. Všechny možná nastavení jsou v souboru standardně označena jako komentáře4 , 3 4
Je možné aktivovat/deaktivovat Se znakem # na začátku řádku
5
VLASTNÍ APLIKACE
45
Obr. 20: Schránka pro přesun/kopírování souborů
stačí toto označení odstranit a doplnit vlastní hodnoty. Umístění konfiguračního souboru je možné změnit v souboru web.xml, kde je možné dále nastavit maximální povolenou velikost nahrávaného souboru. Pokud nebude konfigurační soubor přítomen, bude jako kořenový adresář použit adresář nadřazený adresáři aplikace. Možnosti lokalizace: komponenta ve výchozím stavu obsahuje všechny popisky v českém jazyce, avšak v konfiguračním souboru my.properties je možné lokalizovat celkem 78 popisků a informačních zpráv systému. Stačí jednotlivým položkám nastavit vlastní popisek. Ve stejné složce jako my.properties se nachází i en my.properties a po nastavení tohoto souboru ve web.xml jako hlavního konfiguračního je celý správce ihned lokalizován do anglického jazyka. Uživatelské účty: jako další vlastnost této aplikace je možnost nastavení více uživatelských účtů. Nastavení je provedeno přes externí soubor users.xml (užito JAXP). XML soubor se standardně nachází ve složce WEB-INF, ale umístění je možné změnit opět úpravou inicializačních parametrů v konfiguračním souboru web.xml. Jsou zde dvě skupiny uživatelů. Administrátoři a běžní uživatelé. Administrátoři mají v každém případě dostupné všechny funkce, u běžných uživatelů je možné v konfiguračním souboru my.properties zakázat upload, mazání souborů, přejmenování souborů a tvorbu složek. Formát uživatelského souboru je ve tvaru: < SmartFile > < user > < login > Uživatelské jméno login > < password > Heslo password > < userRootFolder >/ userDir userRootFolder > < isAdmin > true isAdmin > user > SmartFile >
V tomto xml souboru je možné nastavit libovolné množství uživatelů. Každý uživatel musí mít nastaven login, heslo, typ uživatele a uživatelský adresář. Cesta k adresáři musí být relativní k nastavenému kořenovému adresáři aplikace. Uživatelé mající přístup k souboru users.xml tedy mohou díky integrovanému textovému editoru přidávat a odstraňovat uživatelské účty.
5
VLASTNÍ APLIKACE
46
Po zadání a odeslání přihlašovacích údajů je na serveru nalezena shoda jména a hesla s některým z uložených uživatelů, jsou odeslány informace o uživatelově nastavení a na straně klienta je toto nastavení aplikováno. Pokud shoda není nalezena, je zobrazena zpráva o vyplnění nesprávných přihlašovacích údajů a přístup k aplikaci není umožněn. Textový editor: aplikace je dále vybavena textovým editorem, který může pracovat v režimu úpravy prostého textu nebo v režimu jednoduchého WYSIWYG editoru. Mezi těmito režimy je možné přepínat i během úpravy textu. Editor podporuje php, htm, html, xml, css, js, txt, tex a pl soubory. Editovat lze soubory, které se již nachází na serveru, nebo je možné vytvořit soubor nový.
Obr. 21: Ukázka textového editoru. Vlevo v režimu úpravy prostého textu, vpravo v režimu WYSIWYG.
Servlety: aplikace pro práci na serveru využívá dva servlety. První servlet implementuje metody pro RPC, v souboru web.xml se nastavují jako inicializační parametry cesty k souborům my.properties a users.xml. Druhý servlet se stará o nahrávání souborů na server. Licence: pro vlastní aplikaci je nutné zvolit licenci, pod kterou bude poskytována k volnému užití. Do užšího výběru jsem vybral Open Source GNU/GPL a BSD licence. Obě nabízí volné užití komponenty avšak v případě GPL je nutné produkt užívající tuto komponentu poskytovat pod stejnou licencí a není tedy možné komerční užití. Oproti tomu v případě užití licence BSD je možné libovolné užití (včetně komerčního), jen je nutné uvést jméno autora a zřeknutí se zodpovědnosti. Jelikož se jedná o aplikaci vytvořenou jako součást závěrečné práce, zdála se mi vhodnější Open Source GPL licence.
5
VLASTNÍ APLIKACE
47
Kompatibilita: Prohlížeče postavené na jádře Webkit (chrome 11 a safari 5) neměly s vykreslením vytvořeného souborového správce sebemenší problémy. Stejně tak tomu bylo u jádra Gecko (firefox 4). Oproti tomu prohlížeč Opera 11 (jádro Presto) sice dokázal souborového správce vykreslit a bylo možné spravování některých funkcí, avšak formulářové prvky samovolně mizely a chovaly se neočekávaně. Funkce pracující s těmito prvky zde nebylo možné užívat (upload, a změna velikosti ikon). Prohlížeč Internet Explorer 9 (jádro Trident) v základním režimu nebyl schopen vykreslit žádnou část souborového správce, po přepnutí do režimu kompatibility aplikace byla kromě nahrávání souborů funkční. Viníkem těchto problémů je menší kompatibilita GWT s IE9, ta by však podle informací na stránkách frameworku měla být vyřešena v další verzi GWT. U IE 8 nebyl problém žádný. Aplikace byla funkční i na mobilních přístrojích s operačním systémem iOS 4.3.2 (v integrovaném Safari) a na starém Symbianu 3rd v prohlížeči Opera Mobile 11 5 . Ani u jednoho mobilního přístroje nebylo možné nahrát nový soubor na server. U iOS je to zapříčiněno nepřístupností souborového systému, u Opery mobile byl potom stejný problém jako u desktopové verze, kdy mizely formulářové elementy. U integrovaného prohlížeče Symbianu aplikace nebyla funkční vůbec. Na starším přístroji s Androidem 1.6 v interním prohlížeči byla aplikace opět kromě uploadu komplet funkční. Opera Mini se u všech výše uvedených platforem chovala stejně. Dokázala vykreslit pouze přihlašovací obrazovku, ale po stisknutí tlačítka přihlášení nebyla žádná odezva. Pro pohodlné ovládání na těchto přístrojích by však bylo nutné vytvořit mobilní profil aplikace, jenž by upravil velikost a rozvržení všech prvků. Stručný souhrn vlastností komponenty • Přístup pod uživatelskými účty. • Nahrávání nových souborů na server s grafickým ukazatelem stavu. • Vizuální schránka pro přesun nebo kopírování souborů a složek. • Živá editace názvu souboru uvnitř tabulky s výpisem souborů. • Editace php, htm, html, xml, css, js, txt, tex a pl dokumentů (prostý text i WYSIWYG editor). • Odstraňování souborů a složek. • Možnost vlastní lokalizace. • GNU/GPL licence. • Nutný Apache Tomcat 6.0.x a vyšší verze.
5
jen u přístrojů s alespoň 256MB RAM, u přístrojů se 128MB RAM prohlížeč spadl
6
6
DISKUZE
48
Diskuze
Na základě sepsané problematiky tvorby webových aplikací v programovacím jazyce Java byla za užití Open Source frameworku Google Web Toolkit sestavena vlastní komponenta pro správu souborů na serveru. První verze této komponenty obsahovala pár skrytých chyb, které se však díky získanému Java hostingu a dlouhodobému testování přáteli podařilo postupem času odstranit. Aplikace je přizpůsobena pro fungování na Windows i Linux serverech. V podstatě se jednalo jen o ošetření jiného chápání souborového systému v těchto OS. Funkčnost zobrazení u klienta byla testována u stejných prohlížečů jako při sestavování přehledu dostupných komponent, navíc pro zajímavost byla vyzkoušena funkčnost na některých mobilních přístrojích. Tato aplikace by tedy aktuálně mohla být využívána pro udržování aplikačních dat na serveru nebo díky možnosti správy pod uživatelskými účty jako „online USB klíčenkaÿ pro zálohu nebo rychlou výměnu dat mezi uživateli. Další možná vylepšení: Aplikace je již v této podobě plně funkční a použitelná, avšak pro pohodlnější užívání by dále bylo vhodné provést rozšíření o další funkce. Například by bylo na místě vytvořit více typů uživatelských účtů, kde by se nacházela i skupina s ještě vyššími pravomocemi. Tito super-uživatelé by mohli například spravovat uživatelské účty přímo přes GUI. Dále by bylo vhodné umožnit ukládání uživatelských účtů do SQL databází a rozšířit možnosti nastavení jednotlivých profilů. Jako další možné vylepšení se nabízí integrace jednoduchého editoru obrázků či fotografií, který by umožňoval alespoň úpravu rozlišení nebo vkládání vlastního vodotisku.
7
7
ZÁVĚR
49
Závěr
Tato bakalářská práce se zabývala webovými aplikacemi v programovacím jazyce Java Enterprise Edition. Byla sepsána základní problematika tvorby těchto aplikací, čtenář je seznámen se základní konfigurací a s požadavky pro provoz vlastního serveru s podporou Javy. V práci byl dále sestaven přehled volně dostupných komponent pro vývoj aplikací v J2EE. I když je Java sama o sobě velmi rozšířený jazyk, je množství volně dostupných komponent velmi malé. Je to zapříčiněno zejména omezenou dostupností bezplatného Java hostingu. PHP dnes podporuje téměř každý poskytovatel, avšak nalézt podporu pro Javu je obtížnější a pro bezplatný Java hosting je to téměř nemožné. Většina začínajících programátorů proto raději sáhne při tvorbě menších projektů k jiné platformě. Vlastní komponenta souborového správce, vytvořená jako součást této práce, prezentuje možnosti frameworku Google Web Toolkit. Výhodou užití GWT není jen moderní vzhled GUI komponent, ale i množství dodatečných parametrů a funkcí, které každá komponenta poskytuje. Moderní vzhled v sobě nese menší daň v podobě výpočetní náročnosti při vykreslování stránky na klientském zařízení. Nejedná se však o žádné extrémní požadavky a aplikace není problém spustit na modernějším smartphone. Oproti shromážděným komponentám obsahuje vlastní souborový správce nejen editor prostého textu, ale navíc ještě možnost úpravy textu pomocí jednoduchého WYSIWYG editoru. Většina z dostupných komponent při výpisu obsahu složky vykresluje správce kompletně včetně GUI nanovo. Vlastní správce díky asynchronní komunikaci pouze aktualizuje výpis uvnitř tabulky a není nutné zdlouhavě načítat a vykreslovat všechny prvky. Další výhodou vlastního správce je jeho rychlá a kompletní lokalizovatelnost, která spočívá v pouhém přidání vlastního textového popisku uvnitř konfiguračního souboru. Takto je možné upravit celkem 78 systémových popisků a informačních zpráv. Editor je standardně v českém jazyce, avšak v balíku je přítomen i konfigurační soubor s anglickou lokalizací. Vlastní komponenta dále obsahuje vizuální paměťovou schránku pro přesun a kopírování souborů či složek, do které je možné přidávat neomezené množství položek, a uživatel má tedy neustálý přehled o všech souborech ve schránce obsažených. Dalšími významnými funkcemi správce je možnost živé editace názvu souboru uvnitř tabulky, vícenásobný upload s grafickým status barem a přístup k aplikaci pod řízenými uživatelskými účty.
8
8
LITERATURA
50
Literatura
JENDROCK, Eric. The Java EE 6 Tutorial : Basic Concepts. Fourth Editon. Ann Arbor (Michigan) : Apress, 2010. 559 s. ISBN 978-013-708185-1, ISBN 0-13708185-5. GONCALVES, Antonio. Beginning Java TM EE 6 Platform with GlassFish TM 3 : From Novice to Professional. Second Edition. New York : Springer Science + Bussines Media, 2010. 508 s. ISBN 978-1-4302-2889-9. GONCALVES, Antonio. Professional Apache Tomcat 5. Wiley Publishing, Inc., Indianapolis, Indiana, 2004. 598 s. ISBN 0-7645-5902-8. HALL, Marty. [online] Core Servlets and JavaServer Pages. 2008. Dostupné z WWW: LINDFORS, Juha; FLEURY, Marc; The Jboss Group. JMX : Managing J2EE with Java Management Extensions. USA : Sams Publishing, 2000. 388 s. [cit. 201102-05]. ISOMORPHIC SOFTWARE, Inc. Smart GWT Quick Start Guide [online] San Francisco: Isomorphic Software, Inc., 2010. 81 s. Dostupné z WWW: GUERMEUR, Daniel; UNRUH, Amy. Google App Engine Java and GWT Application Development . Birmingham: Packt Publishing Ltd., November 2010. 231 s. ISBN 978-1-849690-44-7. KEITH, Mike; SCHINCARIOL, Merrick. Pro EJB 3: Java Persistence API. USA : Apress, 2006. 453 s. ISBN 978-1-59059-645-6. BOND, Martin. Teach Yourself : J2EE in 21 Days.Indianapolis (Indiana) : Sams Publishing, 2002. 1094 s. ISBN 0-672-32384-2. RICHARDSON, D. Asynchronous JavaScript and XML (AJAX) [online]. 2006 [cit. 2011-02-05]. Dostupné z WWW: SHANNON, Bill. JavaT M 2 Platform Enterprise Edition Specification, v 1.2 [online]. Palo Alto (California) : Sun Microsystems, Inc., 1999 [cit. 2011-02-05]. Dostupné z WWW: SHANNON, Bill. JavaT M 2 Platform Enterprise Edition Specification, v 1.3 [online]. Palo Alto (California) : Sun Microsystems, Inc., 7/27/01 [cit. 2011-02-05]. Dostupné z WWW: SHANNON, Bill. JavaT M 2 Platform Enterprise Edition Specification, v 1.4 [online]. Santa Clara (California) : Sun Microsystems, Inc., 4/28/06 [cit. 2011-02-05]. Dostupné z WWW:
8
LITERATURA
51
SHANNON, Bill. JavaT M Platform, Enterprise Edition (Java EE) Specification, v5 [online]]. Santa Clara (California) : Sun Microsystems, Inc., May 8, 2006 [cit. 2011-02-05]. Dostupné z WWW: CHINNICI, Roberto; SHANNON, Bill. JavaT M Platform, Enterprise Edition (Java EE) Specification, v6 [online]].Santa Clara (California) : Sun Microsystems, Inc, 11/06/09 [cit. 2011-02-05]. Dostupné z WWW: BURNS, Ed; KITAIN, Roger. JavaServerT M Faces Specification: Version 2.0 [online]. Santa Clara (California) : Sun Microsystems, Inc, June 2009 [cit. 2011-0205]. Dostupné z WWW: MANI, John. JavaMailTM API Design Specification : Version 1.4 [online]. Santa Clara (California) : Sun Microsystems, Inc. 17 April 2006 [cit. 2011-02-06]. Dostupné z WWW: KOTAMRAJU, Jitendra. The JavaT M API for XML-Based Web Services (JAXWS) 2.2 [online] . Santa Clara (California) : Sun Microsystems, Inc, Dec 10, 2009 [cit. 2011-02-05]. Dostupné z WWW: ORACLE [online]. Java TM Authentication and Authorization Service (JAAS) . August 8, 2001 [cit. 2011-02-05]. Dostupné z WWW: APACHE TOMCAT [online]. Apache Tomcat Versions.. 2011 [cit. 2011-05-08]. Dostupné z WWW: ORACLE [online]. The History of Java Technology. 2011 [cit. 2011-05-08]. Dostupné z WWW: SHAMSUDDIN, Ahammad. Google Web Toolkit 2 Application Development Cookbook: Over 70 simple but incredibly effective practical recipes to develop web applications using GWT with JPA, MySQL, and iReportBirmingham: Packt Publishing Ltd., November 2010. 231 s. ISBN 978-1-849512-00-8. W3SCHOOLS.COM [online]. Browser Statistics. 2011 [cit. 2011-05-08]. Dostupné z WWW:
9
9
PŘÍLOHY
52
Přílohy
CD příloha práce obsahuje: • Eclipse projekt vlastní komponenty s kompletními zdrojovými kódy a se všemi externími knihovnami. • War balík vlastní komponenty. • Java dokumentaci. Ukázka konfiguračního souboru my.properties Základní nastavení RootFolder=Kořenový adresář aplikace EnableExtendedBrowsing=Tento parametr umožňuje práci správce mimo webapps složku ExtendedPath=C:/temp NeedAuth=Jestli bude požadováno uživatelské jméno a heslo (dle souboru users.xml) Práva pro ne-administrátory (v závorkách defaultní hodnoty, pokud zde nebude parametr nastaven) DisableDelete=Zákaz odstraňování položek (false) DisableUpload=Zákaz uploadu (false) DisableNewFolder=Zákaz tvorby složek (false) DisableRename=Zákaz přejmenovávat položky (false) Rozměry správce v pixelech Width=820 Height=500 Vlastní lokalizace(při smazání parametru z konfiguračního souboru je použita čeština) ComFailed=Komunikace se serverem selhala! NewFileName=Zadejte jméno souboru EmptyFolderName=Nebylo vyplněno jméno složky! ConfirmDelete=Opravdu chcete ostranit tento soubor? LoginBTNLabel=Přihlásit LogoutBTNLabel=Odhlásit WrongPassword=Nesprávné uživatelské jméno nebo heslo! Welcome=Vítejte CannotReadAuthProperty=Nesprávně nastavená proměnná NeedAuth! Hlavičkové Labely MainPanelName=Popisek hlavního panelu CopyOrMovePanelName=Popisek panelu schránky HeaderName=Jméno souboru HeaderSize=Velikost souboru HeaderType=Typ souboru HeaderDelete=Odstranit HeaderModified=Naposledy změněno Popisky schránky HeaderMove=Přesunout HeaderCopy=Kopírovat HeaderOriginalPath=Původní umístění souboru EmptyCopyGrid=Žádná položka ve schránce TTMove=Kliknout pro přesun souboru/složky do aktuální složky TTCopy=Kliknout pro zkopírování souboru/složky do aktuální složky ConfirmMoveMessage=Opravdu chcte přesunout soubor ConfirmCopyMessage=Opravdu chcete kopírovat soubor FromFolder=ze složky ToFolder=do složky
9
PŘÍLOHY
53
CopyDone=Kopírování úspěšně dokončeno! FolderCopyFailed=Nepodařilo se zkopírovat soubor! CannotCopyFile=Není možné zkopírovat soubor! CopyFinished=Kopírování dokončeno CannotMoveFile=Není možné přesunout soubor!! FileMoved=Soubor úspěšně přesunut! Textový editor CannotReadFile=Nelze načíst textový soubor! SaveErr=Nepodařilo se uložit soubor!! SavedMessage=Soubor uložen!!! EditorSaveBtnLabel=Uložit EditorCloseBtnLabel=Zavřít EditorHeader=Textový editor EditorCloseMessage=Opravdu chcete zavřit editor? EditorSaveMessage=Opravdu chcete uložit soubor? ConfirmSwitch=Opravdu chcete přepnou do režimu WYSIWYG? Z html dokumentů budou odebrány tagy html a head!!! Zobrazení popisku tlačítek při přejetí myši TTReload=Aktualizovat TTBack=O úroveň výš TTDisabled=Nacházíte se na nejvyšší úrovni TTUpload=Nahrát nový soubor TTNewFolder=Vytvořit Složku TTAddAndConfirm=Zadejte jméno složky a potvrďte TTConfirm=Kliknout pro potvrzení TTCancel=Kliknout pro zrušení TTOpen=Otevřít TTSettings=Zobrazit/skrýt nástrojový panel TTMove=Přesunout Zprávy systému: MessageFolderExists=Složka s tímto jménem již existuje MessageFolderCreated=Složka úspěšně vytvořena MessageFolderError=Nelze vytvořit složku MessageFolderDeleted=Složka smazána MessageFolderDeleteError=Nelze smazat složku MessageFileNotExists=Soubor neexistuje MessageFileExists=Soubor s tímto jménem již existuje MessageFileWasNotDeleted=Soubor nebyl smazán MessageFileDeleted=Soubor byl smazán MessageFileRenameError=Nelze přejmenovat soubor MessageFileRenameOK=Soubor úspěšně přejmenován UploadLabel=Nahrát nový soubor Panel Nastavení IconSize1Text=Nejmenší ikony IconSize2Text=Malé ikony IconSize3Text=Střední ikony IconSize4Text=Velké ikony EnableAutoreloadText=Automaticky znovu načíst výpis souborů po změně DisableAutoreloadText=Manuálně znovu načíst výpis souborů po změně
9
PŘÍLOHY
54
Tab. 11: Přehled specifikací jednotlivých verzí J2EE. (SHANNON, 1999; SHANNON, 2001; SHANNON, 2006; CHINNICI, 2009) Specifikace J2EE 1.2 J2EE 1.3 J2EE 1.4 Java EE 5 Java EE 6 JDBC 2.0 2.0 3.0 3.0 3.0 EJB 1.1 2.0 2.1 3.0 3.1 Servlets 2.2 2.3 2.4 2.5 3.0 JSP 1.1 1.2 2.0 2.1 2.2 JMS 1.0 1.0 1.1 1.1 1.1 JTA 1.0 1.0 1.0 1.1 1.1 JNDI 1.2 1.2 1.2 1.2 1.2 JTS 1.0 1.0 1.0 1.0 1.0 JavaMail 1.1 1.2 1.3 1.4 1.4 JAF 1.0 2.0 3.0 1.1 1.1 JAXP 1.1 1.2 1.3 1.3 Connector 1.0 1.5 1.5 1.6 JAAS 1.0 1.0 1.0 1.0 Java Web Services 1.1 1.2 1.3 JAXR 1.0 1.0 1.0 JAX-RPC 1.1 1.1 1.1 SAAJ 1.2 1.3 1.3 J2EE Management 1.0 1.1 1.1 J2EE Deployment 1.1 1.2 1.2 JMX 1.2 1.2 1.2 JACC 1.0 1.1 1.4 JSF 1.2 2.0 JSTL 1.2 1.2 JAX-WS 2.0 2.2 JAXB 2.0 2.2 Web Services Metadata 2.0 2.1 StAX 1.0 1.0 JSP Debugging 1.0 1.0 Common Annotations 1.0 1.1 EL 2.2 JAX-RS 1.1 JASPIC 1.0 Java Persistence 2.0 Bean Validation 1.0 Managed Beans 1.0 Interceptors 1.1 CDI for Java 1.0 DI for Java 1.0