vysoke u´ cenˇ ´i technick e v brn´ eˇ - core.ac.uk · retick a a odborn a v ychodiska re sen...

VYSOKE UCENI TECHNICKE V BRNEBRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMACNICH TECHNOLOGIIUSTAV INFORMACNICH SYSTEMU

FACULTY OF INFORMATION TECHNOLOGYDEPARTMENT OF INFORMATION SYSTEMS

APLIKACE NA PLATFORME MOZILLAAPPLICATIONS ON MOZILLA PLATFORM

DIPLOMOVA PRACEMASTER’S THESIS

AUTOR PRACE Bc. JAN KUPCIKAUTHOR

VEDOUCI PRACE Ing. RADEK BURGET, Ph.D.SUPERVISOR

BRNO 2007

Zadanı diplomove prace

Resitel: Kupcık Jan, Bc.Obor: Informacnı systemyTema: Aplikace na platforme MozillaKategorie: Web

Pokyny:

1. Seznamte se s aplikacnı platformou Mozilla

2. Prostudujte technologie RDF, XUL a JavaScript v kontextu vyvoje aplikacı na teto plat-forme

3. Navrhnete rozsırenı prohlızece Firefox pro sledovanı zmen na webovych strankachvyuzıvajıcı popsanych technologiı

4. Implementujte navrzene rozsırenı na platforme Mozilla

5. Proved’te shrnutı vysledku a navrhnete dalsı mozne upravy

Literatura:

• Dokumentace dostupna na Mozilla.org

Pri obhajobe semestralnı casti diplomoveho projektu je pozadovano:

• Body 1 az 3

Podrobne zavazne pokyny pro vypracovanı diplomove prace naleznete na adresehttp://www.fit.vutbr.cz/info/szz

Technicka zprava diplomove prace musı obsahovat formulaci cıle, charakteristiku soucasneho stavu, teo-

reticka a odborna vychodiska resenych problemu a specifikaci etap, ktere byly vyreseny v ramci rocnıkoveho a

semestralnıho projektu (30 az 40% celkoveho rozsahu technicke zpravy).

Student odevzda v jednom vytisku technickou zpravu a v elektronicke podobe zdrojovy text technicke zpravy,

uplnou programovou dokumentaci a zdrojove texty programu. Informace v elektronicke podobe budou ulozeny

na standardnım pamet’ovem mediu (disketa, CD-ROM), ktere bude vlozeno do pısemne zpravy tak, aby nemohlo

dojıt k jeho ztrate pri bezne manipulaci.

Vedoucı: Burget Radek, Ing., Ph.D., UIFS FIT VUTDatum zadanı: 28. unora 2006Datum odevzdanı: 22. kvetna 2007

Licencnı smlouva

Licencnı smlouva v kompletnım znenı je ulozena v archivu Fakulty informacnıch technologiıVysokeho ucenı technickeho v Brne.

Vynatek z licencnı smlouvy:

Clanek 2Udelenı licencnıho opravnenı

1. Autor touto smlouvou poskytuje nabyvateli opravnenı (licenci) k vykonu prava uvedene dılonevydelecne uzıt, archivovat a zprıstupnit ke studijnım, vyukovym a vyzkumnym ucelumvcetne porizovanı vypisu, opisu a rozmnozenin.

2. Licence je poskytovana celosvetove, pro celou dobu trvanı autorskych a majetkovych pravk dılu.

3. Autor souhlası se zverejnenım dıla v databazi prıstupne v mezinarodnı sıti:

� ihned po uzavrenı teto smlouvy

� 1 rok po uzavrenı teto smlouvy

� 3 roky po uzavrenı teto smlouvy

� 5 let po uzavrenı teto smlouvy

� 10 let po uzavrenı teto smlouvy

(z duvodu utajenı v nem obsazenych informacı).

4. Nevydelecne zverejnovanı dıla nabyvatelem v souladu s ustanovenım § 47b zakonac. 111/1998 Sb., v platnem znenı, nevyzaduje licenci a nabyvatel je k nemu povinen aopravnen ze zakona.

AbstraktCılem teto diplomove prace je seznamit se s aplikacnı platformou Mozilla – jejı struk-

turou, technologiemi, ktere vyuzıva, a zpusobem vyvoje samostatne bezıcıch i rozsirujıcıchaplikacı, ktere tuto platformu vyuzıvajı (napr. webovy prohlızec Firefox, postovnı klientThunderbird). Prace zahrnuje relevantnı informace o vyuzıvanych jazycıch, kterymi jsouXUL, CSS, JavaScript, RDF/XML a dalsı. Jsou zde take rozebrany objektove orientovaneprincipy pouzitelne v jazyce JavaScript v.1.7. Dalsı casti se venujı problematice tvorbya vyuzıvanı komponent platformy i aplikacı. Informace o platforme jsou zavrseny uve-denım moznostı ladenı a nasledneho prevodu do distribuovatelne podoby. Tyto znalostijsou nasledne pouzity pri tvorbe aplikace umoznujıcı sledovanı zmen dokumentu v sıt’ovemprostredı. Lze zde najıt jejı navrh a nektere detaily implementace vztahujıcı se k obecnemuvyvoji aplikacı na uvedene platforme.

Klıcova slovaMozilla, XUL, XBL, JavaScript, XPCOM, IDL, RDF, XML, XPI

AbstractThe goal of the thesis is to study the Mozilla application platform – its structure, used

technology, and the ways of development of standalone applications and extensions forthe applications based on this platform (e.g. the Firefox web browser, the Thunderbirde-mail client). The thesis also contains relevant information about the used programminglanguages such as XUL, CSS, JavaScipt, RDF/XML and others. It describes the objectoriented principles available in the JavaScript v.1.7 language. Next parts are dedicated tocreating and using the platform components and the applications. The information aboutthe platform is concluded by a presentation of the debugging and deployment possibilities.This knowledge is used to create an application able to watch changes of documents in anetwork environment. The thesis describes the application design and some details relatedto the general development of applications based on the discussed platform.

KeywordsMozilla, XUL, XBL, JavaScript, XPCOM, IDL, RDF, XML, XPI

CitaceJan Kupcık: Aplikace na platforme Mozilla, diplomova prace, Brno, FIT VUT v Brne, 2007

Aplikace na platforme Mozilla

ProhlasenıProhlasuji, ze jsem tuto diplomovou praci vypracoval samostatne pod vedenım pana

Ing. Radka Burgeta, Ph.D. Uvedl jsem vsechny literarnı prameny a publikace, ze kterychjsem cerpal.

. . . . . . . . . . . . . . . . . . . . . . .Jan Kupcık

22. kvetna 2007

c© Jan Kupcık, 2007.Tato prace vznikla jako skolnı dılo na Vysokem ucenı technickem v Brne, Fakulteinformacnıch technologiı. Prace je chranena autorskym zakonem a jejı uzitı bez udelenıopravnenı autorem je nezakonne, s vyjimkou zakonem definovanych prıpadu.

Obsah

1 Uvod 21.1 Prehled nasledujıcıch kapitol . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Formatovanı textu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Soucasny stav 6

3 Architektura platformy Mozilla 8

4 Tvorba uzivatelskeho rozhranı 104.1 Obsah XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Urcenı vzhledu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1.2 Podpora pro definici chovanı . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Kaskadove styly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Definice externıch retezcu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3.1 DTD entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.2 Textove konstanty . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3.3 Volba aktivnıho jazyka . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Programovanı chovanı 175.1 Programovacı jazyky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1.1 Objektove programovanı v jazyce JavaScript . . . . . . . . . . . . . 185.2 XPCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2.1 Mozne problemy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.2 Vytvarenı komponent . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.3 Bezpecnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Datova uloziste, RDF 296.1 Ukladanı znalostı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 Dotazovanı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.3 Podpora v XPCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7 Ladenı a testovanı aplikacı 337.1 Konfigurace prohlızece Firefox . . . . . . . . . . . . . . . . . . . . . . . . . . 337.2 Uprava aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.3 Ladenı uzivatelskeho rozhranı . . . . . . . . . . . . . . . . . . . . . . . . . . 357.4 Ladenı kodu aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.5 Ladenı komponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.6 Ladenı RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1

8 Distribuce aplikacı 39

9 Aplikace DocWatcher 419.1 Navrh aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.1.1 Stanovenı pozadavku . . . . . . . . . . . . . . . . . . . . . . . . . . . 429.1.2 Architektura aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . 429.1.3 Ukladanı entit do databaze . . . . . . . . . . . . . . . . . . . . . . . 43

9.2 Detaily implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.2.1 Datova vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.2.2 Uzivatelske rozhranı . . . . . . . . . . . . . . . . . . . . . . . . . . . 469.2.3 Hlavnı okno aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . 469.2.4 Dialogove okno vlastnostı odkazu . . . . . . . . . . . . . . . . . . . . 479.2.5 Proces kontroly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

9.3 Zaverecne poznamky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

10 Zaver 52

2

Kapitola 1

Uvod

Vyvoj kazdeho softwaroveho produktu zacına stanovenım pozadavku, ktere by mel splnovat.Mezi tyto pozadavky take bezesporu patrı vyber operacnıch systemu a hardwarovycharchitektur, na kterych musı vysledny produkt fungovat. Na zaklade tohoto vyberu astanovenych cenovych nakladu je pak potreba zvolit, zda aplikace bude vyuzıvat pouzeaplikacnı programove rozhranı podporovanych operacnıch systemu, zda bude postavena nanejake multiplatformnı programove knihovne, nebo bude pracovat v urcitem aplikacnımprostredı, jehoz sluzby bude vyuzıvat. Toto rozhodnutı je klıcove, protoze ma vliv na bu-doucı architekturu aplikace, muze omezovat mnozinu vhodnych programovacıch jazyku, vefazi provozu muze ovlivnit vykonnost, pouzitelnost a dalsı parametry.

Vyber vhodne programove zakladny pro novy software byl resen i roku 1998 v MozillaOrganization. Doslo totiz k uvolnenı vetsiny zdrojovych kodu prohlızece Netscape Com-municator 5.0 pod licenci Open source a nasledne bylo rozhodnuto, ze zdrojovy kod je jiznatolik neudrzovatelny, ze je potreba jej cely prepsat. Cely projekt byl vsak tak ambicioznıa rozsahly, ze az po ctyrech letech byl vydan novy webovy prohlızec Mozilla 1.0. Duvodemzdrzenı byl fakt, ze jako zaklad nebyla pouzita zadna stavajıcı knihovna, avsak byla vyvi-nuta zcela nova zakladna pro internetove aplikace s plne programovatelnym uzivatelskymrozhranım a modularnı architekturou – vznikla aplikacnı platforma Mozilla.

Postupem casu pribyly nove aplikace, ktere tuto platformu vyuzıvajı. Jde napr. o Sea-Monkey (nastupce Mozilla Suite, k jehoz ukoncenı doslo v roce 2003), velice uspesny we-bovy prohlızec Firefox, postovnı klient Thunderbird, HTML editor Nvu, hudebnı prehravacSongbird, SIP klient ZAP a dalsı.

Ackoli se aplikacnı platforma Mozilla dobre hodı pro vytvarenı novych volne siritelnychdesktopovych aplikacı v sıt’ovem prostredı, je vyvojari dost prehlızena. Duvodem muze bytneznalost – existuje malo tech, kterı vı, co vsechno se nachazı za prohlızecem Firefox, atake vetsı naroky na studium teto problematiky – v sıti Internet lze najıt nemale mnozstvınavodu, jak vytvorit jednoduchou aplikaci, avsak aktualnı uceleny popis vytvarenı slozitejsıaplikace neprinası zadny z nich. Jeden ze dvou cılu teto diplomove prace je proto navazat napublikaci [1] a doplnit shromazdene informace a odkazy na zdroje platne pro vyvoj aplikacına platforme Mozilla s jadrem odpovıdajıcım XULRunner v.1.8, upozornit na chyby v jadre,ktere dosud nebyly opraveny a nekorektnı informace uvest na spravnou mıru. Prace tedyrozebıra problematiku vytvarenı samostatne bezıcıch aplikacı pro XULRunner i rozsirujıcıchaplikacı (oznacovane jako extensions), ukazuje nektere principy vytvarenı uzivatelskehorozhranı, programovanı chovanı, tvorbu komponent systemu a praci s datovymi ulozistive formatu RDF. Nemala cast je venovana ladenı aplikacı a vse je zavrseno informacemio moznostech prevodu do distribuovatelne podoby a sprave aktualizacı.

3

Druhym cılem prace je vyuzıt nabyte znalosti a vytvorit rozsırujıcı aplikaci pro vybraneaplikace zalozene na platforme Mozilla, ktera ma resit neexistenci volne siritelneho multi-platformnıho nastroje pro sledovanı zmen dokumentu v sıt’ovem prostredı. Pouzitı tohotorozsırenı si lze ve svete elektronickych dokumentu predstavit temer kdekoli – chteli bychomsi udrzovat prehled o cenach urcitych produktu, hlıdat si vydanı novych verzı programu,zjist’ovat, zda se na forech hovorı o tematech, ktera nas zajımajı. Studenty muze zajımat, zdapribyly nebo byly zmeneny informace na strankach predmetu, je-li jiz opravena zkouska,ktere nove kulturnı akce skola pripravuje. Diplomova prace tedy dale obsahuje navrh anektere dulezite aspekty implementace z hlediska obecneho vyvoje aplikacı pro tuto plat-formu. Nastroj pro sledovanı zmen dokumentu byl pojmenovan DocWatcher.

Diplomova prace navazuje na predchozı semestralnı projekt, ve kterem byly uvedenyzakladnı informace o vyvoji aplikacı na platforme Mozilla. Tato prace uvedene informacerozsiruje predevsım o poznatky z praktickeho pouzıvanı, pridany jsou kapitoly o XPCOMa ladenı aplikacı. Druha cast, navrh aplikace DocWatcher, je ze semestralnıho projektuprebran a mırne upraven tak, aby vyhovoval vlastnostem platformy Mozilla. Doplneny jsoupak informace tykajıcı se implementace aplikace a par zaverecnych poznamek, ktere mohouvyvojari pomoci.

1.1 Prehled nasledujıcıch kapitol

• Soucasny stav – uvadı programove knihovny a softwarove platformy, ktere jsou dos-tupne pro navrh novych aplikacı.

• Architektura platformy Mozilla – zabyva se architekturou platformy Mozilla, uvadızjednoduseny diagram navaznosti jednotlivych vrstev a vysvetluje jejich funkci.

• Tvorba uzivatelskeho rozhranı – obsahuje informace o zpusobu vytvarenıuzivatelskych rozhranı vyuzıvajıcıch jazyk XUL, odlisnostech v definicıchkaskadovych stylu a popisuje, jak aplikaci pripravit pro provoz ve vıcejazycnemprostredı.

• Programovanı chovanı – vypisuje seznam podporovanych jazyku, ktere lze vyuzıvat priprogramovanı a nasledne se detailne zabyva moznostmi jazyka JavaScript, predevsımzpusobem realizacı objektove orientovanych principu. Nasledne se venuje vyuzıvanı atvorbe vlastnıch komponent.

• Datova uloziste, RDF – predstavuje principy jazyka RDF/XML, uvadı, jakymzpusobem lze zapisovat znalosti a jake prostredky platforma pro praci s nimiposkytuje.

• Ladenı a testovanı aplikacı – informuje o zpusobech ladenı a testovanı aplikacıvyuzıvajıcıch jazyk JavaScript, ktere prostredky lze vyuzıt, nutne upravy kodu anastavenı prostredı.

• Distribuce aplikacı – popisuje adresarovou strukturu, kterou je vhodne dodrzovat aukazuje, jak prevest sadu souboru do podoby, kterou lze predat uzivatelum.

• Aplikace DocWatcher – stanovuje pozadavky kladene na tuto aplikaci, uvadı jejı struk-turu, pojednava o zpusobu resenı uzivatelskeho rozhranı a nekterych aspektu chovanıaplikace a popisuje vybrane aspekty implementace, ktere jsou dulezite z pohleduobecneho vyvoje aplikacı na teto platforme.

4

• Zaver – hodnotı vysledky teto prace, jejı prınos a dalsı moznosti rozvıjenı v budoucnu.

5

1.2 Formatovanı textu

Pro lepsı citelnost jsou v textu pouzity ruzne typy pısma.

• identifikatory, hodnoty konstant, klıcova slova a vypisy kodu

• slovnı vyjadrenı v anglictine

• oznacenı souboru a adresaru

6

Kapitola 2

Soucasny stav

Existuje nekolik moznych cest, kterymi se muze ubırat vyvoj novych softwarovychprojektu. Prvnı z nich je vhodna pro aplikace, na ktere jsou kladeny zvlastnı pozadavkyz hlediska funkcnosti, vykonnosti nebo treba grafickeho uzivatelskeho rozhranı (GUI).Tyto aplikace vyuzıvajı prımo sluzeb operacnıho systemu, na kterem bezı, pomocı volanıfunkcı aplikacnıho programoveho rozhranı (API). Uvedeny zpusob je vyuzıvan naprıkladu systemovych komponent daneho operacnıho systemu, kde ma programator moznostdetailne rıdit vsechny procesy, ktere se zde provadejı. Obecne je na teto urovni takevyuzıvan neobjektovy jazyk C, jehoz prekladem a optimalizacı se da dosahnout rychlejsıodezvy a vyssıho vypocetnıho vykonu. Nevyhodou ovsem muze byt vetsı casova narocnosttvorby projektu zpusobena vyssım mnozstvım zdrojoveho kodu, ktery pozadovanoufunkcnost implementuje. S tım nasledne take souvisı zvysene mnozstvı usilı, ktere jepotreba vynalozit k odladenı a otestovanı tohoto kodu a zaroven dıky pouzitı jazyka Cmuze struktura programu pri vetsıch zmenach rychleji degradovat.

Uvedene nevyhody muzeme castecne eliminovat vyuzitım programovych knihoven,naprıklad nabızejıcıch podporu pro snadnejsı prıstup k uzivatelskemu rozhranı. Toto jedruha cesta. Knihovny, v operacnım systemu Windows jmenujme MFC1, pak zapouzdrujıvolanı API funkcı do logickych celku, vytvarejı tedy vyssı uroven abstrakce. Dıky toho, zese zde jiz uplatnujı objektove jazyky, jako je C++, je proces vyvoje rychlejsı a kodaplikace robustnejsı, nez kdyby byla pouzita prımo volanı API funkcı.

Tretı varianta, ktera stale vıce zıskava na oblibe, je vystavenı aplikace na vhodne ap-likacnı platforme. V tomto prıpade program jiz ke sve cinnosti pouzıva API zcela minimalne,nebo vubec, protoze platforma abstrahuje vetsinu potrebnych castı operacnıho systemu –nabızı vlastnı trıdy zapouzdrujıcı GUI, praci se soubory, prıstup k sıt’ovym prostredkum,spravu pameti a procesu, komunikaci mezi procesy a dalsı. Aplikacnı platforma tedy tvorıvrstvu, ktera oddeluje aplikaci od operacnıho systemu. Tato vrstva se sklada ze dvou castı –rozhranı, ktere je dostupne aplikaci a ktere je zaroven nemenne, a dale vlastnı kod platformy,ktery implementuje nabızene sluzby. Jestlize je platforma oznacena jako multiplatformnı,lze hostujıcı aplikace provozovat na podporovanych operacnıch systemech a hardwarovycharchitekturach. V tomto prıpade je pouze jina implementace teto platformy, avsak dıkynezmeneneho rozhranı nenı nutne menit zdrojovy kod aplikace.

Dle typu programovacıch jazyku lze nasledne rozdelit softwarove platformy na triskupiny. Prvnı tvorı platformy, kde jsou hostitelske aplikace psany v prelozitelnem jazycedo binarnıho kodu procesoru, na kterem bude program spusten – naprıklad C++. Pro

1http://msdn2.microsoft.com/en-us/library/d06h2x6e(VS.80).aspx

7

http://msdn2.microsoft.com/en-us/library/d06h2x6e(VS.80).aspx

prenos mezi ruznymi systemy nenı potreba zasahovat do zdrojovych kodu, avsak je nutnajejich kompilace pomocı kompilatoru urceneho pro vyslednou hardwarovou architekturu aoperacnı system. Aplikace jsou kompatibilnı pouze na urovni API. Do teto skupiny patrınaprıklad QT2, wxWidgets3 a dalsı.

Dale existujı platformy, kde zdrojovy kod hostitelske aplikace nenı kompilovan donativnıho kodu procesoru, ale do specialnıho mezikodu, ktery je distribuovan. Uzivatel sinainstaluje platformu urcenou pro jeho systemovou konfiguraci a ta po spustenı aplikaceautomaticky za behu preklada mezikod do nativnıho kodu procesoru, pricemz ten jenasledne spusten. Proces, ktery tuto cinnost provadı, se nazyva Just-In-Time (JIT)kompilator. Vyhodou je tedy jedina spustitelna verze softwaroveho produktu propodporovane systemove konfigurace, avsak za cenu nutnosti mıt nainstalovane danebehove prostredı na pocıtaci a pomalejsıch reakcı programu pri jeho spustenı. Sem patrıJava4, .NET Framework5.

Do poslednı skupiny se radı platformy vyuzıvajıcı jazyky, ktere nejsou pred distribucıkompilovany. Aplikace jsou tedy sıreny s kodem v otevrene textove podobe. Po spustenıaplikace je zdrojovy kod v prıpade potreby vybalen a behove prostredı platformy nasledneprovadı interpretaci kodu. Toto resenı je nejpomalejsı ze vsech vyse uvedenych a hodı sepro nenarocne aplikace, ktere jsou volne siritelne a prozrazenı kodu je irelevantnı. Pod-statnou navyhodou je pak problematicka kontrola nejen syntaktickych chyb, protoze kodje vyhodnocovan az v prubehu interpretace, a tak na chyby je programator upozornen azv okamziku jejich potencionalnıho spustenı. Zastupcem je naprıklad aplikacnı platformaMozilla6. Obecne sem muzeme zaradit i dalsı skriptovacı jazyky; pak je jen otazka, jakbohate aplikacnı rozhranı dany interpret kodu nabızı.

Ackoli by se mohlo zdat, ze platforma Mozilla dıky vyse uvedenym vlastnostem nenıprılis vhodna pro sirsı pouzitı, opak je pravdou. Dukazem jsou naprıklad uspesny webovyprohlızec Firefox nebo postovnı klient Thunderbird. Tato platforma nabızı jednoduchyzpusob programovanı zalozeny na jazyku XML, ktery definuje uzivatelske rozhranı, a jazykuJavaScript, jenz je pouzıvan pro definovanı chovanı aplikace. Vysledek lze beze zmenyspustit na vıce nez 10 operacnıch systemech, viz [1, 16]. Hlavnı vyhodou je vsak prıtomnostkomponent umoznujıcıch zobrazit (X)HTML dokument, aktivne se na nej napojit a praco-vat s jeho obsahem. Prave tato vlastnost a vysoky pocet podporovanych systemu vyzdvihujıplatformu Mozilla nad ostatnı.

Bohaty seznam dostupnych podpurnych knihoven i softwarovych platforem lze najıtv [25].

2http://www.trolltech.com/3http://www.wxwidgets.org/4http://java.sun.com/5http://msdn2.microsoft.com/en-us/netframework/default.aspx6http://xulplanet.com/

8

http://www.trolltech.com/

http://www.wxwidgets.org/

http://java.sun.com/

http://msdn2.microsoft.com/en-us/netframework/default.aspx

http://xulplanet.com/

Kapitola 3

Architektura platformy Mozilla

Zjednodusene schema architektury je uvedeno na obrazku 3.1. Podrobnejsı pohled lze najıtv [1]. Komponenty muzeme rozdelit do nekolika vrstev. Nejnıze polozena, ktera komunikujes operacnım systemem, se nazyva back-end. Nachazı se zde velke mnozstvı komponent,coz jsou trıdy implementovane v programovacım jazyce C++ a prelozene pro konkretnıoperacnı system. Tyto komponenty pak tvorı jadro cele aplikacnı platformy. Mezi ne patrınaprıklad:

• Komponenty jadra – definice datovych typu, spravce komponent a rozhranı, kompo-nenty umoznujıcı praci se soubory a datovymi toky, rızenı procesu, vlaken, casovacu,vyjimek a udalostı.

• Komponenty pro praci v sıt’ovem prostredı – podpora znamych sıt’ovych protokolu,soketu, rızenı vyrovnavacıch pametı, proxy, spravce cookies, kooperace s webovymisluzbami, sluzby pro stahovanı obsahu, moznost otevıranı ZIP a JAR archıvu.

• Komponenty pro podporu vyvoje aplikacı – spravce oken, vestaveny webovy prohlızec,prıstup k historii a profilum, RDF databaze, nativnı podpora XML, DOM, HTML,XUL, SVG.

• Komponenty souvisejıcı s elektronickou postou – odesılanı, prijımanı a sprava postya diskuznıch skupin, podpora adresare, protokolu LDAP, IMAP, POP3.

• A dalsı komponenty zahrnujıcı naprıklad rızenı a interpretace kodu v jazyceJavaScript, sprava bezpecnosti a napojenı na vyssı vrstvu XPCOM.

Nad tımto blokem lezı system zvany Cross Platform Component Object Model(XPCOM). Ten zprıstupnuje komponenty vyssım vrstvam platformy tak, ze prıstup k nimjiz nenı zavisly na pouzitem operacnım systemu. Protoze XPCOM je prımo dosazitelnepouze pomocı programovacıch jazyku C, C++, existuje zde jeste tenka vrstva XPConnectposkytujıcı rozhranı pro JavaScript.

Pro zcela prenositelny kod je potreba jistym zpusobem adresovat pozadovane kompo-nenty. Proto ma kazda komponenta dıky XPCOM svuj jedinecny identifikator, tzv. Con-tractID. Je ve tvaru @mozilla.org/component-name;1. Ten je mapovan pres objekt URLdo prostoru, ve kterem se jiz nachazı aplikace napsane v jazyce JavaScript. Krome tohotopropojenı existuje jeste druhy typ spojenı vyuzıvajıcı identifikatoru RDF, ktere mapujıURL na urcity zaznam v otevrene RDF databazi.

9

Vrstva oznacena Overlays zodpovıda za rozsırenı funkcnostı aplikacı jako je Firefox neboThunderbird. Takto lze naprıklad pridat novou polozku do menu, informaci do stavovehoradku, vytvorit dalsı panel atd. bez toho, aniz by se musel jakkoli menit kod hostitelskeaplikace. Vsechny informace, jake nove prvky majı byt pridany, jake jsou jejich vlastnostia umıstenı, jsou soucastı distribuce rozsirujıcı aplikace.

Nasledujıcı vrstva je urcena pro vytvarenı novych grafickych komponent. Je zalozena najazyku XML Binding Language, XBL, dıky nehoz lze skladat existujıcı prvky uzivatelskehorozhranı do vetsıch celku a definovat jim pozadovane chovanı. Prıkladem je prvek Tree, vekterem se zobrazuje historie navstıvenych dokumentu v prohlızeci Firefox.

Dalsı cast teto architektury, Templates, rıdı propojenı nekterych prvku uzivatelskehorozhranı a zdroju v RDF databazi. Takto lze bez jedineho radku kodu naplnit daty naprıkladstrom zobrazujıcı historii odkazu. Tato vrstva take umoznuje vıcenasobne pohledy na datarızene spolecnou aktualizacı. Jestlize je ve vıce oknech zobrazen obsah nejake strukturovaneinformace ulozene v RDF databazi, jejı zmenou v jednom okne muze automaticky dojıtk aktualizaci techto dat i v ostatnıch oknech.

Nejvyse je polozena vrstva podporujıcı standardy W3C a zajist’ujıcı interakcis uzivatelem. Na teto urovni jsou naprıklad nacıtany a za ucasti nizsıch vrstevzpravovavany (X)HTML/XUL dokumenty, kaskadove styly, provadeny XSL transformacea dalsı. Data, ktera majı byt prezentovana uzivateli, jsou vykreslovana renderovacımjadrem Gecko, akutalnı verze je 1.8.1 [32].

Obrazek 3.1: Zjednoduseny pohled na architekturu platformy Mozilla

10

Kapitola 4

Tvorba uzivatelskeho rozhranı

K programovanı uzivatelskeho rozhranı je urcen jazyk XML User-Interface Language(XUL). Pomocı textoveho zapisu lze hierarchicky skladat komponenty, ktere vytvorıpozadovanou podobu GUI. Platforma nabızı velke mnozstvı uzivatelskych prvku:

• boxy, panely a mrızky, ktere lze pouzıt pro pozicovanı dalsıch komponent,

• standardnı ovladacı prvky, jako jsou ruzne typy tlacıtek, vyberovych nabıdek, prvkupro vlozenı a zobrazenı textu a obrazku, apod.,

• prvek zobrazujıcı stromovou strukturu v kombinaci s dalsımi sloupci,

• realizace zalozek s prıslusejıcımi panely,

• hlavnı i kontextove nabıdky, nastrojova lista, stavovy radek, bublinova napoveda,

• ovladacı prvky pro realizaci pruvodcu,

• sofistikovane komponenty, ktere dokazı zobrazit obsah webovych stranek a prıpadnejejich obsah vizualne upravovat a

• dalsı pomocne prvky pro pripojenı k datovemu zdroji a podobne.

Obecna struktura zdrojoveho kodu okna aplikace vypada nasledovne:

<?xml version="1.0"?><?xml-stylesheet href="chrome://global/skin/" type="text/css"?><?xml-stylesheet href="chrome://docwatcher/skin/main.css"

type="text/css"?>

<!DOCTYPE window [<!ENTITY % mainDTD SYSTEM "chrome://docwatcher/locale/main.dtd">%mainDTD;

]>

11

<windowxmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"><script type="application/x-javascript" src="main.js"/>

<commandset><command id="cmd_newLink" />

</commandset>

<keyset><key id="key_newLink" command="cmd_newLink" keycode="VK_INSERT" />

</keyset>

<menupopup id="cmenuFolders"><menuitem label="&cmd.newLink;" accesskey="&cmd.newLink.accesskey;"

key="key_newLink" command="cmd_newLink"/></menupopup>

<description flex="1">Content</description>

<script type="application/x-javascript"><![CDATA[]]></script></window>

Soubor s prıponou .xul se sklada ze dvou castı. Nejprve se uvadı deklaracnı cast, vektere se nachazı seznam importovanych stylu a DTD souboru s retezcovymi konstantami.Nasleduje blok definujıcı hierarchicke usporadanı prvku uzivatelskeho rozhranı.

4.1 Obsah XUL

Jak jiz bylo receno, XUL soubor je ve formatu XML, takze krome danych pravidel syntak-tickeho zapisu vyzaduje mimojine i korenovy element. Podporovano je techto pet:

• window – predstavuje standardnı okno aplikace, ktere se nelisı od ostatnıch okendaneho operacnıho systemu.

• prefwindow – specialnı typ okna pouzıvany pro nastavovanı parametru aplikace.Umoznuje prıme napojenı na datovy zdroj.

• dialog – reprezentuje dialogove okno. Automaticky pridava tlacıtka OK a Storno,pricemz chovanı chovanı a vzhled okna jsou upraveny tak, aby odpovıdaly vlastnostemdialogovych oken daneho systemu.

• wizard – typ okna usnadnujıcı tvorbu pruvodcu.

• overlay – specialnı element, ktery uvozuje obsah upravujıcı nekterou cast stavajıcıhouzivatelskeho rozhranı platformy. Dalsı informace jsou uvedeny nıze.

Nezbytnou soucastı korenoveho elementu je take urcenı jmennychprostoru, ktere budou pouzıvany. Vsechny XUL elementy lezı v prostoru

12

http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul. Vetsinou jeXUL dokument tvoren pouze XUL elementy, a proto se identifikator jmenneho prostoruneuvadı. Presto ale existujı situace, kdy je potreba do XUL take vlozit HTML elementy.V takovem prıpade je potreba uvest jmenny prostor, ve kterem se tyto elementy nachazı aurcity identifikator:

xmlns:html="http://www.w3.org/1999/xhtml"

HTML elementy jsou pak vkladany beznym zpusobem, jejich jmeno je navıc uvozenoidentifikatorem prıslusneho jmenneho prostoru. Naprıklad <html:p>.

Elementy, ktere mohou byt umısteny v danem korenovem XUL elementu, lze rozdelitdo dvou skupin.

4.1.1 Urcenı vzhledu

Prvnı skupina je tvorena znackami, ktere utvarejı vlastnı uzivatelske rozhranı, majı nejakouvizualnı podobu. Tyto elementy jsou dobre popsany v [37].

Pri programovanı slozitejsıch aplikacı vsak nezrıdka nastavajı situace, kdy je standardnıfunkcnost prvku nedostatecna a je potreba ji modifikovat. V takovem prıpade je nezbytnepochopit jejich implementaci. Vsechny XUL prvky jsou definovany pomocı jazyka XMLBindings Language (XBL), ktery umoznuje skladat jiz existujıcı elementy uzivatelskehorozhranı do vetsıch celku, definovat jejich chovanı, rozhranı pro komunikaci s vnejsımsvetem a vzhled. Protoze zname nazev elementu, jehoz implementaci potrebujeme prozk-oumat, vychazıme z CSS souboru zıskaneho z adresy chrome://global/content/xul.css, jehozskutecne umıstenı se nachazı v firefox dir/chrome/toolkit.jar – content/global/xul.css, kdefirefox dir je adresar s nainstalovanou aplikacı Firefox. V xul.css nalezneme pozadovanynazev elementu a jemu prıslusejıcı hodnotu vlastnosti -moz-binding, ktera obsahuje URLs XBL definicı pozadovane XUL znacky. Pokud potrebujeme jeste podrobnejsı informace,ktere lze zıskat pouze ze zdrojovych kodu platformy, je v [38] k prıslusne znacce uvedennazev odpovıdajıcı trıdy. S temito znalostmi lze ve vlastnı aplikaci nasledne vytvaret zcelanove prvky na zaklade jiz existujıcıch a nebo pouze upravovat chovanı a vzhled stavajıcıch.

4.1.2 Podpora pro definici chovanı

Do druhe skupiny znacek, ktere lze nalezt v XUL dokumentu, pak patrı ty, jenznedefinujı vizualnı podobu, avsak nejakym zpusobem urcujı chovanı, jenz se prımo tykauzivatelskeho rozhranı. Byva totiz zvykem, ze veskery kod definujıcı chovanı aplikace nenımıchan s vizualnım obsahem, mame snahu tyto dve oblasti od sebe co nejvıce oddelit.Vyjimkou muze byt kratky kod, ktery se naprıklad stara o spravne pozicovanı prvku prizmene velikosti okna. Tento kod je vetsinou zapisovan do prvku <script>...</script>umısteneho na konci XUL.

V aplikacıch lze obvykle nektere funkce vyvolat z vıce mıst, naprıklad z hlavnı nebo kon-textove nabıdky, nastrojove listy nebo pomocı klavesove zkratky. Mısta, kde vsude lze zvolitdanou funkci, by ale mela byt propojena pouze na urovni uzivatelskeho rozhranı, idealneprımo v XUL. Aplikacnıho programatora jiz nezajıma, jak lze aktivovat danou funkci,pozaduje pouze jediny bod, ktery mu umoznı pripojit se a reagovat na tento pozadavek,centralne zakazat funkci nebo naprıklad upravit popisek. Stejne tak definice klavesovych

13

zkratek by mela byt umıstena pouze v XUL nebo souborech s retezcovymi konstantami (vizdale).

Pro tyto ucely XUL nabızı nekolik elementu:

• command – definuje vychozı mısto spoustenı urcite funkce. Prvky umoznujıcı vyberteto funkce (naprıklad menuitem, button) pak musı mıt hodnotu atributu commandrovnou hodnote atributu id prvku command. Jakmile se vybere libovolnym zpusobemdana funkce, je vyvolana udalost oncommand tohoto centralnıho mısta. Tato udalostje prave mıstem propojenı uzivatelske rozhranı – aplikacnı uroven.

• broadcaster – umoznuje urcit jedine mısto pro nastavovanı atributu. Jestlizepotrebujeme naprıklad nastavovat hodnotu nejakeho atributu pro vıce znaceknajednou, nenı potreba nastavovat je oddelene, muzeme je propojit stejnymzpusobem jako u elementu command. Mısto atributu command je vsak pouzıvanatribut s nazvem observes. Jakmile je urcitemu elementu broadcaster prirazenanebo zmenena hodnota libovolneho atributu mimo id, jsou okamzite nastavenypatricnym zpusobem i atributy pripojenych elementu. Tuto vlastnost ma i predchozıznacka command, u ktere se bezne pouzıvajı atribut pro zakazovanı dane funkce(disabled) a jejı popisek (label).

• key – definuje klavesovou zkratku. Zpusob napojenı na danou funkci se provadıprostrednictvım jiz uvedeneho atributu command. Bohuzel zde existuje jedenz problemu, ktery nenı v zadnych zdrojıch jasne uveden. Pokud je jisty <key>propojen s <command>, nemuze byt registrace udalosti oncommand u elementucommand provedena pomocı metody addEventListener(), je nutne vyuzıtsetAttribute(). V opacnem prıpade klavesova zkratka nenı funcnı.

Aby program mohl zachytavat reakce uzivatele, jakou muze byt treba poklepanı napolozku ve strome, je potreba priradit k pozadovane udalosti, kterou platforma generuje,kod zpracovavajıcı pozadavek. Obecne je mozne tento kod vepsat prımo do atributu,ktery odpovıda nazvu udalosti. Tento zpusob vsak vetsinou vede k neprehlednemu aneudrzovatelnemu kodu. Zrejme nejlepsı resenı se sklada ze dvou kroku:

1. Hodnotu atributu onload korenoveho elementu, s vyjimkou overlay, nastavit nanazev inicializacnı funkce, ktera se nachazı v prıslusnem souboru s JavaScript kodem.V prıpade, ze se v teto funkci alokujı prostredky, ktere je nutne pred ukoncenım praceuvolnit, provadı se tato cinnost ve funkci, jejız nazev se staticky definuje pomocıatributu onunload.

2. V inicializacnı funkci pripojit k udalostem jednotlivych prvku obluzne funkce po-mocı volanı metody nsIDOMEventTarget::addEventListener() (vyjimku tvorı vyseuvedeny problem s elementem key).

S prvky uzivatelskeho rozhranı se pracuje vzdy az v okamziku, kdy je vytvoren DOMdaneho XUL dokumentu, nenı tedy nutne zabyvat se umıstenım prvku script v XULdokumentu. Pokud by totiz byl zpracovavan nejaky kod na zacatku dokumentu, kteryby pracoval s prvkem uzivatelskeho rozhranı umısteneho nıze ve vypisu zdrojoveho kodu,prvek by nikdy nebyl nalezen, protoze v danem okamziku interpretace tohoto kodu jesteneexistuje.

Pouzitı metody nsIDOMEventTarget::addEventListener() je vyhodne ze dvouduvodu. Jednak lze urcit fazi zachycenı udalosti a take muzeme k jedne udalosti priradit

14

vıce obsluznych funkcı. Ty lze dynamicky za behu pridavat i odebırat. Prımy zapis kodudo atributu s nazvem udalosti toto neumoznuje.

4.2 Kaskadove styly

Kaskadove styly jsou umısteny v souborech s prıponou .css. Urcujı vzhled a umıstenıjednotlivych elementu i celych hierarchiı definovanych v XUL dokumentech. Protoze jevykreslovacı jadro pro XUL a HTML stejne, lze pro upravu vzhledu pouzıvat bezne CSSvlastnosti a kazdemu prvku priradit atribut class. Presto vsak byly pro XUL pridany novevlasnosti, jejich seznam s vysvetlenım je uveden v [23].

Zde uved’me dve vlasnosti, ktere majı specialnı vyznam. Prvnı vlastnost je-moz-binding, tato jiz byla uvedena vyse v souvislosti s XUL elementy. Spojuje nazevznacky uvadene ve zdrojovem kodu XUL s XBL definicı.

Druha vlastnost se jiz tyka vzhledu, jejı nazev je -moz-appearance. Jestlize prvek tutohodnotu nema nastavenou, hodnota je rovna none, nebo je platforma provozovana na jinemoperacnım systemu nez je Windows XP a vyssı a Mac OS X, pak se element chova a vypadapresne takovym zpusobem, jak jej urcujı XBL a CSS. Jestlize je ale tato vlastnost nastavenana neprazdnou platnou hodnotu, naprıklad button, chovanı a vzhled prvku je rızeno in-terne dle nastavene hodnoty. Duvodem je nova vlastnost vykreslovacıho jadra Gecko, kterev operacnıch systemech Windows XP a Mac OS X podporuje nativnı vzhled a chovanıgrafickych komponent. Interne se vytvorı prvek uzivatelskeho rozhranı operacnıho systemua ten je vlozen na pozadovane mısto v dokumentu, cımz se ignoruje nastavenı vzhleduuvedeneho v CSS. Seznam povolenych hodnot se nachazı v souboru nsCSSKeywordList.h.Protoze vetsina XUL prvku ma tyto vlastnosti implicitne nastaveny, zmena vzhledu castıprvku nenı mozna. Jedinou moznostı pak byva vlastnost -moz-appearance vypnout a jena vyvojari, aby se vizualnı podoba upravovaneho XUL prvku co nejvıce blızila nativnımuvzhledu prvku daneho operacnıho systemu.

Krome novych vlasnostı pridava Mozilla do CSS jeste jeden specialnı zapis selektoru,ktery se uplatnuje pri upravovanı vzhledu radku, sloupcu a obsahu bunek prvku tree.Klasickym zpusobem lze menit pouze vizualnı podobu okraju stromu a zahlavı sloupcu.Duvodem je odlisny zpusob reprezentace generovaneho obsahu stromu, jenz nedovolujepouzitı atributu class. Ten nahrazuje novy atribut s nazvem properties. Odpovıdajıcınastavenı v CSS pak vypada nasledovne:

selektor_stromu treechildren::nazev_vlastnosti(hodnoty) {CSS definice

}

selektor stromu je nepovinny selektor vybırajıcı pozadovany strom v DOM,treechildren oznacuje regularnı nazev elementu umısteneho ve stromu, ktery je vzdyprıtomen a ohranicuje datovou oblast, nazev vlastnosti je povinny a udava, kteravnitrnı oblast stromu bude upravovana a seznam hodnot uvedenych v zavorce vybıraobsah, na nehoz bude vzhled aplikovan. Tyto hodnoty se vyhledavajı v hodnotachatributu properties. Krome hodnot, ktere definuje uzivatel, jsou prıtomny i platformoudefinovane, jako je naprıklad sudy/lichy radek, serazeny sloupec a podobne. Kompletnıseznam je uveden v [24].

15

Pro pripojenı kaskadovych stylu k XUL nebo XBL je pouzıvana notace platna pro XML:

<?xml-stylesheet href="chrome://docwatcher/skin/main.css"type="text/css"?>

Vyznam URL, ktery je zde uveden, vysvetluje kapitola 8. Zde je nutnevsimnout si, ze skutecna fyzicka cesta, ktera by v tomto prıpade bylacontent/skin/classic/docwatcher/main.css neodpovıda vyse uvedene. Duvodem je fakt, zeplatforma umoznuje vytvaret vıce typu vzhledu aplikace a prepınat se mezi nimi. Zdeclassic oznacuje nazev vychozıho vzhledu, ktery bude aplikovan, pokud nenı nalezenadresar s nazvem aktualne zvoleneho skinu pro celou platformu.

Proto, aby kazdy XUL dokument vypadal stejnym zpusobem, je potreba pripojitsystemovou slozku se styly chrome://global/skin/, z nız platforma automaticky vybırapotrebne kaskadove styly. Bez techto souboru by vhled aplikace pripomınal obycejnouneupravenou HTML stranku. Pote jiz mohou byt pripojeny dalsı styly aplikace.

4.3 Definice externıch retezcu

Jeden ze standardnıch pozadavku na modernı aplikace je podpora vıce jazykovych verzıa jejich snadna sprava. Tohoto cıle by bylo problematicke dosahnout, pokud by retezcebyly v prıslusnych mıstech prımo vepsany, byly by tedy soucastı zdrojoveho kodu. Z tohotoduvodu jsou pro ucely lokalizace urceny dva typy souboru.

4.3.1 DTD entity

Prvnı typ externe deklaruje textove entity, ktere mohou byt pripojeny k defici typu doku-mentu (DTD), soubory majı prıponu .dtd. Prıklad jednoho radku z tohoto souboru:

<!ENTITY cmd.newLink "Nový odkaz">

Za klıcovym slovem ENTITY je uveden nazev entity, pomocı nehoz se v XUL dokumentuodkazujeme na skutecny obsah. Notace zapisu pro vlozenı obsahu textove entity pri inter-pretaci dokumentu je &nazev entity;. Zpusob pripojenı souboru DTD s retezci je ukazanv prıkladu na zacatku teto kapitoly.

Vlastnı textovy obsah, ktery bude vlozen do objektoveho modelu dokumentu (DOM), jeuveden v uvozovkach za nazvem entity. Jestlize vyuzıvame znaky narodnı abecedy, tzn. je-jich ASCII hodnota je vyssı nez 127, musıme si uvedomit, ze se take uplatnuje vliv kodovanısouboru. Pokud naprıklad ve Windows ulozıme soubor, ktery bude obsahovat pısmeno “R”,bude implicitne ulozen v kodovanı CP1250 a toto pısmeno bude mıt urcitou hodnotu. Pokudstejny soubor vytvorıme a ulozıme v Linuxu, bude pouzito pravdepodobne jine kodovanı(ISO8859-2) a dany znak bude mıt odlisnou hodnotu. Pri nactenı renderovacım jadremMozilly pak dochazı k problemu – je-li pouzit vychozı typ kodovanı ulozeny v nastavenıcha pokud se neshoduje s kodovanım, ve kterem byl soubor ulozen, budou znaky s diakri-tikou zobrazeny chybne, nebo XML parser nebude schopen vubec dany element nacıst ainterpretace koncı chybou.

Nejspolehlivejsım resenım je nahrazovat vsechny znaky s ASCII hodnotou vetsı nez127 jejich hodnotami dle 16bitoveho Unicode. Tyto hodnoty se zapisujı v hexadecimalnım

16

tvaru, prıklad je uveden vyse, kde je nahrazovan znak “y”. Pro texty v ceskem jazyce platıtabulky oznacene Latin-1 a Latin Extended A nachazejıcı se v [28].

4.3.2 Textove konstanty

Druhy zpusob uchovavanı retezcovych konstant mimo kod aplikace spocıva v pouzitısouboru s prıponou .properties. K extrakci pozadovaneho textu z tohoto zdroje je vsaknutne pouzıt jeden z jazyku popisujıcıch chovanı aplikace, viz. kapitola 5.1. Radek vypadanaprıklad takto:

confirmDelete=Opravdu chcete vybran\u00E9 odkazy (celkem %S) smazat?

Kazdy radek obsahuje identifikator retezce a prıslusejıcı text. Stejne jako u externıchtextovych entit, i zde je nejlepsı cesta zapisu znaku narodnı abecedy pres odpovıdajıcı16bitovou Unicode hodnotu. Dale zde fungujı escape sekvence zname z jazyka C, coz jetake jediny zpusob, jak vlozit do textu znak noveho radku.

A konecne, retezce mohou byt parametrizovane, tj. na mısta, ktera jsou oznacenapomocı znaku procento nasledovaneho retezcem reprezentujıcım pozadovany format, sevlozı vstupnı hodnoty. Podporovane formaty zrejme odpovıdajı formatum funkce printfjazyka C, i kdyz tato skutecnost nenı v zadne oficialnı dokumentaci explicitneuvedena. Na strankach [37] je k elementu stringbundle uveden pro vlozenı textovehoretezce pomocı jazyka JavaScript parametr %s, coz je ovsem chyba. Metoda trıdynsStringBundle urcena pro analyzu retezcovych konstant neprımo vola statickou metodunsTextFormatter::dosprintf, ve ktere lze najıt podporovane formaty. Z tohoto kodu jepatrne, ze %s je pouze pro 8bitove ASCII retezce, zatımco %S je urceno pro 16bitoveUnicode retezce. Protoze JavaScript pracuje pouze s 16bitovymi znaky, spravnyidentifikator formatu je %S, %s zpusobı chybny vystup.

4.3.3 Volba aktivnıho jazyka

Jazyk, ve kterem jsou retezce psany, nenı explicitne uveden v souborech, je vsak dan jmenemadresare, ve kterem se tyto soubory nachazejı. Nazev je ve tvaru ln nebo ln-CT, kde ln je kodjazyka malymi pısmeny dle ISO 639.2 a CT je kod zeme velkymi pısmeny dle ISO 3166 [8].Nadrazeny adresar techto jazykovych adresaru se pak jmenuje locale. Pro Ceskou republikuje kod cs-CZ.

Je dulezite vsimnout si, ze ve zdrojovem kodu uvedenem na zacatku teto kapitoly nenıv ceste chrome://docwatcher/locale/main.dtd konkretnı nazev jazykove varianty. Obecnevsechny soubory, ktere se nachazejı v podhierarchii adresare locale, nemajı uvedeny kodjazyka. Mozilla sama tuto cestu upravuje a doplnuje na zaklade nejlepsı shody s aktualnımnastavenım operacnıho systemu. Jestlize nalezne adresar s jazykovym kodem ekvivalentnımkodu, ktery poskytuje operacnı system, jsou pouzity retezce z tohoto adresare. V prıpadeneshody je vyhledan adresar en-US. Jestlize ani ten neexistuje, je vybran prvnı zaregi-strovany adresar v prubehu procesu instalace rozsırenı, viz. kapitola ??.

17

Kapitola 5

Programovanı chovanı

Pred vlastnım obsahem teto kapitoly je vhodne zmınit dostupne zdroje, odkud lze zıskavatmnoho informacı o API, funkcnıch postupech i chybach platformy. Pri vyvoji musıme brattotiz ohled na to, ze se jedna o otevrenou aktivne se rozvıjejıcı aplikacnı platformu, najejımz vytvarenı se podılı hodne programatoru z celeho sveta a ne kazdy dodrzuje vsechnapravidla zapisu zdrojovych kodu, apod. Z tohoto duvodu jsou pak nektere casti dokumen-tace dostupne v [37] neuplne, v nekterych mıstech popis zcela chybı. V takovem prıpade lzezkoumat prımo zdrojove kody, ktere jsou prıstupne na adrese http://lxr.mozilla.org, jezde i funkce vyhledavanı. Bohuzel zde vsak nejsou zahrnuty zdrojove kody aplikace Firefox2.0, a proto je potreba stahnout si zdrojove kody. Blizsı informace jsou uvedeny v [17].Jen upozornuji, ze rozbaleny archiv zabıra na disku pres 250MB, obsahuje vıce nez 40000souboru a nalezenı potrebne informace muze byt casove dosti narocne.

Dalsım zdrojem informacı je samotna instalace zvoleneho produktu Mozilla, hlavnepak archivy v adresari chrome. Ty jsou potreba predevsım pro nalezenı idenfikatoru zaucelem rozsirovanı stavajıcıch aplikacı pomocı overlays. Jestlize vytvarıme aplikaci, jejıznejaka funkce je podobna cinnosti jiz existujıcıho rozsırenı nebo casti produktu Mozilla,je obcas nutne pristoupit k reverznımu inzenyrstvı a zjistit, jakym zpusobem fungujı. Jetotiz pravdepodobne, ze se vyvojari potykali se stejnymi problemy. Dostupna rozsırenılze zıskat naprıklad z adresy https://addons.mozilla.org. Zbyva upozornit na adresuhttps://bugzilla.mozilla.org, na nız je dostupna Bugzilla, coz je databaze s nalezenymichybami platformy Mozilla – ne vzdy je totiz chyba v kodu vyvojare.

5.1 Programovacı jazyky

Pro programovanı aplikacı jsou na teto platforme primarne dostupne dva jazyky. Prvnımje C++, kterym lze implementovat pozadovane chovanı na urovni komponent. Nevyhodouje, ze tento kod bude po prekladu zavisly na HW architekture a prıpadne i na operacnımsystemu. Hodı se tam, kde potrebujeme zrychlit vypocet, skryt nejake implementacnı detailynebo vyuzıt prımeho napojenı na kokretnı operacnı system.

Druhym jazykem je JavaScript, ktery je nejcasteji vyuzıvan. Jeho pouzitı je vpodstatenezbytne i v predchozım prıpade, kde je potreba vytvorene komponente predat rızenı. Vlast-nosti jazyka shrnuje nasledujıcıch nekolik bodu:

• Vychazı ze standardu ECMAScript (ECMA-262 Edition 3) a pridava nekterarozsırenı. Aktualnı verze je 1.7 [18].

18

http://lxr.mozilla.org

https://addons.mozilla.org

https://bugzilla.mozilla.org

• Je to skriptovacı jazyk, coz znamena, ze zdrojovy kod se syntaxı podobnou syntaxijazyka C, je pri behu programu cten a interpretovan. Tento fakt ma tri nevyhody:Je snızena rychlost provadenı kodu, coz je znatelne pri slozitejsıch vypoctech. Ladenıje obtıznejsı dıky toho, ze chyby jsou vetsinou odhaleny az v okamziku, kdy majıbyt zpracovany. Poslednı nevyhoda se tyka otevrene podoby kodu – ten je snadnocitelny, pokud nenı z nejakeho duvodu mozne pouzıt nastroj pro zatemnenı kodu,tzv. obfuscator.

• Typy promennych se explicitne neuvadejı, jsou zjist’ovany za behu. Objekty sevytvarejı pomocı operatoru new, destruktory zde neexistujı. O uvolnovanı pameti seautomaticky stara Garbage collector.

• Podporovano je objektove orientovane programovanı, u trıd lze rozlisovat privanıa verejne atributy a metody. Lze vyuzıvat polymorfismu (volanı jedne konkretnımetody objektu ruznych trıd) a jednoducha dedıcnost (odvozovanı trıdy od jine trıdya prebıranı jejich verejnych atributu a metod). Objekt a asociativnı pole si vpodstateodpovıdajı.

• JavaScript umoznuje i funkcionalnı programovanı.

• Je mozne take vyuzıvat iteratory, getter/setter metody zname napr. z jazyka C#,funkce muze vracet vıce hodnot najednou a dalsı vlastnosti, ktere se stale rozvıjı.

V poslednı dobe se take vyvıjı dva nove projekty, ktere se snazı propojit jadro platformys jazyky Python a Java. Nazvy prıslusnych projektu jsou PyXPCOM1 a JavaXPCOM2.

5.1.1 Objektove programovanı v jazyce JavaScript

Jak jiz bylo uvedeno vyse, JavaScript podporuje objektove orientovane programovanı,cımz lze dosahnout lepsı struktury a udrzovatelnosti kodu. Prıklad definice trıdy vypadanasledovne:

function classA(parameter){const _self = this;var private_attribute = parameter;var private_method = function() {_self.public_attr1 = null;

}this.public_attr1 = null;this.public_method1 = function() {}

}

1http://developer.mozilla.org/en/docs/PyXPCOM2http://developer.mozilla.org/en/docs/JavaXPCOM

19

http://developer.mozilla.org/en/docs/PyXPCOM

http://developer.mozilla.org/en/docs/JavaXPCOM

classA.prototype.__defineGetter__("public_attr2", function(){ return this.public_attribute; });

classA.prototype.__defineSetter__("public_attr2", function(val){ this.public_attribute = val; });

classA.prototype = new function() {var private_static_attr = null,this.public_attr2 = null;this.public_method2 = function() {}

}

Funkce i trıdy sdılejı v jazyku JavaScript jedine klıcove slovo function. V prıkladu jedefinovana trıda classA, telo funkce predstavuje jejı konstuktor, jehoz parametrem mo-hou byt libovolne promenne. Vlastnosti, ktere jsou dostupne vne trıdy, majı pred nazvemuvedeno klıcove slovo this oddelene teckou. V tomto prıpade se jedna o vsechny polozkys prefixem public. this funguje stejnym zpusobem jako v jinych objektovych jazycıch,oznacuje tedy referenci na aktualnı objekt. Dale se zde nachazı atribut a metoda s prefixemprivate. Ty jsou prıstupne pouze v ramci tela konstruktoru a protoze jsou dostupne pocelou dobu existence objektu, lze je povazovat za privatnı. V Mozille vsak existuje chyba,ktera zpusobuje, ze v tele privatnıch metod nenı pres klıcove slovo this dostupna referencena aktualnı objekt. Reference je nastavena na globalnı objekt, ktery je vetsinou window.Zpusob resenı tohoto problemu spocıva v zavedenı konstantnı promenne, ktera udrzuje refe-renci na aktualnı objekt a v tele privatnıch metod se pak lze odkazat pomocı teto promennena obsah objektu.

V kodu se nachazı staticka vlastnost trıdy nazvana prototype. Jedna se o systememvytvoreny objekt dostupny v kazde funkci, ktery lze pouzıt pro pridavanı/odebıranı/upravuverejnych atributu a metod. Pro odebıranı vlastnostı slouzı specialnı operator delete[6]. Dıky teto vlastnosti muzeme rozsirovat funkcnost existujıcıch trıd, ale take vsech jizvytvorenych instancı dane trıdy. Tak lze naprıklad pridat metody do systemoveho objektuDate.

Metody defineGetter () a defineSetter () jsou dostupne pouze v ramci ob-jektu prototype a umoznujı vytvaret gettery a settery. V prıkladu je uvedena vlastnostpublic attr2, ktery se syntaxı a pouzitım tvarı jako atribut, avsak pri ctenı jeho hodnotyje volana metoda getteru a pri zapisu nove hodnoty je volana metoda setteru. Vynechanımdefinice setteru muzeme zıskat atribut urceny pouze pro ctenı, ktery je dostupny vne ob-jektu.

Protoze ma kazda trıda jediny staticky objekt prototype, je vsemi instancemi tetotrıdy sdılena. Atribut, ktery je zde definovan a nenı uvozen klıcovym slovem this, je pakinterne dostupny vsem temto instancım. Predstavuje tedy privatnı staticky atribut. Nejvetsıproblem uvedeneho zapisu je fakt, ze privatnı atributy definovane v konstruktoru a privatnıstaticke atributy obsazene v objektu prototype nejsou nikdy viditelne z jedine metody.

V prıkladu je dale znazornen zpusob vytvarenı instance anonymnı trıdy. Znamena to,ze zde existuje jediny objekt definovane trıdy, ktera vsak nenı dostupna a nelze vytvorit jejıdalsı instanci. Nasledujıcı kody uvadejı dva zpusoby vytvorenı diskutovanych typu instancı:

20

Zde je jeste potreba uvest, jakym zpusobem se interne provadı prirazovanı novych hod-not vlastnostem. Tato problematika je detailne i s prıklady rozebrana v [27]. Jestlize jenaprıklad definovana hodnota verejneho atributu v objektu prototype rodicovske trıdy,pak pri jejım ctenı v potomkovi trıdy je vracena hodnota, ktera ulozena v rodici. Pri zapisunove hodnoty tohoto atributu ale jiz dochazı k vytvorenı noveho atributu v pamet’ovemprostoru potomka. V tomto okamziku tedy existujı dve hodnoty, pricemz ta v rodici jeaktualne neviditelna, protoze pri vyhledavanı je nalezena a vracena hodnota umıstena v po-tomkovi. Jestlize byl tento atribut definovan v prototype, lze pro zıskanı hodnoty atributuinstance prımeho rodice provest nasledujıcı kod:

var valueOfParent = classAInstance.__proto__.__proto__.public_attr2;

Je-li atribut definovan v tele konstruktoru rodicovske trıdy, nelze tuto hodnotujakymkoli zpusobem zıskat. Stejne tvrzenı pak platı v prıpade volanı metod.

V komentari je uveden jeste jeden zpusob tvorby vazeb dedicnosti. Ten nenıdoporucovan, protoze v okamziku nacıtanı scriptu do XUL nebo HTML dokumentudochazı k vytvarenı instance rodicovske trıdy, ktera vsak muze pozadovat parametrykonstruktoru a ty v tomto okamziku jeste nemusı byt dostupne. Druhy problem souvisı sezdrzenım zavadenı naslednych castı dokumentu zpusobeneho vytvarenım instance. Pripouzitı tohoto zpusobu je vhodne nastavit zpet hodnotu atributu constructor, ktery jeautomaticky vytvaren platformou, na referenci na funkci, ktera vzdy predstavujekonstruktor dane trıdy.

Druhym nezbytnym krokem je zavolanı systemove metody apply(), jenz je dostupnav kazde funkci. Prvnım parametrem je vzdy reference na objekt, v jehoz kontextu ma bytspustena, a nasleduje pole s parametry predavanych rodicovske trıde. call() se chovastejne, avsak mısto pole parametru se uvadejı jednotlive parametry zvlast’. Tyto metodyspustı kontruktor dane trıdy, avsak reference udane klıcovym slovem this jsou nahrazenyreferencı, ktera je predavana jako prvnı parametr. To znamena, ze vsechny verejne atributya metody, ktere se nachazejı v konstruktoru rodice budou zkopırovany do pamet’ovehoprostoru potomka. Pokud by k volanı apply() nedoslo, potomci rodicovske trıdy by nemelipolozky z konstruktoru k dispozici, protoze tyto objekt prototype nezahrnuje. Z tohotofaktu take vyplyva, ze vyvojar ma dve moznosti navrhovanı trıd a je na nem, aby zvo-lil vyhovujıcı. Pokud bude vyuzıvat lokalnı promenne a funkce v tele konstruktoru, sekterymi bude pracovat jako s privatnımi polozkami trıdy, muze sice lepe ukryvat informacepred okolnım svetem, avsak interpret jazyka vytvorı pro kazdou novou instanci trıdy znovavsechny metody nachazejıcı se v tele konstruktoru, takze se zvysujı naroky na pamet’ arychlost vytvarenı objektu klesa. Druha moznost je opacna – do tela konstruktoru umıstitpouze atributy a vsechny metody definovat do objektu prototype. Tım sice prıjdemeo moznost ukryvanı polozek, avsak odstranıme drıve uvedene nevyhody. V tomto prıpademuze pomoci zavedenı vlastnıch pravidel pro oznacovanı polozek s ruznymi urovnemiprıstupu (private, protected, public) a ty pak dodrzovat.

Pro prıstup k polozkam trıdy se pouzıva standardnı teckova notace znama napr. z jazykaC. Dıky to, ze jazyk JavaScript chape objekty jako asociativnı pole, ve kterem je klıc tvorennazvem polozky, muzeme pro prıstup pouzıt i operator pole. Jestlize do tohoto pole zapısemehodnotu na mısto dane klıcem, jenz neexistuje, vytvorı se nova vlastnost prıslusne instancetrıdy. Nasledujıcı dva radky jsou tedy identicke:

22

new classA().public_method()new classA()["public_method2"]()

Nova instance trıdy vznika operatorem new. Soucastı interpretu jazyka JavaScript jegarbage collector, ktery se automaticky stara o uvolnovanı pameti, pokud pocet referencına dany objekt klesne na nulu. Neexistujı zde destruktory, operator delete ale muze bytpouzit pro odstranenı elementu z pole, vlastnosti z objektu nebo dokonce celeho objektu[6]. Dalsı operatory pro ucely objektove orientovaneho programovanı jsou tyto: in muze bytpouzit pro testovanı existence urcite vlastnosti v instanci trıdy, instanceof udava, zda jeobjekt na leve strane operatoru instancı trıdy uvedene na strane prave a operator typeofvracı pro trıdu retezec "function" a pro instanci trıdy "object".

5.2 XPCOM

Obecne programovanı chovanı aplikace probıha stejne, jako u (X)HTML stranek. Objektywindow, document a dalsı bezne jsou dostupne standardnı cestou, i pres prıslusna rozhranı.S vyjimkou prvku uzivatelskeho rozhranı, ktere jsou ve specialnım rezimu budovany prımoz datoveho RDF zdroje, je mozne se vsemi prvky v okne manipulovat prostrednictvımDOM operacı a na reakce uzivatele jsou pouzıvany udalosti. Uvedene moznosti jsou vsakpro implementaci pokrocilych aplikacı nedostatecne. V beznem JavaScriptu nelze pracovatse soubory na disku, spoustet dalsı aplikace, pristupovat k oknum prohlızece, vytvaretlibovolna sıt’ova spojenı a podobne.

Platforma Mozilla proto poskytuje mechanismy, ktere umoznujı XUL aplikacımpripojit se k pozadovanym komponentam a volanım jejich sluzeb provadet potrebneoperace. Zıskanı reference na pozadovany objekt je provedeno jednım z nasledujıcıchprıkladu volanı, jehoz vyber je zavisly na typu komponenty:

Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties)

nebo

Components.classes["@mozilla.org/rdf/container;1"].createInstance(Components.interfaces.nsIRDFContainer)

Prvnı prıpad pouze zıska referenci na instanci trıdy, ktera je singleton. V celempamet’ovem prostoru platformy je tedy pouze jedina instance teto sluzby. Druhy prıpad jizvytvarı novou instanci pozadovane trıdy. V hranatych zavorkach se uvadı ContractIDpozadovane komponenty, coz je jedinecny retezec, kterym se kazda komponenta platformyidentifikuje. Parametrem metod getService() a createInstance() je pak rozhranı,ktere chceme zıskat. Volanı operacı, ktere zıskana komponenta nabızı, se jiz provadıklasickym zpusobem volanı metody. Poznamenejme, ze ne vsechny metody lze volat,nektere jsou v dokumentaci [37] oznaceny [noscript] a tyto lze spoustet pouze z jazykaC++ na urovni komponent.

Pred uvedenım nasledujıcıch castı je potreba take upozornit na dokument [29], s jehozobsahem je vhodne seznamit se, protoze obsahuje informace tykajıcı se spravnych postupupouzıvanı XPCOM komponent tak, aby byly eliminovany uniky pameti.

23

5.2.1 Mozne problemy

Pri praci s komponentami se muzeme setkat s nekolika problemy. Prvnı vznika u metod,ktere majı u nejakeho parametru uveden vyraz out a jeho typ je zakladnı, neobjektovy (viz[12], seznam Built-in Types). Znamena to, ze dana promenna vyzaduje volanı odkazem, tj.v tele metody bude nastavena na novou hodnotu. Resenım je predanı objektu, jehoz atributvalue bude po vykonanı metody obsahovat navratovou hodnotu.

Druhy problem nastava u parametru nekterych metod, ktere vyzadujı objekts definovanym rozhranım. Jestlize bychom naprıklad chteli pouzıt metodu Serialize()komponenty s rozhranım nsIRDFXMLSource, musıme jı predat objekt s rozhranımnsIOutputStream. V tomto prıpade je na vyvojari, aby objekt vytvoril a implementovalpozadovane rozhranı, nelze jej totiz zıskat pomocı volanı getInstance():

var serializer = Components.classes["@mozilla.org/rdf/xml-serializer;1"].createInstance(Components.interfaces.nsIRDFXMLSerializer);

serializer.init(ds);var outputStream = {data: "",close: function() {},flush: function() {},write: function (buffer,count) {

this.data += buffer;return count;

},writeFrom : function (stream,count) {},isNonBlocking: false

};serializer.QueryInterface(Components.interfaces.nsIRDFXMLSource)

.Serialize(outputStream);

Protoze jsou rozhranı usporadana hierarchicky, tj. podporujı pouze jednoduchoudedicnost, majı vsechny jedineho predka nsISupports. Toto rozhranı implementuje trimetody, z toho dve jsou dostupne pouze v jadre pod vrstvou XPCOM a slouzı prozvysovanı/snizovanı pocıtadla referencı na dany objekt. Poslednı metodaQueryInterface() je jiz viditelna a umoznuje zıskat urcite rozhranı komponenty, coz bymohlo byt castecne prirovnano k pretypovanı objektu. V predchozım prıkladu je volanımcreateInstance() vytvorena komponenta pro serializaci a vraceno jedno z rozhranı,ktere implementuje. Jestlize je nasledne potreba zavolat metodu jineho rozhranı stejnekomponenty, musı byt pred vlastnım volanım toto rozhranı obdrzeno prostrednictvımmetody QueryInterface().

Jestlize potrebujeme nejakou hodnotu nebo objekt predat jine casti kodu pomocıXPCOM nebo si je nekam ulozit a pozdeji si vyzvednout, zjistıme, ze potrebna metodarozhranı ma parametr typu nsISupports. V prıpade, ze se jedna o hodnotu, nelze jiprımo predat, ale musı byt zabalena do objektu. Zde jsou dve moznosti – bud’ vytvorımebezny objekt v JavaScriptu a zvoleny atribut nastavıme na pozadovanou hodnotu,nebo vytvorıme instanci komponenty odpovıdajıcıho typu s prefixem [email protected]/supports- (viz rozhranı nsISupportsPrimitive). Druha moznost jepomalejsı, protoze dochazı ke komunikaci s XPCOM. V tomto okamziku uz by bylo

24

mozne objekt predat, protoze XPConnect automaticky prevede JavaScript objekt nansISupports. Jakmile zıskame objekt zpet, vratı se jako nsISupports. Jestlize jsmepredtım vytvareli komponentu s rozhranım nsISupportsPrimitive, zjistıme dle atribututype, jaky datovy typ tato komponenta predstavuje, a dle zıskane hodnoty vyzadameprıslusne rozhranı. Problem ovsem nastava, pokud jsme predavali JavaScript objekt. Zdeneexistuje cesta, jak “pretypovat” zıskany objekt na puvodnı a tım se dostat k ulozenymhodnotam. Proto musı do objektu pridan atribut wrappedJSObject, ktery obsahujereferenci na tento objekt. Pote, co je objekt vracen z XPCOM, lze k puvodnım datumpristupovat prostrednictvım vlastnosti wrappedJSObject. Implementacnı detaily jsouuvedeny ve zdrojovych kodech platformy v souboru nsIXPConnect.idl a dalsı informacejsou v [15, 35].

5.2.2 Vytvarenı komponent

Vytvarenı novych komponent muze je vyhodne zejmena tehdy, pokud aplikace potrebujevlastnı sluzby, tj. singletony v pamet’ovem prostoru platformy, objekty, ktere budou pracovats temito sluzbami nebo chceme rozsırit stavajıcı komponenty. Programovanı komponentv jazyce C++ detailne popisuje [2]. Zde se opet zabyvame pouze komponentami v jazyceJavaScript.

Dle [13] byva kod komponenty obvykle stejny a lisı se jen v hodnotach konstant a definicitrıdy, ktera implementuje pozadovane chovanı:

const Cc = Components.classes;const Ci = Components.interfaces;const Cr = Components.results;

const CLASS_ID = Components.ID("{1E60EA22-D89D-7FCB-F78A-9FAB5AD6A01F}");const CLASS_NAME = "DocWatcher: Controller service.";const CONTRACT_ID = "@docwatcher.jk.cz/controller;1";

function Controller(){/* Implementace chovanı komponenty... */

}Controller.prototype.QueryInterface = function(IID) {if (!IID.equals(Ci.dwIController) &&

!IID.equals(Ci.nsISupports))throw Cr.NS_ERROR_NO_INTERFACE;

return this;}

const Factory = {createInstance: function (outer, IID) {if (outer != null) throw Cr.NS_ERROR_NO_AGGREGATION;return (new Controller()).QueryInterface(IID);

}};

25

Rozhranı muze byt definovano naprıklad takto:

#include "nsISupports.idl"

[scriptable, uuid(1E60EA22-D89D-7FCB-F78A-9FAB5AD6A01F)]interface dwIController : nsISupports{const short NULL_ITEM = 0;readonly attribute nsISupports data;wstring getLngStringWA(in string str,

[array, size_is(paramsCount)] in string params,in unsigned long paramsCount);

};

Nejpve je potreba pripojit definice vsech rozhranı, ktera se zde vyskytujı. V hranatezavorce musı byt vzdy klıcove slovo scriptable z duvodu vyberu implementacnıho jazykakomponenty a uvedene UUID se musı shodovat s CLASS ID. Nasleduje jiz samotna definicerozhranı, pricemz se uvadı nazev rozhranı a nepovinny nazev jeho predka. V prıpade, zerodic rozhranı nenı uveden, je implicitnı nsISupports. V tele lze definovat konstanty, kteremohou byt pouze typu short nebo long. Retezcove konstanty uvedenym zpusobem defino-vat nelze, musı byt implementovany jako atribut urceny pouze ke ctenı. Metody rozhranımajı svuj nazev, u kazdeho parametru je uveden smer, povolene hodnoty jsou in, out,inout. V tomto prıkladu je uvedeno pouzitı klıcoveho slova array, ktere v dokumentaci[36] chybı. Toto klıcove slovo umoznuje danemu parametru predat pole jazyka JavaScriptvytvorene pomocı new Array() nebo []. Musı byt vsak uvedena take jeho velikost jakpomocı hodnoty klıcoveho slova size of, tak i jako parametr metody. Seznam typu a jejichekvivalentu v C++, je uveden v [12].

Pokud vyvojar zna objektove jazyky jako je napr. C++ nebo Java, je zvykly na to, zededenım prebıra potomek nejen rozhranı, ale take metody a atributy, jenz jsou soucastırodicovske trıdy. V prıpade kombinace trıd v JavaScriptu a IDL k tomu ale nedochazı. Pridedenı v IDL sice komponenta prebıra vlastnosti rozhranı rodice, avsak dana trıda musıobsahovat vsechny verejne metody a atributy, ktere se nachazejı nejen v rozhranı danekomponenty, ale i vsech jeho predcıch (krome nsISupports). V XUL dokumentu by setato situace resila snadno – i kdyz by byla kazda trida umıstena ve svem souboru, pouzitımelementu script by doslo k jejich nactenı a vytvorenı vazeb dedicnosti mezi nimi. Na urovnikomponent ale tento mechanismus nefunguje a bylo by nutne celou hierarchii trıd umıstitdo jedine komponenty, coz je velice nevyhodne. Z tohoto duvodu lze pouzıt nasledujıcı usekkodu:

function appendBaseClasses() {const BASE_CLASS_PATH = "chrome://docwatcher/content/base/Base.js";const jsloader = Cc["@mozilla.org/moz/jssubscript-loader;1"]

.getService(Ci.mozIJSSubScriptLoader);var classHolder = {};

27

jsloader.loadSubScript(BASE_CLASS, classHolder);BaseClass = classHolder.BaseClass;

Controller.prototype.__proto__ = BaseClass.prototype;}

Tato funkce by mela byt volana v metode nsIFactory::createInstance() a to pouzepri prvnım vyzadanı instance trıdy. Kod nacte obsah souboru umısteneho na URL danehokonstantou BASE CLASS PATH a jednotlive polozky umıstı do objektu classHolder. Jestlizeje v tomto souboru definovana trıda BaseClass, pak ji zıskame z classHolder pod tımtojmenem. Poslednı radek jiz provede vytvorenı vazby rodic – potomek. Dıky tohoto zpusobulze mıt vsechny trıdy implementujıcı pozadovane chovanı komponent ve zvlastnıch sou-borech, bazove tridy jsou umısteny v chrome, odkud je lze snadno zıskat, a vsechny trıdy,tj. bazove i jejich potomci majı definovane rozhranı.

Soubor, ktery obsahuje definici rozhranı, ma obvykle prıponu .idl. Pred pouzitım jevsak potreba prelozit jej do binarnı podoby, vznikne soubor s prıponou .xpt. Nastroj xpidlurceny k prekladu je soucastı vyvojoveho balıku Gecko SDK [10]. V uvedenem zdroji je iodkaz na jeho stahnutı. V operacnım systemu Windows vsak pravdepodobne dojde k chybezpusobene neprıtomnou dynamickou knihovnou libIDL-0.6.dll. Zıskat ji lze z adresy http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip [9].

Po instalaci Gecko SDK je preklad vybraneho rozhranı spusten nasledujıcım prıkazem[11]:

{sdk_dir}/bin/xpidl -m typelib -w -v -I {sdk_dir}/idl -e Controller.xptController.idl

V adresari idl/ vsak nejsou vsechna rozhranı platformy, ale pouze ta s oznacenım FROZEN.Tato rozhranı uz by se v budoucnu nemela menit. Pri vyvoji aplikacı jsou vsak vetsinouvyzadovany i dalsı rozhranı a je nutne je ze zdrojovych kodu Firefoxu zkopırovat do uve-deneho adresare idl/.

5.2.3 Bezpecnost

Protoze lze XUL aplikaci spoustet i na dalku tak, ze je umıstena na vzdalenem serveru jakobezne HTML dokumenty, mohlo by byt dıky nepozornosti uzivatele pouzıvajıcıho naprıkladFirefox stazen do pocıtace kod, ktery by mel kompletnı prıstup k celemu systemu. Protoplatforma Mozilla rozeznava prıstupova prava. Jestlize se XUL dokument nenaleza v chromelokaci, tedy nebyl nainstalovan jako rozsırenı aplikace, je veskery prıstup k XPCOM zakazana lze pracovat pouze s DOM. Aplikace si vsak muze o tato prava zazadat a pokud uzivatelodsouhlası okno s zadostı, muze aplikace dale pokracovat. Vyzadanı potrebnych prav seprovadı naprıklad nasledujıcım volanım:

window.netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

Parametr metody enablePrivilege je retezec slozeny z nazvu pozadovanychbezpecnostnıch prav, ktere se oddelujı mezerou. Zde je uveden nazev duleziteho

28

http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip

http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip

prıstupoveho prava, jenz umoznuje prıstup k XPCOM. Mezı dalsı patrı ctenı a zapiscitlivych dat prohlızece (napr. ulozena hesla), ctenı obsahu souboru a dalsı. Pro blizsıpodrobnosti je potreba nahlednout do [1], nebo prostudovat zdrojovy kod trıdynsScriptSecurityManager.

29

Kapitola 6

Datova uloziste, RDF

Existuje vıce zpusobu, jak lze ukladat textova data. Mohou byt uchovavany v textovychsouborech s ruznou internı strukturou, v dokumentech s tabulkami, ve vyspelychdatabazovych serverech. Pokud je pozadovano nenarocne lokalnı skladiste dat, mohoutextove soubory plne postacovat. Dale je potreba definovat strukturu takoveho souboru.S pouzitım znackovacıch jazyku, jako je naprıklad XML, lze prehledne ukladatpozadovana data vcetne jejich hierarchicke struktury. XML sam vsak nedefinuje, jakeprvky majı byt pouzıvany. Proto je vhodne pouzıt nejakou aplikaci XML – RDF.

6.1 Ukladanı znalostı

Resource Description Framework, zkracene RDF, je standard W3C konsorcia vyuzıvajıcıznackovacıho jazyka XML (Extensible Markup Language) ke kodovanı znalostı do textovehoformatu [19, 34, 20]. RDF je zalozen na zapisu tvrzenı o realite ve forme trojic (subjekt– predikat – objekt). Subjekt predstavuje hlavnı entitu, o ktere se neco tvrdı, predikatvyjadruje vztah a objekt druhou cast tvrzenı. Znalosti v RDF lze take modelovat pomocıorientovaneho ohodnoceneho grafu.

Jako prıklad byla zvolena stromova struktura slozek a odkazu, ktere jsou zapsanyv RDF/XML. Odpovıdajıcı graf je na obrazku 6.11. Oval zde predstavuje subjekt, obdelnıkobjekt a popisy hran reprezentujı predikaty.

Na zacatku je potreba krome jmenneho prostoru RDF nadefinovat take vlastnı jmenneprostory, ktere budou slouzit pro odlisenı nazvu predikatu od RDF entit. Trojice (subjekt,predikat, objekt) je zapisovana ve tvaru

<RDF:Description RDF:about="nazev subjektu" NS1:predikat="objekt">

kde NS1 je nazev vlastnıho jmenneho prostoru. V prıkladu je uvedena take druha moznanotace, kde predikat netvorı atribut, jak je tomu tady, ale vlastnı znacku, ve kterem senachazı objekt jako textova entita. V tomto prıpade lze uvest pro RDF procesor typhodnoty pomocı NC:parseType. Standard definuje hodnoty Literal (implicitnı hodnotaoznacujıcı retezec) a Resource (retezec je URI). Mozilla krome toho jeste podporujeInteger (retezec je cele 32-bitove cıslo se znamenkem) a Date (retezec je datum).

Oba zpusoby zapisu trojice je mozne kombinovat az na jedinou vyjimku, kterou je odkazna jiny subjekt pomocı RDF:resource. Ten muze existovat pouze jako atribut.

1Tento obrazek je upraveny graf, ktery vygeneroval RDF validator na http://www.w3.org/RDF/

Validator/

30

http://www.w3.org/RDF/Validator/


Obrazek 6.1: Graf trojic odpovıdajıcı prıkladu v RDF

<?xml version="1.0"?><RDF:RDF xmlns:NS1="http://docwatcher.cz/rdf#"

xmlns:NC="http://home.netscape.com/NC-rdf#"xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<RDF:Description RDF:about="rdf:#$ygqD31"NS1:label="Parent folder">

<NS1:subfolder RDF:resource="rdf:#$zgqD31"/></RDF:Description><RDF:Description RDF:about="rdf:#$zgqD31"

NS1:label="Folder"><NS1:link>

<RDF:Description RDF:about="rdf:#$agqD31"><NS1:label>Mozilla</NS1:label><NS1:url NC:parseType="Literal">

http://www.mozilla.org</NS1:url>

</RDF:Description></NS1:link><NS1:link RDF:resource="rdf:#$bgqD31"/>

</RDF:Description><RDF:Description RDF:about="rdf:#$agqD31"

NS1:label="Google"NS1:url="http://www.google.com"/>

</RDF:RDF>

Z prıkladu je dale patrny zpusob uchovavanı znalostı. Mısto toho, aby bylo receno:“Slozka obsahuje odkazy na Google a Mozillu”, je kazdemu vyrazu prirazen jedinecny iden-tifikator. Teprve mezi nimi se tvorı vazby. Puvodnı vetu musıme tedy rozdelit na vıce

31

castı: “Existuje zroj s ID rovnym rdf:#$zgqD31. Tento zdroj ma nazev slozka a obsahujereference na odkazy s ID rdf:#$agqD31 a rdf:#$zgqD31. Zdroj rdf:#$agqD31 ma nazevMozilla a URL http://www.mozilla.org. Zdroj rdf:#$bgqD31 ma nazev Google a URLhttp://www.google.com.”

Hierarchickou strukturu lze stavet dvema zpusoby. Potomky nadrazene entity je moznevkladat prımo do rodicovskeho subjektu. Prıklad teto moznosti je ukazan zapisem vz-tahu Slozka – odkaz Mozilla. Druha moznost spocıva v umıstenı potomka kdekoli do RDFsouboru a nasledne odkazanı se na nej pres RDF:resource. Dıky tohoto atributu lze vytvaretpropojenı mezi libovolnymi subjekty.

Pro vytvarenı seznamu je mozne pouzıt tyto specialnı tagy: <Seq> vytvarı usporadanyseznam, <Bag> je prosta kolekce polozek, kde muze dojıt k zamene jejich poradı a <Alt>uvozuje seznam, z nehoz je vybrana vzdy pouze jedina polozka. Ve vsech trech prıpadechjsou polozky ohraniceny elementem <li>. V takovem seznamu je kazda polozka chapanajako trojice (ID seznamu, automaticky generovany anonymnı nazev predikatu ve tvarurdf: cıslo, polozka).

6.2 Dotazovanı

Dıky toho, ze znalosti jsou modelovany jako trojice, lze snadno provadet dotazovanıpodobne, jako v jazyce Prolog. Tohoto faktu vyuzıvajı take projekty pod oznacenımSemanticky Web, ktere si kladou za cıl prevest informace z dokumentu na Internetu dovhodne pocıtacove reprezentace za ucelem vytvorenı jednotneho zpusobu vymeny azpracovavanı informacı.

Softwarova platforma Mozilla poskytuje tzv. Templates, dıky nichz lze prımo pripojitdatovy RDF zdroj k prvkum uzivatelskeho rozhranı. V XUL se nadefinujı dotazy, ktereRDF procesor zpracovava, vysledky uklada do pozadovanych promennych a tyto promennese prirazujı pozadovanym atributum UI prvku. Podporovany jsou i hierarchicke struktury,takze je mozne tımto zpusobem plnit stromy i rozsahle vıceurovnove nabıdky. U techtoslozitejsıch komponent je dostupne tzv. pozdnı prirazenı, ktere zajist’uje nahravanı dat azv okamziku, kdy jsou potreba. Jestlize ma zdroj naprıklad 100000 polozek a nulta urovenobsahuje jen deset polozek, jsou nacteny pouze tyto polozky a dalsı az v okamziku otevrenınejake vetve.

Proto, aby tento system fungoval, musı byt urcen datovy zdroj a vstupnı bod, coz jenazev subjektu v hierarchii RDF. Dale je urcena mnozina trojic, ktere mohou obsahovatidentifikatory s otaznıkem na zacatku, do kterych se bude ukladat pri zpracovanı zjistenahodnota. Tyto promenne se mohou nachazet na mıste subjektu i objektu, predikat musıbyt vzdy zadan. Procesor prohledava stavovy prostor od definovaneho vstupnıho bodudo urovne, ktera je dana poctem trojic v mnozine podmınek. Jestlize vsechny trojice vy-hovujı datovym zavislostem, je nalezeno resenı, zjistene hodnoty jsou prirazeny prıslusnymatributum XUL prvkum a jsou zarazeny do DOM stromu. Jestlize alespon jedna trojicenevyhovuje, je nalezene resenı neplatne. Proces se opakuje tak dlouho, dokud nejsou vsechnykombinace v danem stavovem prostoru prozkoumany.

6.3 Podpora v XPCOM

Abychom mohli pracovat s RDF, musıme znat nekolik zakladnıch komponent. Datovy zdrojreprezentuje komponenta s rozhranım nsIRDFDataSource. Obsahuje predevsım metody pro

32

ukladanı, mazanı a upravu znalostı. Pri ukladanı trojice pomocı XPCOM se navıc urcuje,zda se jedna o pravdivou nebo nepravdivou informaci, coz je dano ctvrtym parametremmetody Assert(). Temer vzdy je hodnota nastavena na true. Komponenta dale disponujemetodami pro prochazenı hierarchiı trojic daneho zdroje.

Jestlize jsou data menena z vıce mıst, muze byt pro transformaci pohledu vhodne defi-novat jedine mısto, kterym muze byt objekt s rozhranım nsIRDFObserver. Tento objektnabızı 6 ruznych udalostı, na ktere lze reagovat: vkladanı a mazanı znalosti, zmena hod-noty objektu ve trojici, zmena hodnoty predikatu trojice a zacatek a konec hromadnychuprav. Tyto poslednı dve udalosti mohou byt pouzıvany naprıklad v prıpade, ze programhodla vykonat vıce zmen v datovem zdroji a reagovanı na vsechny tyto upravy by cinnostzbytecne zdrzovalo. Datovy zdroj umoznuje tyto objekty s udalostmi dynamicky pridavata odebırat.

Z rozhranı nsIRDFDataSource jsou dale odvozeny nektere specifictejsı typy, naprıkladdatovy zdroj umısteny v pameti (nsIRDFInMemoryDataSource) a datovy zdroj slozeny zvıce jinych RDF zdroju (nsIRDFCompositeDataSource), ktery lze priradit vsem prvkumuzivatelskeho rozhranı v XUL.

Platforma zprıstupnuje sluzbu s rozhranım nsIRDFService. Pomocı nı lze synchronnenebo asynchronne z daneho URL zıskat datovy zdroj nsIRDFDataSource. Sluzba se samapostara o nactenı dat, jejich rozparsovanı a ulozenı do pamet’ove reprezentace. Tato kom-ponenta take exportuje metody, ktere slouzı k vytvarenı instancı reprezentujıcıch subjekty,predikaty a objekty. V Mozille je subjekt a predikat ve trojici vzdy tvoren komponentou srozhranım nsIRDFResource, jehoz atributem URI predstavuje jejich identifikator. Objektv trojici muze byt bud’ dalsı idenfikator, nebo kokretnı hodnota typu retezec, cele cıslo,nebo datum. Implementace ukladanı typu datum reprezentovaneho 64bitovym cıslem vsaknefunguje spravne, pravdepodobne jde o Bug 302387, viz Bugzilla. Poznamenejme, ze iden-tifikatory lze vytvaret bud’ rucne, tj. vlozenım urciteho URI, nebo automaticky pomocımetody GetAnonymousResource(), ktera vytvorila naprıklad rdf:#$7G1Zn1.

Seznam polozek realizuje komponenta s rozhranım nsIRDFContainer. Typ seznamu jeurcen metodou sluzby nsIRDFContainerUtils pouzite pro jeho vytvorenı – MakeAlt(),MakeBag() a MakeSeq(). Seznam nabızı metody pro vlozenı a odstranenı polozky, zjistenıjejich aktualnıho poctu a umoznuje jimi prochazet.

33

Kapitola 7

Ladenı a testovanı aplikacı

Vyber prostredı, ktere budeme vyuzıvat pro ladenı, zavisı na pozadovane cılove platforme,na ktere bude aplikace pracovat, a na dostupnosti pomocnych rozsırenı. Protoze je tatoprace zamerena na aplikace zalozene na jadre XULRunner 1.8, nejsou zde zmıneny zpusobyladenı a testovanı pro produkty SeaMonkey1, dnes jiz zastaraly Mozilla Suite a drıvejsıverze Firefox a Thunderbird pred verzı 1.5.

V pocatecnıch fazıch vyvoje cılove aplikace je pro ladenı nejvyhodnejsı Firefox 1.5nebo 2.0. Nizsı verze je vhodna v prıpade, ze vysledna aplikace ma pracovat s produk-tem Firefox 1.5 a vyse, Thunderbird 1.5 a vyse, XULRunner 1.8, nebo s nekterym dalsım,jako je Flock, Sunbird, Songbird a dalsı. Pro Firefox totiz existuje nejvıce potrebnychladıcıch nastroju a disponuje moznostı zjednoduseneho pripojovanı novych softwarovychcastı. Jakmile se vsak dostane vyvoj do faze, kdy se jiz vyuzıvajı nestandardnı kom-ponenty dostupne pouze v danem cılovem produktu, je potreba provadet testovanı vevsech produktech, ktere majı byt rozsırenım podporovany. Je take potreba uvedomit si,ze na funkcnost mohou mıt vliv i minoritnı aktualizace stavajıcı aplikace. Vyvojar se paksetkava s problemy, kde v jedne verzi nejaky potrebny kod nepracuje spravne, a proto sepokusı chybu obejıt naprıklad pomocı jine XPCOM komponenty. V dalsı verzi je pak chybaopravena, avsak puvodne vyuzita XPCOM komponenta doznala zmen, ktere zpusobı jinechovanı nez vyvojar zamysel. Dostava se tımto do situace, kdy jeden kod nepracuje ve dvouruznych verzıch. Ano, platforma se stale dynamicky vyvıjı, s temito problemy je potrebapocıtat.

7.1 Konfigurace prohlızece Firefox

Jestlize je Firefox na pocıtaci vyvojare pouzıvan jako standardnı prohlızec, je rozumnevytvorit novy profil pro ucely programovanı a testovanı, ktery nebude sdılet nastavenı,programove doplnky, ale i chyby, ktere se urcite budou objevovat. Pokud Firefox bezı, jepotreba jej zavrıt. Nynı spustıme Firefox s parametrem -P, cımz se zobrazı okno “Vyberprofilu uzivatele”, kde vytvorıme novy profil. Aby se puvodnı profil urceny pro prohlızenıwebovych stranek implicitne nacıtal pri startu Firefoxu, je nutne vybrat jej ze seznamu amıt zaskrtnute tlacıtko “Neptat se pri startu”. S takto nastavenym prohlızecem nedoslok zadne viditelne zmene, puvodnı programovı zastupci fungujı stejne.

1I kdyz aktualnı verze SeaMonkey i Firefox 2.0 vyuzıvajı Gecko 1.8, majı odlisny zpusob registrace novychrozsırenı a strukturu adresaru.

34

Pro spustenı Firefoxu s vyvojovym profilem nazvanym dev je vhodne pouzıt nasledujıcıdavkovy soubor (urceny pro OS Windows):

set MOZ_NO_REMOTE=1"C:\Program Files\Mozilla Firefox\firefox.exe" -console -P dev

Prvnı prıkaz nastavujıcı promennou daneho prostredı slouzı k zajistenı vytvorenı noveinstance Firefoxu. Pokud by Firefox byl jiz spusten s jinym profilem nez dev a tento prıkazzde chybel, byly by vsechny parametry nasledujıcıho radku ignorovany a bylo by pouzeotevreno dalsı okno jiz bezıcıho profilu. Parametr -console zajist’uje zobrazenı konzolovehookna, do ktereho lze pak zapisovat a -P dev zpusobı nactenı profilu pro vyvoj [21].

Dalsı krok spocıva v nastavenı parametru profilu dev. Jednou z moznych cest je otevrıtsi stranku about:config a na nı nastavit binarnı hodnoty nasledujıcıch polozek na true.Pokud polozky chybı, musı byt vytvoreny:

• javascript.options.showInConsole – chyby, ktere se vyskytnou v chrome oblasti,budou logovany do Chybove konzoly.

• nglayout.debug.disable xul cache – vypına ukladanı XUL dokumentu, koduv JavaScriptu a dalsıch do vyrovnavacı pameti. Bez tohoto nastavenı by se napr.XUL dokument pri jeho prvnım nactenı ulozil do pameti, a jakakoli zmena v jehozdrojovem kodu by se az do dalsıho restartu Firefoxu neprojevila. Se zapnutouvolbou lze zdrojovy kod zmenit a znovu nactenım daneho XUL okamzite spatritnovy vysledek.

• browser.dom.window.dump.enabled – aktivuje funkci dump(str), ktera zpusobıvypis retezce str do konzole, ktera je zobrazena dıky parametru -console.

• javascript.options.strict – zapına striktnı kontrolu jazyka JavaScript, pri kteremvypisuje varovanı, ktera jsou bezne ignorovana.

7.2 Uprava aplikace

Protoze je aplikace tvorena soustavou vzajemne propojenych souboru, ktere tvorı jedinycelek, nenı vetsinou mozne testovat je samostatne. Pred verzı Firefox 1.5 bylo mozne testo-vat aplikace pouze tak, ze se vytvoril instalacnı balıcek rozsırenı, a ten se nainstaloval doprohlızece. Jestlize zde byla objevena chyba, bylo potreba upravit zdrojove kody, vytvoritnovy balıcek, predchozı odinstalovat a nainstalovat tento novy. Cely proces je pak neumernenarocny nejen na cas.

Verze 1.5 pak prisla s novym zpusobem registrace rozsırenı, takze pri ladenı nenınutne kod balit do XPI. Jestlize je dodrzovana struktura aplikace dle kapitoly 8, jepotreba provest upravu souboru chrome.manifest spocıvajıcı v nahrazenı retezcu“jar:chrome/package name.jar!” za “chrome”. Nynı vytvorıme v adresariprofile dir/extensions/ textovy soubor, pricemz profile dir oznacuje cestu k adresaris pouzıvanym vyvojovym profilem, v OS Windows XP napr. c:\Documents andSettings\Uzivatel\Data aplikacı\Mozilla\Firefox\Profiles\wvs5kema.dev. Nazev novehosouboru musı byt shodny s identifikatorem vyvıjeneho rozsırenı, tj. viz hodnota objektu vtrojici (urn:mozilla:install-manifest, id, ?) umıstene v install.rdf. Obsahem tohoto

35

souboru je jediny radek s cestou, kde sıdlı rozsırenı. Firefox musı byt schopny v tomtoadresari najıt soubory install.rdf, chrome.manifest a adresar content. Po restartu aplikaceFirefox by melo dojıt nalezenı rozsırenı a jeho instalaci.

Protoze prochazenı chrome oblasti nenı mozne, muzeme pouzıt rozsırenı Chrome List2.Dıky nej lze v prıpade problemu s instalacı nası aplikace zjistit, zda se nepodarilo aplikacizaregistrovat (vlivem chyby v nekterem z konfiguracnıch souboru), a nebo zda je aplikacev systemu prıtomna, avsak dıky uvedenı chybne cesty je dostupna pouze jejı cast.

7.3 Ladenı uzivatelskeho rozhranı

Syntakticka stranka XUL dokumentu je kontrolovana automaticky pri analyze XML. Pokudse zde vyskytne chyba, je oznaceno mısto chyby a zobrazen jejı popis. Vyjimku ovsem tvorıoverlays, ktere v prıslusnem upravovanem dokumentu zobrazı sedy pruh a cast chybnehokodu, jiz vsak bez blizsıch podrobnostı.

Spravnost semantiky XUL lze overit pouze vizualnı kontrolou vzhledu. Jestlize jenaprıklad omylem napsan chybne nazev atributu nejakeho elementu, bude tento atributtise ignorovan a k zobrazenı chyby nedojde.

Velkym pomocnıkem je DOM inspektor, ktery byva soucastı temer vsech aplikacıMozilla, je-li nainstalovan. Umoznuje prehledne prochazenı hierarchickou strukturouobjektoveho modelu libovolneho okna aplikace, nastavovanı atributu elementu, zobrazitpouzite kaskadove styly, pracovat s DOM objekty a JavaScriptem.

Krome dvou vyse uvedenych parametru prıkazoveho radku existuje jeste volba -chrome,ktera spolu s uvedenım URL odkazujıcıho na XUL dokument v chrome umıstenı spustıinstanci prohlızece, kde je zobrazen pouze XUL dokument. Takto lze naprıklad testovatsamostatne vzhled a chovanı aplikace.

7.4 Ladenı kodu aplikace

Pro vypis hodnoty konkretnı promenne je vetsina vyvojaru webovych aplikacı zvyklapouzıvat metodu Window::alert(). Bylo-li provedeno nastavenı dle kapitoly 7.1 a je-liotevreno konzolove okno Firefoxu spustene parametrem -console, je druhou moznostıvypisu libovolneho retezce metoda dump(), ktera zapisuje vystup do tohoto okna.

Pozadujeme-li vypsat obsah celeho objektu, tj. vsechny nazvy vlastnostı, konstant ajejich akutalnıch hodnot a vsech dostupnych metod, muzeme toho dosahnout tımto cyklem:

for (var name in object) {try {var value = object[name];if (typeof(value) == "function")dump(name + "()\n");

elsedump(name + " = " + value + "\n");

}catch(ex) { dump(name + " - nelze zıskat hodnotu\n"); }

}

2https://addons.mozilla.org/firefox/4453/

36

https://addons.mozilla.org/firefox/4453/

Protoze se objekt chova v jazyce JavaScript jako asociativnı pole, lze pomocı uve-deneho cyklu prochazet vsechny jeho pary nazev – hodnota. Pokud je prvkem promennanebo konstanta, zıskana hodnota je retezec reprezentujıcı skutecnou hodnotu dane vlast-nosti. Vyhodou, naprıklad oproti prohlızeci Internet Explorer, je skutecnost, ze u objektuje jako hodnota vypsan nazev trıdy, ze ktere je instance vytvorena, nikoli pouze [object].V nekterych prıpadech pri volanı z DOM objektu (napr. okna) muze nacıtanı hodnotnekterych vlastnostı zpusobit vyhozenı vyjimky. Proto se zde musı nachazet try/catchblok. Poslednı pripomınka je k metodam – protoze je hodnota metody bud’ vypis jejı im-plementace, je-li znama, nebo systemovy retezec [native code], je vystup pro snadnejsıcitelnost upraven.

Aplikace Firefox nabızı nastroj nazvany “Chybova konzola”, avsak pro ladenı je vhodnenahradit jej rozsırenım Console2 3. Narozdıl od prıtomne chybove konzoly umoznuje takefiltrovanı zprav a vyhodnocovanı vlozeneho kodu.

Nejpohodlnejsı zpusob ladenı vsak nabızı Venkman Debugger4, coz je komplexnı grafickeladıcı prostredı urcene pro jazyk JavaScript. Mezi podporovane funkce patrı naprıklad pod-pora zarazek (tzv. breakpoints), zobrazenı zasobnıku volanı, dynamicke prohlızenı hodnotpromennych a prochazenı hierarchiı objektu [31]. Taktez je k dispozici konzola, do ktere lzeinteraktivne zadavat prıkazy rıdıcı beh programu a vyhodnocovat vlozeny kod.

Dalsım uzitecnym rozsırenım je Developer’s Extension5. Nabızı interaktivnı testovanıXUL kodu, takze pri psanı kodu ihned vidıme vysledek, konzoli pro testovanı kodu v jazyceJavaScript s prıstupovymi pravy k XPCOM, nastroj pro vyhodnocovanı regularnıch vyrazua dalsı funkce.

Zbyva jeste upozornit na knihovnu XULUnit6 urcenou pro vytvarenı testovacıchprıpadu a nasledne automaticke testovanı JavaScriptoveho kodu. Aby bylo mozne testovataplikaci zevnitr, musı byt tato knihovna soucastı chrome oblasti. Lze ji naprıkladumıstit do adresare content/test a tım zıska prıstup ke vsem komponetam aplikace. Vimplementaci teto knihovny je vsak chyba, protoze vyuzıva vlastnosti opener, jenz vchrome nenı dostupna. Naprava spocıva v uprave dvou radku:

• xulunit.js:this. window = window.open("testrunner.xul", ...) zmenit nathis. window = window.openDialog("testrunner.xul", ..., 400,testRunner)

• testrunner.xul:vsechny vyskyty opener. testrunner zmenit na window.arguments[0]

7.5 Ladenı komponent

Ladenı komponent je ponekud komplikovanejsı nez v predchozım prıpadu. Nenı zde dos-tupne prıme volanı metody alert(), proto se nejcasteji pouzıva dump(). Ladıcı nastrojVenkman Debugger je mozne pouzıt, ovsem vstupnı bod ladenı byva v kodu aplikace, nikoliuvnitr komponenty, a bohuzel nezvlada prechod do asynchronne volaneho kodu.

3http://console2.mozdev.org/4https://addons.mozilla.org/firefox/216/5http://ted.mielczarek.org/code/mozilla/extensiondev/6http://xulunit.mozdev.org/

37

http://console2.mozdev.org/


http://ted.mielczarek.org/code/mozilla/extensiondev/

http://xulunit.mozdev.org/

Problematiku ladenı lze rozdelit do dvou skupin dle typu komponenty, tj. zda jde osluzbu jedinecnou v celem pamet’ovem prostoru platformy, nebo zda se jedna o beznoukomponentu s libovolnym poctem instancı, jenz je vytvarena pomocı createInstance().

Zacneme jednodussım prıpadem, komponentami zıskanymi pomocıcreateInstance(). Jestlize kompenta byla jiz nactena do pameti platformy a vyvojarnalezne a opravı chybu v implementaci, nedojde pri dalsım volanı createInstance() kvytvorenı instance s opravenou implementacı. Pri kazde zmene kodu komponent by tedybylo nutne platformu restartovat. Tuto situaci lze resit podobnym zpusobem, jako jeresena dedicnost uvnitr komponent:

const SOURCE = "chrome://docwatcher/content/compdevel/Controller.js";const loader = Cc["@mozilla.org/moz/jssubscript-loader;1"]

.getService(Ci.mozIJSSubScriptLoader);const BaseClass = null;

createInstance: function (outer, IID) {if (outer != null) throw Cr.NS_ERROR_NO_AGGREGATION;

appendBaseClasses();

var obj = {};loader.loadSubScript(SOURCE, obj);obj.Controller.prototype.__proto__ = BaseClass.prototype;return (new obj.Controller()).QueryInterface(IID);

}

Pri kazdem volanı createInstance() jsou znovu nacteny zdrojovy kod dane trıdy kom-ponenty i vsech jeho predchudcu. Funkce appendBaseClasses() odpovıda funkci uvedenejako prıklad v kapitole 5.2.2. Tento zpusob ma dve mensı nevyhody – vytvarenı instancıtechto komponent je pomale a platforma ma nekdy problem s uvolnovanım pameti. Druhyproblem spocıva v tom, ze pokazde, kdyz je vytvarena nova instance, jsou zaroven vytvarenyi nove bazove trıdy. V ostrych verzıch software vsak bude existovat pouze jedina bazovatrıda. Jestlize je chyba soucastı bazovych trıd, nemusı se to v nekterych prıpadech pri ladenıuvedenym zpusobem projevit. V ostre verzi pak muze byt pozorovano vzajemne ovlivnovanıatributu instancı odvozenych trıd. Proto je nezbytne i dukladne testovanı ostrych verzı, zdeuz vsak pomaha jen dump() a restarty platformy.

Jestlize potrebujeme odladit sluzbu, je predchozı resenı nefunkcnı, protoze instancekomponenty se vytvarı pouze jednou a pak uz je vracena jen jejı reference. Resenı spocıvav nekolika krocıch. Je potreba vytvorit XPCOM sluzbu, ktera bude schopna uchovavatreference na objekty. Sluzbu nazveme ObjectStorageService, prıklad jejı implementace:

function ObjectStorageService() {var objects = [];

this.getObject = function(objName) {return (objects[objName]);

}

38

this.setObject = function(objName, instance) {objects[objName] = instance;

}

this.REINIT = function() {var controller = Cc["@docwatcher.jk.cz/controller;1"]

.createInstance(Ci.dwIController);objects["Controller"] = controller;

};

this.REINIT();}

Aplikace uz nesmı volat metodu getService() pro obdrzenı ladenych sluzeb, mıstotoho jsou tyto sluzby zıskavany volanım metody ObjectStorageService::getObject().Pri jejım prvnım volanı je take spustena metoda REINIT(), ktera vytvorı instance vsechladenych sluzeb aplikace a ulozı je do sveho pole. V okamziku, kdy zmenıme implementacinektere trıdy reprezentujıcı sluzbu, spustıme nejakym zpusobem znovu metodu REINIT(),ktera upravene trıdy nacte. Soucastı uprav je tedy i zmena implementace metodcreateInstance() podle predchozıho prıkladu, aby dochazelo k automatickemu nacıtanınovych zdrojovych kodu.

Pro uplnost je potreba uvest, ze v prıpade zmeny rozhranı komponenty byva nejjistejsıcestou odinstalace komponenty pres Spravce doplnku, restartovanı Firefoxu, cımz dojde kodebranı zaznamu o tomto rozsırenı, a po zavrenı spusteneho prohlızece lze opet v adresaris rozsırenımi vytvorit soubor odkazujıcı na mısto s testovanou aplikacı.

Mezi nastroje, ktere je mozne pouzıvat pri vyvoji XPCOM komponent patrıXPCOMViewer7, jenz zobrazuje seznam dostupnych komponent, rozhranı a chybovychkonstant a nabızı moznost jejich filtrovanı. Dıky nej muzeme snadno zjistit, zda instalacenove komponenty probehla bez chyb a zda jsou vsechny vlastnosti dostupne. Druherozsırenı ma nazev Leak Monitor8, ktery je schopen detekovat uniky pameti a upozornitna ne.

7.6 Ladenı RDF

Pro overenı spravnosti zapisu v jazyce RDF/XML vyuzıvame sluzbu validatoru, jenz jedostupna na strankach W3C9. Ze zapisu dokaze zıskat dostupne trojice znalostı a prıpadneje znazornit ve forme grafu.

V prıpade, ze pozadujeme kontrolu obsahu datoveho zdroje, ktery se nachazıpouze v pameti, lze zıskat aktualnı stav ve forme textu pomocı metodynsIRDFXMLSource::Serialize(). Kod, kterym lze tento prevod provest, je uveden jakoprıklad v kapitole 5.2.1. Vstupnı promenna ds musı obsahovat referenci na danydatovy zdroj s rozhranım nsIRDFDataSource. Vysledny textovy retezec je ulozen voutputStream.data.

7http://xpcomviewer.mozdev.org/8https://addons.mozilla.org/firefox/2490/9http://www.w3.org/RDF/Validator/

39

http://xpcomviewer.mozdev.org/



Kapitola 8

Distribuce aplikacı

Aby bylo mozne aplikaci distribuovat a nasledne provozovat, je potreba dodrzovat urcitoustrukturu adresaru. Koren obsahuje tyto polozky:

• components/* – adresar se soubory XPT, ktere obsahujı prelozena IDL rozhranı kom-ponent a jejich implementace v souborech .js.

• defaults/preferences/*.js – implicitnı nastavenı aplikace ulozena v souborech s prıponou.js. Radek z tohoto souboru vypada naprıklad takto:pref("extensions.docwatcher.enabled", true);Po instalaci rozsırenı lze tyto hodnoty menit na specialnı strance about:config a pro-gramovy prıstup k nim zajistuje XPCOM komponenta s rozhranım nsIPrefService.

• chrome/ – adresar, ktery po instalaci predstavuje koren tzv. chrome oblasti, ve kterejsou zdrojove kody aplikaci, textove konstanty, soubory s kaskadovymi styly a dalsıpolozky, napr. obrazky. Programove soubory zıskavajı v teto oblasti automatickyprıstupova prava k XPCOM. Obvykle obsahuje tri podadresare:

– content – obsahuje soubory XUL, XML, JS.

– locale – nachazı se zde jeden nebo vıce adesaru s nazvem udavajıcım jazyktextovych konstant ulozenych v souborech, ktere obsahuje. Soubory .dtd jsouspojovany s XUL, k retezcum ze souboru .properties je mozny prıstup z koduaplikace, viz kapitola 4.3.

– skin – zde byvajı kaskadove styly, obrazky a dalsı soubory pro potreby upravvzhledu.

Cesta chrome://docwatcher/content/*.xul umoznuje zprıstupnit soubory XUL,pricemz docwatcher oznacuje nazev aplikace, ktery je uveden v chrome.manifest.

• platform/ – adresar s kodem zavislym na operacnım systemu a hardwarove platforme.Podrobne informace lze nalezt v [22].

• install.rdf – soubor pouzıvany pri instalaci rozsırenı, sklada se ze dvou castı – informacıo produktu, tj. jeho jedinecny identifikator dle UUID, jmeno, verze, adresa URL adalsı a seznamu aplikacı danych jejich UUID a rozsahem verzı, do kterych lze totorozsırenı instalovat. Podrobne vysvetlenı vsech polozek je uvedeno v [14] a seznamplatnych verzı a identifikatoru produktu Mozilla se nachazı v [30].

40

• chrome.manifest – soubor, jenz identifikuje obsah adresare chrome. Zaroven takenahrazuje stare registracnı soubory contents.rdf, ktere byly pouzıvany pred verzıFirefox/Thunderbird 1.5, avsak jsou stale nutne pro fungovanı rozsırenı v aplikaciSeaMonkey. Podrobny popis uvadı [4].

Existujı dve moznosti, jak lze aplikace provozovat – jako rozsırenı jiz existujıcı aplikacenebo samostatne spustitelny program. Prvnı moznost spocıva v integraci nove aplikace donektere hostitelske aplikace vyuzıvajıcı platformu Mozilla. Do teto varianty spadajı rozsırenıs prıponou .xpi, ktere lze stahovat naprıklad na webovych strankach MozDev.org1.

Rozsırenı .xpi je zabaleny archiv algoritmem ZIP, ktery obsahuje vyse uvedenouadresarovou strukturu, az na obsah adresare chrome. Ten je zabalen opet algoritmem ZIPdo archivu s prıponou .jar. a tento archiv se jako jediny nachazı ve slozce chrome.

Druhou moznostı je vytvorenı samostatne spustitelne aplikace. Jejı vyvoj se po pro-gramove strance temer nelisı od implementace rozsırenı. Jediny rozdıl je v tom, ze je nutneurcit hlavnı okno aplikace, a XUL elementy overlay tedy postradajı smysl.

V predchozım prıpade byla aplikacnı platforma soucastı hostitelske aplikace. Zde seuplatnuje XULRunner, coz je platforma prelozena pro konkretnı operacnı system dospustitelne podoby [39]. Uzivateli se tedy dodava instalator obsahujıcı XULRunner azabalenou aplikaci. Pri instalaci do systemu uzivatele jsou tyto dve casti zkopırovany napozadovane mısto a nasledne je spustena registrace aplikace do behoveho prostredıXULRunner. Tım dojde k jejich propojenı.

Platforma take nabızı moznost automatickych aktualizacı aplikacı, ktere ji vyuzıvajı. Vsouboru install.rdf je potreba uvest i parametr updateURL, jenz obsahuje adresu RDF/XMLdokumentu udavajıcıho oznacenı dostupnych verzı a pravidla, jakym zpusobem se majıaplikace aktualizovat. Podrobny popis s vysvetlenım vsech polı je dostupny v [7].

1http://www.mozdev.org/projects/active.html

41

Kapitola 9

Aplikace DocWatcher

Nastroju pro sledovanı zmen dokumentu v sıt’ovem prostredı nenı mnoho. V dubnu 2005byl na [3] proveden test techto aplikacı. Vysledky lze rozdelit do ctyr skupin:

• Vıtezem se stal WebSite-Watcher spolecnosti Aignes1.

• Dalsı prıcku obsadily ostatnı komercnı programy nabızejıcı nizsı mnozstvı funkciona-lity: Check&Get2, Copernic Tracker3, TimelyWeb4, Right Web Monitor5 a Wysigot6.

• Nasledujı volne dostupne programy, jejichz moznosti jsou jen zakladnı: WebMon7,Check4Me8 a InfoIC9.

• Poslednı skupinu tvorı webove sluzby hlıdajıcı zmeny v dokumentech na Internetu:WatchThatPage10, TrackEngine11.

Uvedene programy se lisı predevsım moznostmi vyberu castı dokumentu, ktere budouporovnavany, a ktere budou naopak ignorovany. Tretı skupina je zcela nepouzitelna prowebove stranky, ve kterych se napr. dynamicky generuje aktualnı datum. Ctvrta skupina– webove sluzby – ma nevyhodu v podobe slabych moznostı reakce na zmenu. I kdyz jesluzba propracovana, vetsinou nabızı jen moznost odeslanı e-mailove zpravy. Naproti tomulokalnı aplikace mohou provest na pocıtaci nejakou akci, napr. spustit program. Vhodne proaktivnı pouzıvanı jsou tedy jen programy prvnı a druhe skupiny, ktere jsou vsak komercnıa jejich volne verze jsou casove a nebo funkcne omezene. Navıc, vsechny aplikace, kromewebovych sluzeb, jsou dostupne pouze pro operacnı system Windows. Zatım tedy chybıvolne dostupna multiplatformnı aplikace s otevrenym kodem.

Tuto mezeru se bude snazit zaplnit novy program nazvany DocWatcher, ktery jepostaven na diskutovane aplikacnı platforme Mozilla. Nynı je hlavnım cılem vytvoritzakladnı aplikaci, kterou bude mozne dale upravovat a rozvıjet.

1http://www.aignes.com2http://activeurls.com/en/3http://www.copernic.com/en/products/tracker/index.html4http://www.timelyweb.com/index.html5http://www.right-soft.com/webmon/6http://www.wysigot.com/7http://www.markwell.btinternet.co.uk/webmon/8http://www.neogie.com/check4me/9http://www.infoic.com/Index.asp

10http://www.watchthatpage.com/11http://www.trackengine.com/

42

http://www.aignes.com

http://activeurls.com/en/

http://www.copernic.com/en/products/tracker/index.html

http://www.timelyweb.com/index.html

http://www.right-soft.com/webmon/

http://www.wysigot.com/

http://www.markwell.btinternet.co.uk/webmon/

http://www.neogie.com/check4me/

http://www.infoic.com/Index.asp

http://www.watchthatpage.com/

http://www.trackengine.com/

9.1 Navrh aplikace

9.1.1 Stanovenı pozadavku

Pozadavky zahrnujıcı podporu vıce operacnıch systemu a HW architektur a volnou dos-tupnost jiz byly zmıneny. Nynı se proto zamerıme na funkcnı pozadavky, tedy na to, coprogram bude uzivateli nabızet. Vetsina uvedenych pozadavku vychazı z funkcı, ktere nabızıWebSite-Watcher [33].

• Testovanı zmen dokumentu v sıt’ovem prostredı – podpora protokolu HTTP(S), FTPi lokalnıch dokumentu dostupnych pres file:///.

– Binarnı formaty – pouze informace o zmene, kontrola dle parametru delkasouboru, cas modifikace nebo obsah.

– Textove formaty – moznost nastavit, ktere casti dokumentu majı byt sledovanynebo ignorovany, ktere vyskyty retezcu majı byt hlıdany. Jestlize nenı uplatnenfiltr, je dokument kontrolovan nekterym z parametru uvedenych u binarnıchformatu.

• Podpora autentizace pomocı SSL.

• Nastavenı intervalu kontrol – kontrolovanı dokumentu pri spustenı programu,v zadanem intervalu, manualne v libovolny okamzik.

• Ukladanı predchozıch verzı dokumentu a moznost pohybovat se historiı zmen, zadanıhloubky historie.

• Notifikace: zobrazenı informacnıho okna, zvukove upozornenı a spustenı externı ap-likace

Mezi pozadavky je jeste vhodne uvest, ze vysledna aplikace bude primarne fungovat jakorozsırenı produktu Firefox a Thunderbird, avsak kod by mel byt psan tak, aby bylo moznevytvorit i samostatne spustitelnou aplikaci. DocWatcher pak bude dostupny v nabıdce“Nastroje”.

9.1.2 Architektura aplikace

Celkovy pohled na propojene komponenty teto aplikace je uveden na obrazku 9.1. Tlustacara oznacuje hlavnı datovy tok, kde se prenası vetsı mnozsvı dat, carkovana tenka caraodpovıda rıdıcımu toku, kde se volajı operace a prochazı udalosti. V tomto modelu jsouzahrnuty nektere charakteristicke vlastnosti aplikacnı platformy Mozilla.

Aplikace je slozena z nekolika hlavnıch komponent. Prvnı s nazvem Database zodpovıdaza nacıtanı a ukladanı nastavenı jednotlivych slozek a odkazu do RDF uloziste dat, jehozstruktura je popsana v kapitole 9.1.3. Uzivatelske rozhranı nacıta data z Database v prıpade,ze uzivatel chce zobrazit vlastnosti slozky nebo odkazu a ukladanı dat probıha v okamzikuvytvorenı novych nebo upravenı jiz existujıcıch dat entit. Krome toho je uzivatelske rozhranıprımo napojeno na datovy zdroj pomocı Templates, seznamy slozek a odkazu jsou gene-rovany prımo z nej.

Dalsı vyznamna komponenta je Timer. Jestlize uzivatel zvolı automaticke kontrolovanıodkazu v urcitych intervalech, tato komponenta si automaticky ve spolupraci s Databasezjist’uje, kdy ma byt prıstı kontrola a jakmile tento cas nastane, preda dany odkaz kekontrole komponente Controller.

43

Obrazek 9.1: Celkovy pohled na propojene komponenty aplikace DocWatcher

Controller je rıdıcı komponenta cele aplikace. Krome podpory ostatnım castem ap-likace slouzı take ke spoustenı kontroly vybranych odkazu. Podle umıstenı dokumentu jeodkaz poslan k nactenı do prıslusne komponenty, naprıklad dokumenty s URL zacınajıcıhttps:// jsou zaslany ke zpracovanı komponente HTTPSource. Jestlize je vybrano kon-trolovanı dle obsahu, nebo je-li zapnuto ukladanı do historie, je pri nacıtanı dokumentudatovy tok ukladan do docasneho souboru. Pozdeji muze byt presunut do uloziste verzıdokumentu. Jestlize je vybrano kontrolovanı dokumentu dle jeho obsahu, zpracovava jejprıslusna komponenta s postfixem Target, v opacnem prıpade udaje o velikosti souborunebo datumu poslednı zmeny zjist’uje nacıtajıcı komponenta. Jestlize je zjistena odlisnahodnota od te, jenz je ulozena u prıslusneho odkazu, je zahlasena zmena.

9.1.3 Ukladanı entit do databaze

ER diagram zobrazujıcı perzistentnı vztah slozek, odkazu a dalsıch podpurnych entit jezobrazen na obrazku 9.2.

Oproti puvodnımu navrhu, jenz byl soucastı semestralnıho projektu, byl tento navrhznacne upraven. Puvodne byla zamyslena moznost hierarchicky definovat spolecne vlast-nosti. Naprıklad uzivatelske jmeno a heslo bylo mozne nastavit na urovni slozky a u vsechodkazu, ktere by mely tyto vlastnosti nevyplnene, by doslo k jejich prevzetı. Po zkusebnı im-plementaci tohoto zpusobu se vsak ukazalo, ze uzivatele jsou spıse zmateni a tuto moznostnevyuzıvajı. Take ji temer plne muze nahradit funkce, ktera umoznuje vybrat vıce odkazunajednou a nastavit v jednom okamziku vybrane hodnoty na jednu konkretnı hodnotu.

Diagram obsahuje pet typu entit. ItemBase je bazova entita v hierarchii dedicnosti, zekterych dedı spolecne vlastnosti entity odkaz (Link) a slozka (Folder). Jedna slozka muze

44

Obrazek 9.2: ER diagram zobrazujıcı perzistentnı vztah odkazu a slozek

obsahovat vıce zanorenych slozek a odkazu a take vsechny tyto entity majı, s vyjimkoukorenove slozky, nadrazenou slozku. Vyznam vetsiny atributu je jasny, proto je zde uvedenojen nekolik podrobnostı:

• targetType – cıl odkazu, dokument muze byt v textovem, binarnım formatu, HTMLatd.

• compareType – zpusob porovnavanı verzı dvou dokumentu, je mozna jednaz vyctovych hodnot: velikost souboru, datum a cas zmeny souboru, kontrola obsahu.S tım take souvisı atribut data v entite odkaz, ktery obsahuje hodnotu zavislou natypu porovnavanı. Je zde tedy ulozena bud’ velikost poslednı verze dokumentu, nebokonkretnı datum a cas poslednı zmeny a nebo otisk zıskany algoritmem MD5.

• alertMessage – udava, zda bude vyskakovat okno se zpravou.

Kazdy odkaz ma informace o tom, kdy ma byt kontrolovan. Tyto udaje jsou ulozenyv entite TimeSchedule. Vlastnost periodGranularity muze nabyvat jednu z vyctovychhodnot sekunda, minuta, hodina, den, mesıc.

Fitrum je venovana vlastnı kapitola 9.2.5, kde je take vysvetlen vyznam atributu entity.Poslednı entita HistoryVersion slouzı k udrzovanı prehledu o ulozenych verzıch jed-

noho dokumentu, pricemz je uchovavan unikatnı identifikator kopie a casove razıtko jejıhoporızenı.

Poznamka – jestlize uvazujeme realizaci teto perzistence na platforme Mozilla, zjistıme,ze vsechny tyto zaznamy budou ulozeny v jednom XML souboru. Hesla se zde budouzrejme nachazet v otevrene textove podobe, coz muze byt znacne bezpecnostnı riziko.Proto v dalsıch verzıch tohoto nastroje bude potreba vyresit zpusob zabezpecenı a sifrovanıtechto citlivych dat, bude take nutne detailne prozkoumat implementaci spravce hesel,jenz je soucastı platformy Mozilla. Asi jedinym dostatecne univerzalnım resenım pak budenabıdnout uzivateli ochranu citlivych udaju pomocı spolecneho hesla, ktere bude muset

45

vkladat pri startu aplikace. V takovem prıpade je pak mozne sifrovat data nekterym zesymetrickych kryprovacıch algoritmu.

9.2 Detaily implementace

Pri vyvoji aplikace DocWatcher doslo k nutnosti prepracovat vetsı cast zdrojoveho kodu.Prvnı verze implementovala trıdy Database, Controller, Timer jako bezne trıdy na urovniXUL dokumentu. Protoze uzivatel mohl spustit vıce oken weboveho prohlızece a kazdeokno si vytvarı nove instance vsech definovanych promennych a trıd, doslo by k tomu,ze v systemu by fungovalo vıce techto objektu. Dokumenty by mohly byt kontrolovanyvıcekrat za sebou, vıce instancı Database by zpusobilo problemy v datovem ulozisti. Protobyla v XPCOM vytvorena sluzba ObjectStorageService, ktera udrzovala jedine instanceuvedenych trıd v celem prostoru platformy. V okamziku, kdy bylo nainstalovano rozsırenıLeak Monitor, viz kapitola 7.5, uzivatel otevrel nove okno prohlızece a predchozı okno zavrel,bylo zobrazeno hlasenı o uniku pameti. Prvnı okno, ktere uzivatel zavrel, totiz vytvoriloobjekty v pameti a jejich reference byly predany sluzbe ObjectStorageService k uchovanı.Protoze je objekt vytvoreny v okne prohlızece na nej interne vazan, nedoslo k uvolnenıpameti zabırane jiz zavrenym oknem. Tato skutecnost byla odstranena presunutım techtotrıd do XPCOM, byly tedy vytvoreny sluzby s rozhranımi dwIDatabase, dwIController,dwITimer. Trıdy reprezentujıcı odkazy, slozky a dalsı, ktere s nimi spolupracujı, bylo takenutne prevest do XPCOM. Doslo tım vpodstate take k dokonalejsımu odstınenı aplikacnılogiky od datove vrstvy reprezentovane dwIDatabase a dalsıch komponent aplikace.

9.2.1 Datova vrstva

Datova vrstva je tvorena komponentou s rozhranım dwIDatabase, ktera zajist’uje prıstupk datovym zdrojum ve formatu RDF/XML a naslednıky rozhranı dwIPropertyBase. Totorozhranı je abstraktnı a poskytuje operace pro praci s atributem perzistentnıho objektu.Musıme si uvedomit, ze je-li nejaky atribut trıdy cıselneho typu, naprıklad PRInt16, a ikdyz do vnitrnı reprezentace muzeme zapsat hodnotu null, nelze takovou hodnotu predatpres tento typ rozhranı. Proto dve z metod, ktere rozhranı dwIPropertyBase nabızı, jsouisNull() a setNull().

Odvozenou trıdou je ItemBase, ktera obsahuje spolecne polozky odkazu a slozek,coz jsou jmeno, poznamka a nadrazena slozka. Z nı jsou pak jiz odvozeny komponentys rozhranım dwILink a dwIFolder. Ve vsech trech trıdach je implementovano nacıtanı hod-not na vyzadanı, coz znamena, ze hodnoty jsou z RDF zdroje cteny az v okamziku, kdyjsou potreba. Kazdy atribut deklaruje mısto pro uchovanı hodnoty, jejıho typu daneho po-tomkem rozhranı nsISupportsPrimitive a v prıpade potreby je pripraven mechanismustransformace nactenych hodnot z RDF zdroje. Hodnoty nejsou do atributu prirazovanyprımo, avsak pres obalujıcı typ s rozhranım dwIType. Po vytvorenı instance trıdy jsou totizvsechny atributy nastaveny na hodnotu null a tım indikujı, ze hodnota jeste nebyla zıskanaze zdroje. Pokud by ovsem tato zıskana hodnota byla opet null, nebylo by mozne odlisitstav “nenacteno” od “hodnota = null”.

Po nactenı hodnoty atributu z databaze se automaticky vytvarı instance trıdy Typea do jejı vlastnosti value se priradı bud’ null nebo nova instance trıdy s prıslusnymrozhranım naslednıka nsISupportsPrimtive a typ rozhranı je ulozen do promenne VIID.Tım zıskavame silnou typovou kontrolu, jenz lze predavat pres IDL a zaroven take prostorpro parametrizovanı hodnot atributu. Teto vlastnosti bylo vyuzito v predesle verzi aplikace,

46

kde jeste fungovala moznost hierarchickeho nastavovanı hodnot. Takovym parametrem bylisParentValue signalizujıcı, zda je hodnota definovana u dane polozky, nebo zda tutohodnotu pouze prebıra od rodicu.

Trıda s dwIType je pouzıvana take k predavanı libovolne hodnoty pres rozhranı ty-pove bezpecnym zpusobem. Tım nedochazı k problemum, kdy pres cıselny atribut rozhranıpotrebujeme dostat null.

9.2.2 Uzivatelske rozhranı

Klıcovymi prvky uzivatelskeho rozhranı jsou hlavnı okno aplikace a dialogove okno vlast-nostı odkazu, ktere je zobrazovano pri pridavanı nebo uprave informacı o dokumentuurcenem ke kontrole.

9.2.3 Hlavnı okno aplikace

Aplikace WebSite-Watcher a TimelyWeb pouzıvajı dva ruzne zpusoby zobrazovanı polozekve stromove strukture. Lze je videt na obrazcıch 9.3 a 9.4.

Obrazek 9.3: Hlavnı okno aplikace WebSite-Watcher

V obou programech se pouzıva stromova struktura, ktera zobrazuje slozky a v prıpadeTimelyWeb take odkazy, ktere se v nich nachazejı. Jestlize je ale strom hodne rozvetvenya obsahuje velke mnozstvı slozek a odkazu na dokumenty, je zpusob zobrazenı pouzıvanyv aplikaci TimelyWeb velice neprehledny. Smıchanı slozek a odkazu do jedne strukturypusobı pomerne chaoticky.

Proto byl zvolen oddeleny pohled na strom slozek a na seznam odkazu, ktere vybranaslozka, prıpadne slozky, obsahujı. Takovy zpusob zobrazenı je take znamy z aplikace Ex-plorer v operacnım systemu Windows. Zde je mozno spatrit prvnı vylepsenı oproti uve-denym programum – lze vybrat najednou vıce slozek, pricemz se vsechny jejich polozkyzobrazı v prave casti okna. Dıky toho lze skupinove menit vlastnosti odkazu.

Hlavnı okno aplikace se tedy sestava ze dvou castı – v leve se nachazı stroms uzivatelskymi slozkami. Krome nich se zde nachazejı i tri systemove, jenz informujıo prave kontrolovanych dokumentech, chybach, ktere vznikly behem poslednıch kontrol azmenenych odkazech. V prave casti okna je umısten seznam odkazu, ktery zobrazuje tytodetaily: Nazev odkazu, URL, datum/cas poslednı zmeny, datum/cas poslednı kontroly,datum/cas prıstı kontroly a stav poslednı kontroly.

47

Obrazek 9.4: Hlavnı okno aplikace TimelyWeb

Oba XUL elementy, ktere zobrazujı slozky a odkazy, jsou prımo napojeny na dva datovezdroje. Prvnım je externı RDF, jenz je umısten v adresari docwatcher/data.rdf v danemprofilu uzivatele. O jeho prıpadne vytvorenı a nactenı se stara sluzba Database. Jsouzde umısteny vsechny udaje o odkazech a slozkach, ktere je potreba uchovavat. Jestepoznamenejme, ze vytvorenı hierarchicke struktury slozek je umozneno skladanım identi-fikatoru pomocı kontejneru realizovanych dwIRDFContainer. Jiny zpusob ukladanı znalostıdo RDF by pravdepodobne zpusobil nemoznost prımeho zobrazenı stromove struktury.Druhym datovym zdrojem je internı RDF, ktere je vytvoreno dynamicky pri startu ap-likace. Pouzıva se z nekolika duvodu. Prvnım je potreba vytvorit dvouurovnovou hierarchiislozek, kde budou vlozeny slozka “Prehled” spolu se tremi podslozkami a k nim priraditodpovıdajıcı odkazy. K teto hierarchii se pak jeste pridava korenova slozka uzivatelskychslozek, jenz jsou vzapetı take pripojeny. Druhym duvodem je interpretace hodnot uzivateli.V externım RDF zdroji je naprıklad datum poslednı zmeny ulozeno jako 64bitove cısloa tuto hodnotu nelze uzivateli vypsat. Proto jsou u odkazu definovany metody, kterevytvarı novou trojici, kde subjekt odpovıda identifikatoru odkazu, predikat uvozuje citelnoupodobu konkretnı hodnoty a objekt je retezec, zde naprıklad datum a cas. Tyto trojice jsouvytvareny pouze tehdy, jestlize uzivatel dany odkaz vybral a muze jej videt, a opet ruseny,byl-li odkaz skryt.

9.2.4 Dialogove okno vlastnostı odkazu

Druhym dulezitym prvkem uzivatelskeho rozhranı je dialogove okno s vlastnostmi odkazu.Sklada se z nekolika zalozek, na jejichz panelech lze zadat nasledujıcı udaje:

• Obecne – nazev dokumentu, adresa URL a typ souboru (textovy, binarnı).

• Nastavenı – prihlasovacı jmeno a heslo a zpusob porovnavanı dokumentu (dle obsahu,velikosti, datumu poslednı zmeny).

• Filtr – zalozka je dostupna pouze u textovych souboru. Umoznuje omezit oblast, vektere budou vyhledavany zmeny.

48

• Historie – nastavenı parametru ukladanı historie zmen dokumentu.

• Casy kontroly – moznost zaskrtnutı volby “Kontrola pri startu”, vybermanualnıch/automatickych kontrol. Ve druhem prıpade lze urcit, jak casto ma bytdokument kontrolovan.

• Akce – zpusob upozornenı uzivatele pri zmene dokumentu a prıpadne volba akce.Zahrnuje vyber zvukoveho souboru, nazev externı aplikace, ktera bude spustena amoznost urcit, zda bude zmena signalizovana vyskakujıcım oknem.

• Poznamka – karta s editacnım polem umoznujıcı zadat libovolnou textovou poznamku.

Pri vyberu vıce odkazu mohou byt vlastnosti nastavovany v jeden okamzik na stejnouhodnotu. Aplikace WebSite-Watcher tuto vlastnost take zvlada, avsak pouzıva jiny typdialogoveho okna nez je zobrazen pri vytvarenı noveho odkazu, coz muze uzivatele mast.DocWatcher vyuzıva jedine okno. Jestlize je dana vlastnost ve vsech odkazech nastavenana stejnou hodnotu, je tato hodnota uvedena. Pokud jsou hodnoty ruzne, je zobrazen ob-sah textove konstanty moreValues umıstene v souboru app.properties, prıpadne, jedna-li seo zaskrtavacı tlacıtko, je zobrazen tretı nerozhodny stav, ktery byl pro tento ucel imple-mentovan. Prave tlacıtko mysi vyvolava kontextove menu, ktere umoznı navrat na puvodnıhodnotu.

9.2.5 Proces kontroly

Po spustenı aplikace je pomocı metody dwIDatabase::getNextLinksToCheck() nalezennejnizsı cas, kdy se ma/mela spustit kontrola dokumentu. Je-li nalezeny cas mensı neboroven aktualnımu casu, je prozkoumana databaze odkazu a vyhledany ty, ktere majı bytzkontrolovany. V opacnem prıpade je vracen odkaz, ktery ma byt zkontrolovan nejdrıve.Prubeh kontroly textovych a binarnıch dokumentu je zobrazen na obrazku 9.5.

Po odstartovanı procesu kontroly dokumentu je navazano spojenı se serverem, na kteremje zkoumany dokument ulozen, nebo je otevren lokalne dostupny soubor. Take je inicializo-vana hodnota otisku dat (hash). Jestlize byla zvolena moznost porovnavanı dle velikostinebo casu zmeny souboru, je tento parametr ihned vyhodnocen a v prıpade neshodys ulozenou hodnotou je zahlasena zmena.

Soubor je cten a kopırovan do docasneho souboru po blocıch, jejichz velikost urcujevzdaleny server nebo operacnı system. Bloky jsou nacıtany asynchronne, tj. ctenı neblokujehlavnı vlakno aplikace. Jestlize uzivatel nezadal filtr, je pri kazdem nactenem bloku upravenahodnota otisku dat. Tento proces je opakovan az do nactenı celeho souboru. V prıpadeuspesneho dokoncenı stahovanı je aplikovan filtr a vypocıtan otisk vyfiltrovanych oblastı,pokud uzivatel tuto volbu vyzaduje. Nasleduje kontrola mnozstvı predeslych nactenychverzı souboru a pri prekrocenı hranicnı hodnoty je nejstarsı verze smazana.

V tomto okamziku je k dispozici hash, ktery charakterizuje oblast dat, o kterou seuzivatel zajıma. Jestlize tato hodnota je odlisna s tou, ktera je ulozena v databazi, je doku-ment zmenen, uzivateli se aktivujı vybrane zpusoby notifikace a je ulozena nova hodnota.Cely proces koncı uzavrenım spojenı nebo lokalnıho souboru.

Filtrovanı obsahu textoveho dokumentu

U textovych formatu je mozne vyuzıt funkci filtru. Prave tato funkce podstatnym zpusobemurcuje kvalitu aplikacı zamerujıcıch se na detekci zmen obsahu v dokumentech. Bez nı nelze

49

Obrazek 9.5: Diagram aktivit znazornujıcı prubeh kontroly dokumentu.

50

detekovat zmeny v dokumentech, do kterych se naprıklad automaticky generuje datum acas. Pri kazdem nactenı by byl takovyto dokument oznacen jako zmeneny.

Kazdy textovy soubor muze obsahovat hierarchickou posloupnost filtru. U kazdeho filtruse definujı nasledujıcı vlastnosti:

• ohranicenı pomocı dvou retezcu, ktere nejsou zahrnuty do testovanı a

• typ bloku, tj. zda ma byt vyznacena cast dokumentu ignorovana nebo sledovana

Pravidla definice filtru:

1. Filtrovanı je neaktivnı v prıpade, ze je zobrazen pouze jediny filtr, ktery je urcenzacatkem a koncem souboru a jehoz obsah je sledovan. Tento filtr nelze smazat.

2. Do filtru, jehoz obsah je sledovan, lze vlozit filtry obou typu:

(a) Vlozen filtr pro sledovanı bloku – rodicovsky filtr pozbyva funkce sledovanı, jizpouze vyznacuje cast v dokumentu. Novy filtr provedl upresnenı mısta sledovanı.

(b) Vlozen filtr pro ignorovanı obsahu bloku – rodicovsky filtr stale urcuje oblastsledovanı vyskytu zmen s vyjimkou oblastı, ktere majı byt ignorovany.

3. Do filtru, jehoz obsah ma byt ignorovan, jiz nelze vlozit dalsı filtr.

4. Filtry nelze prekryvat.

Aplikace filtru je cinnost systemu, pri kterem je ve vstupnıch textovych datech vyh-ledavana skupina retezcu, ktere budou nasledne testovany na shodu s minulou verzı. Filtryjsou usporadany hierarchicky, postupuje se od globalnıho filtru (viz bod 1 definice pravidel)az k nejvıce zanorenym filtrum. Je nalezen zacatek a konec bloku, ktery filtr definuje, av nem jsou aplikovany zanorene filtry. Jestlize je definovano vıce filtru na stejne urovniv hierarchii, pak zacatek noveho bloku je vyhledavan od konce bloku predchozıho. Je-linalezen sledovacı filtr, ktery jiz neobsahuje dalsı zanoreny sledovacı filtr, pak je retezecdany jeho ohranicenım a vyrıznutım vsech castı, ktere definujı ignorujıcı filtry, ulozen dopameti.

Jestlize existuje alespon jeden retezec udavajıcı hranici bloku filtru, ktery nenı v doku-mentu nalezen, pak byla zrejme zmenena struktura dokumentu a filtr nelze aplikovat.V takovem prıpade je zahlasena “Chyba filtru”.

V puvodnım navrhu v semestralnım projektu byla moznost provadet filtrovanı nad ele-menty HTML dokumentu. Aby to bylo mozne, musela by existovat nejaka trıda, kteraje schopna vykreslit v pameti danou HTML stranku, tj. vytvorit DOM model, spustitJavaScript kod, ktery tato stranka obsahuje a aplikovat CSS styly (ktere naprıklad ukryjınejake informace nebo zmenı jejich poradı). Takova trıda dostupna v jazyce JavaScriptale neexistuje. Z popisu procesu renderovanı uvedeneho v [26] a prıspevku v nekolikadiskusnıch skupinach vyplyva, ze vykreslovanı HTML dokumentu musı vzdy probıhat v kon-textu nejakeho okna. Tım se dostavame do problematicke situace – DocWatcher pracujevetsinu sveho casu pouze v pameti a okno je vytvareno az v okamziku kliknutı na volbu“DocWatcher” v menu “Nastroje”. Resenım by mohlo byt spustenı procesu renderovanıv kontextu nejakeho otevreneho okna prohlızece. Jestlize vsak uzivatel otevre nove oknoa puvodnı okno zavre, dojde k chybe a “stehovanı” na jine okno nelze provest. Druhamoznost je vyuzitı skryteho okna, ktere je potreba na operacnım systemu Mac OS X, oknoje dostupne pres atribut nsIAppShellService::hiddenDOMWindow. Vzhledem k tomu, ze

51

by melo byt toto okno z implementacı pro Windows XP a Linux casem odebrano, opet tonenı vhodne resenı. Z tohoto duvodu zustava funkce filtrovanı dle prvku DOM daneho doku-mentu nefunkcnı a v budoucnu bude snaha vytvorit komponentu v jazyce C++, ktera seprımo napojı na renderovanı, sama v pameti vytvorı skryte okno a doda potrebny kontext.

9.3 Zaverecne poznamky

Pri ladenı zdrojovych kodu byl krome principu uvedenych v kapitole 7 take vytvorenjednoduchy system komentaru pro oznacenı oblastı, ktere jsou urceny pouze pro ladenı,ktere majı byt pouze v ostre verzi, a zbyvajıcı kod. Specialnı komentar byl take vytvorenpro vkladanı souboru na dane mısto. Prıklad:

/* INCLUDE "chrome/content/compdevel/Controller.js" *//* DEBUG B */function Controller(){}/* DEBUG E */

/* RELEASE B *dump("Controller OK\n");/* RELEASE E */

Pro prevod do XPI balıku muzeme mıt vytvorenou davku, jejız soucastı je spustenınaprıklad skriptu v jazyce Perl, ktery projde vsechny soubory, komentare /* DEBUG B*/ ... /* DEBUG E */ odstranı vcetne jejich obsahu, smaze take radky /* RELEASE B *(zde opravdu chybı lomıtko) a /* RELEASE B */ a konecne radky /* INCLUDE "cesta"*/ nahradı skutecnym obsahem uvedeneho souboru. Prıklad tohoto davkoveho souboru aprıslusnych skriptu je uveden na doprovodnem DVD.

Druha poznamka se tyka komentovanı kodu v JavaScriptu a automaticke vytvarenıdokumentace. Zdrojove kody aplikace DocWatcher jsou komentovany dle mırne upravenychpozadavku aplikace Natural Docs12, ktera umoznuje prevod jasne citelnych komentaru domodernı dokumentace v HTML. Pro spravny vystup je potreba vsechny zdrojove kody jestezpracovat pomocı skriptu umısteneho na DVD.

Alternativou je JSDoc13, ktery je vytvaren pouze pro jazyk JavaScript, avsak jehovystupy uz nejsou tak hezke a u slozitejsıch konstrukcı ma problemy s rozpoznanım kon-textu.

12http://naturaldocs.org/13http://jsdoc.sourceforge.net/

52

http://naturaldocs.org/

http://jsdoc.sourceforge.net/

Kapitola 10

Zaver

Uzivatele, kterı pouzıvajı pro prohlızenı webovych stranek aplikaci nazvou Firefox a neboctou svou postu e-mailovym klientem Thunderbird vetsinou nemajı ani tusenı, jak mocnynastroj pouzıvajı a co vse je ukryto pod povrchem uzivatelskych rozhranı, se kterymipracujı. Tato diplomova prace ma snahu toto tajemstvı odkryt a predstavit svetu volnesiritelnou aplikacnı platformu Mozilla.

Jejı vyhodou je velke mnozstvı podporovanych operacnıch systemu, kterych je vıcenez deset. Teto vlastnosti je dosazeno vyspelou architekturou platformy, jejız strukturaje uvedena na zacatku teto prace. Hlavnı prednostı je vsak nativnı podpora zobrazovanı(X)HTML dokumentu a moznostı aktivne s nimi pracovat. Je mozne upravovat jejich ob-jektovy model, aniz by bylo potreba psat slozity kod.

Avsak platforma ma bohuzel i stinne stranky. Nejvetsı nevyhodou je nedostupnost kva-litnıch ucelenych informacı, ktere se zabyvajı vyvojem aplikacı na nejnovejsıch verzıch tetoplatformy. Cılem teto prace je proto navazat na knihu Rapid Application Development withMozilla od N. McFarlanea, uvest na pravou mıru informace, ktere nejsou platne pro jadrobehoveho prostredı XULRunner v.1.8. a zaroven upozornit vyvojare na chyby, ktere existujıve stavajıcı implementaci jadra platformy. Tato diplomova prace zaroven obsahuje kapitolyv poradı, v jakem se obvykle vytvarı aplikace – programator je seznamen s vytvarenımuzivatelskeho rozhranı v jazyce XUL a jeho moznostmi, dale je proveden objektove orien-tovanymi principy dostupnych v jazyce JavaScript, jenz je hlavnı programovacı jazyk nadvrstvou XPCOM. O teto vrstve, jenz oddeluje jadro platformy od prostoru, ve kterem sepohybuje vyvojar, jsou uvedeny dulezite informace a dale se zde muzeme seznamit s prob-lematikou vyvoje vlastnıch komponent. Nechybı ani vysvetlenı ukladanı znalostı a dota-zovanı v jazyce RDF/XML. Vetsı cast prace je venovana ladenı aplikacı, jenz je ponekudkomplikovanejsı nez u jinych kompilovanych jazyku a platforem. Poslednı kapitola teto castiuvadı moznosti distribuce hotovych aplikacı a zpusoby jejich provozu.

Zıskane znalosti byly nasledne vyuzity prakticky pri vytvarenı volne siritelneho mul-tiplatformnıho nastroje zvaneho DocWatcher, jenz vyuzıva ke svemu fungovanı aplikacnıplatformu Mozilla. Cılem kapitoly zabyvajıcı se touto aplikacı je uvest dalsı konretnejsıobecne platne informace a nabıdnout prıklad prakticke implementace. Vzhledem k faktu,ze byl o tuto aplikaci projeven zajem z rad dalsıch uzivatelu, bude jejı vyvoj pokracovatdale, jen se presune na server http://mozdev.org nebo https://addons.mozilla.org.

Dalsı vyvoj se bude snazit vyresit problem s filtrovanım dle DOM elementu, ktery jenynı nefunkcnı z duvodu nedostatecne podpory ze strany platformy a pridanı filtrovanıbinarnıch souboru. Uzivatele by urcite take privıtali barevne odlisenı zmen mezi ulozenymiverzemi dokumentu, pokrocilejsı metody prihlasovanı se na server a opetovne odhlasenı,

53

http://mozdev.org

https://addons.mozilla.org

testovanı celych adresarovych struktur, RSS, ... Pozadovanych vlastnostnı je urcite hodnea DocWatcher by se jednou mohl kvalitou a funkcemi prıblizit spickam, jako je WebSite-Watcher. Nespornou vyhodu ma vsak DocWatcher jiz nynı – je to prvnı aplikace tohotozamerenı, ktera funguje v operacnıch systemech Windows, Linux, Mac OS X a dalsıch, cozpro uzivatele znamena stejne nastavenı doma, ve skole i v praci.

Pouzitı tohoto nastroje jiz zalezı na predstavivosti a potrebach uzivatele, avsak dıkytoho, ze svet kolem nas je velmi dynamicky a menı se kazdym okamzikem, muzeme s jehopomocı pohodlneji sledovat vydanı novych clanku na tema, ktere nas zajıma, muze nasinformovat o vydanı nove verze softwaroveho produktu, nebo jen proste s jeho pomocınezmeskame oblıbeny obed v jıdelne s on-line jıdelnım lıstkem.

54

Literatura

[1] McFarlane, N.: Rapid Application Development with Mozilla. P T R Prentice-Hall,2003. ISBN 0-13-142343-6http://www.informit.com/content/downloads/perens/0131423436 pdf.zip.

[2] Turner, D., Oeschger, I.: Creating XPCOM Components. Brownhen Publishing,2003. http://www.mozilla.org/projects/xpcom/book/cxc/.

[3] WWW stranky. Best web site monitoring tool.http://www.donationcoder.com/Reviews/Archive/WebWatchers/index.html.

[4] WWW stranky. Chrome Registration.http://developer.mozilla.org/en/docs/chrome.manifest.

[5] WWW stranky. Core JavaScript 1.5 Guide:Inheritance.http://developer.mozilla.org/en/docs/Core JavaScript 1.5 Guide:Inheritance.

[6] WWW stranky. Core JavaScript 1.5 Guide:Operators:Special Operators.http://developer.mozilla.org/en/docs/Core JavaScript 1.5 Guide:Operators:Special Operators.

[7] WWW stranky. Extension Versioning, Update and Compatibility.http://developer.mozilla.org/en/docs/Extension Versioning%2C Update and Compatibility.

[8] WWW stranky. File-naming convention for XUL toolkit applications.https://bugzilla.mozilla.org/attachment.cgi?id=157639&action=view.

[9] WWW stranky. Find xpidl.exe in Gecko SDK for compiling IDL files.http://mozilla-firefox-extension-dev.blogspot.com/2004/11/find-xpidlexe-in-gecko-sdk-for.html.

[10] WWW stranky. Gecko SDK. http://developer.mozilla.org/en/docs/Gecko SDK.

[11] WWW stranky. How to Build an XPCOM Component in Javascript.http://developer.mozilla.org/en/docs/How to Build an XPCOM Component in Javascript.

[12] WWW stranky. IDL Author’s Guide – Rules and Syntax.http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/rules.html.

[13] WWW stranky. Implementing XPCOM components in JavaScript.http://kb.mozillazine.org/Implementing XPCOM components in JavaScript.

55

[14] WWW stranky. Install Manifests.http://developer.mozilla.org/en/docs/Install Manifests.

[15] WWW stranky. JavaScript XPCOM Components Status – Draft 2.http://www.mozilla.org/scriptable/js-components-status.html.

[16] WWW stranky. Mozilla FAQ.http://mozilla.gunnars.net/mozfaq general.html.

[17] WWW stranky. Mozilla Source Code (HTTP/FTP).http://developer.mozilla.org/en/docs/Download Mozilla Source Code.

[18] WWW stranky. New in JavaScript 1.7.http://developer.mozilla.org/en/docs/New in JavaScript 1.7.

[19] WWW stranky. Resource Description Framework.http://en.wikipedia.org/wiki/Resource Description Framework.

[20] WWW stranky. Resource Description Framework (RDF). http://www.w3.org/RDF/.

[21] WWW stranky. Setting up extension development environment.http://kb.mozillazine.org/Setting up extension development environment.

[22] WWW stranky. Structure of an Installable Bundle.http://developer.mozilla.org/en/docs/Bundles.

[23] WWW stranky. Style Properties.http://xulplanet.com/references/elemref/ref StyleProperties.html.

[24] WWW stranky. Styling a Tree.http://www.xulplanet.com/tutorials/xultu/treestyle.html.

[25] WWW stranky. The GUI Toolkit, Framework Page.http://www.free-soft.org/guitool/.

[26] WWW stranky. The Life Of An HTML HTTP Request.http://www.mozilla.org/docs/url load.html.

[27] WWW stranky. The Prototype.http://www.debreuil.com/docs/ch01 Prototype.htm.

[28] WWW stranky. The Unicode Character Code Charts By Script.http://www.unicode.org/charts/.

[29] WWW stranky. Using XPCOM in JavaScript without leaking.http://www.mozilla.org/scriptable/avoiding-leaks.html.

[30] WWW stranky. Valid Application Versions.https://addons.mozilla.org/en-US/firefox/pages/appversions.

[31] WWW stranky. Venkman Introduction.http://developer.mozilla.org/en/docs/Venkman Introduction.

[32] WWW stranky. Versions of Gecko.http://developer.mozilla.org/en/docs/Gecko.

56

[33] WWW stranky. WebSite-Watcher features. http://www.aignes.com/features.htm.

[34] WWW stranky. What Is RDF. http://www.xml.com/pub/a/2001/01/24/rdf.html.

[35] WWW stranky. XPCNativeWrapper.http://developer.mozilla.org/en/docs/XPCNativeWrapper.

[36] WWW stranky. XPIDL. http://developer.mozilla.org/en/docs/XPIDL.

[37] WWW stranky. XUL Planet. http://xulplanet.com/.

[38] WWW stranky. XUL Tag Implementation.http://wiki.mozilla.org/XUL:XUL Tag Implementation.

[39] WWW stranky. XULRunner.http://developer.mozilla.org/en/docs/XULRunner.

57