MASARYKOVA UNIVERZITA

FAKULTA INFORMATIKY

}w���������� ������������� !"#$%&'()+,-./012345<yA|Integrace slovníku do prostredí

platformy NetBeans

BAKALÁRSKÁ PRÁCE

Tomáš Kyjovský

Brno, 2006

Prohlášení

Prohlašuji, že tato bakalárská práce je mým puvodním autorským dílem, které jsem vypra-coval samostatne. Všechny zdroje, prameny a literaturu, které jsem pri vypracování použí-val nebo z nich cerpal, v práci rádne cituji s uvedením úplného odkazu na príslušný zdroj.

Vedoucí práce: Ing. Petr Adámek

ii

Shrnutí

Úcelem práce je vytvorení modulu pro platformu NetBeans, které dodají podporu pro prácise slovníky do autorského systému projektu ELSW. Úvodní kapitola je venována strucnémupopisu a typizaci slovníku. Kapitola druhá predstavuje základní koncepty platformy Net-Beans. Tretí kapitola popisuje vývoj hlavního modulu, který žajišt’uje správu slovníku adefinuje jednoduché API pro rozširující moduly. Ve ctvrté kapitole je predvedena imple-mentace konkrétního rozširujícího modulu – modulu pro slovníky, dostupné pres protokolDICT. Záverem jsou zhodnoceny dosažené výsledky.

iii

Klícová slova

slovník, korpus, integrace, NetBeans, platforma NetBeans, modul, Java, DICT, DictionaryServer Protocol, e-learning

iv

Obsah

1 Úvod: Slovníky a korpusy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1 Slovníky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Typy slovníku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Prekladové slovníky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Specializované slovníky . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.3 Znakové slovníky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.4 Datové slovníky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.5 Glosáre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Korpusy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Funkce slovníku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Platforma NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Jádro a Open API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Modularita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 System Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Mapování souboru na Java objekty . . . . . . . . . . . . . . . . . . . . . 62.3.2 Modulové vrstvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Tvorba základního modulu a NetBeans API . . . . . . . . . . . . . . . . . . . . . . 83.1 Návrh modulu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Jádro rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Java BeansTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Trída Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Filesystems API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.1 Bežné operace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Loaders API a datové objekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4.1 Dilema c. 1: Centralizace . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.2 Datový objekt pro slovníky . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.3 Datový objekt pro definice . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.4 Typy souboru a NetBeans IDE . . . . . . . . . . . . . . . . . . . . . . . 17

3.5 Nodes API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.1 Typy uzlu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.2 Dilema c. 2: BeanNode vs. DataNode . . . . . . . . . . . . . . . . . . . 183.5.3 Uzly základního modulu . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.6 Actions API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6.1 Akce hlavního modulu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.7 Explorer API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7.1 Explorer View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7.2 Property Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.8 Window System API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.8.1 Komponenta TopComponent . . . . . . . . . . . . . . . . . . . . . . . . 223.8.2 Módy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

v

3.8.3 Skupiny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.8.4 Uživatelské rozhraní modulu . . . . . . . . . . . . . . . . . . . . . . . . 24

3.9 Options Settings API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Tvora modulu pro slovníky dostupné pres protokol DICT . . . . . . . . . . . . . 26

4.1 Protokol DICT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.1.1 Seznam príkazu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Jádro rozširujícího modulu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Nodes API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Customizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Options Settings API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Záver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Rejstrík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A Seznam DICT serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

vi

Predmluva

Tato práce je soucástí projektu Open Platform, což je projekt zamerený na vytvorení radyuniverzálních modulu pro platformu NetBeans. Projekt vznikl primárne jako základní plat-forma pro tvorbu autorských systému v projektu E-learning v kontextu sémantického webu(ELSW).

Hlavním cílem práce je integrovat do autorského systému možnost práce se slovníkya korpusy – poskytnout autorskému systému základní modul s univerzálním rozhranímpro prístup ke slovníkum a k nemu príslušné uživatelské rozhraní. Uživateli by mela býtnabídnuta možnost jednoduché správy slovníku: pridávání, odebírání, úprava jejich vlast-ností apod. Vlastní vyhledávání by v aplikaci melo být dostupné behem editace libovolnéhotextového dokumentu.

Zvláštní duraz je kladen na univerzalitu základního API, která zarucí snadnou rozširi-telnost aplikace o další typy slovníku. Soucástí práce je proto i jednoduchý prototyp rozši-rujícího modulu, na kterém jsou možnosti základního rozhraní predvedeny.

Zdrojové kódy, spustitelnou aplikaci, i text této práce v ruzných formátech, lze nalézt napriloženém CD.

1

Kapitola 1

Úvod: Slovníky a korpusy

Aby bylo možné vytvorit použitelné rozhraní pro práci se slovníky, je vhodné o nich znátalespon základní fakta.

1.1 Slovníky

Podle obecné definice je slovník seznam slov a jejich definic. Slova bývají vetšinou z neja-kého prirozeného jazyka a ve slovníku bývají serazena podle zvyklostí príslušného jazyka1.V mnoha jazycích existují slova ve více ruzných podobách, nicméne ve slovnících se vetši-nou objevují pouze v tzv. lemma podobe2. Mnoho slovníku uvádí informace o výslovnosti,informace o gramatice, odvozená slova, historii a etymologii slov, príklady použití, nebo ilu-strace, apod. Slovníky se nejcasteji vyskytují v knižní podobe, nicméne pro úcely této prácejsou duležitejší slovníky dostupné v podobe elektronické. [7]

1.2 Typy slovníku

Slovníky lze rozclenit do nekolika základních kategorií.

1.2.1 Prekladové slovníky

Prekladové nebo také dvoujazycné ci vícejazycné slovníky slouží k prekladu slov z jed-noho jazyka do jiného (resp. do jiných). Napr. cesko-anglický slovník, anglicko-japonský,rusko-ceský atp. Casto obsahují související informace o výslovnosti, slovních tvarech, syno-nymech, apod.

1. Dnešní slovníky pro jazyky s abecedním ci slabicným písmem radí slova abecedním, nebo nejakým prí-slušným fonetickým razením. Slova a znaky v jazycích s ideografickými písmy jsou razeny podle složitejšíchpravidel, protože pro ne neexistují jednoduchá lineární usporádání. Napr. cínské ideogramy se radí primárnepodle tzv. korene a v rámci korene se dále radí vzestupne podle poctu tahu.2. Slovo lemma v lingvistice oznacuje základní tvar slova, nazývaný též slovníkový. Napr. lemmatem ke slovukonskému je slovo konský, lemmatem ke slovu zvolavši je slovo zvolati, atp. Konvence pro výber lemmatu sev ruzných jazycích liší. V ceštine je lemmatem pro substantiva nominativ singuláru, pro adjektiva nominativ sin-guláru pozitivu mužského rodu, pro zájmena a císlovky obdobne jako pro substantiva a adjektiva, pro slovesaje lemmatem infinitiv, pro príslovce pozitiv, atd. [9]

2

1.2. TYPY SLOVNÍKU

1.2.2 Specializované slovníky

Specializované nebo též technické slovníky se zamerují na množinu jevu, omezenou jistýmoborem, nebo obory. Delí se do trí základních skupin: slovníky víceoborové, jednooborovéa podoborové.

Víceoborové slovníky pokrývají nekolik samostatných oboru, jako napr. bankovnictví,ekonomika, finance, pojištení a marketing. Hlavní problém tohoto typu slovníku je v tom,že se zabývají jedním, ci dvema obory extenzivne a ostatním oborum venují pomerne malýprostor. Kvuli prostorovému omezení jsou víceoborové slovníky casto minimalizující3.

Jednooborové slovníky se v kontrastu s víceoborovými zamerují pouze na jeden vybranýobor; jsou tudíž více specializované. Príklady takových slovníku jsou: právnický slovník,slovník ekonomie, nebo slovník stavitelství. Narozdíl od víceoborových slovníku slovníkyjednooborové mohou být snadno maximalizující4 a mohou se zamerit na ruzné jazykové afaktografické aspekty konkrétní oblasti.

Slovníky podoborové se soustred’ují na jednu nebo nekolik podoblastí urcitého oboru ajsou tudíž ze všech trí typu nejvíce specializované. Jsou vhodné pro extenzivní popis jevu.Príkladem muže být slovník obchodního práva, nebo slovník vojenského stavitelství.

1.2.3 Znakové slovníky

Forma znakového slovníku se vyvinula ve východní Asii. Slovník v této forme obsahujek jednotlivým znakum informace o zpusobu jejich kreslení (pocet a poradí tahu štetce), in-formace o výslovnosti a seznam slov, ve kterých je znak použit.

1.2.4 Datové slovníky

Datové sady a databáze, používané pri statistické analýze, bývají typicky doprovázeny se-znamem jmen použitých promenných, spolu s príslušnými popisy jejich významu, typu,jednotek, apod. Takový seznam se nazývá datový slovník.

1.2.5 Glosáre

Další variantou slovníku je glosár. Glosár je seznam technických termínu z úzce speciali-zovaného tématického okruhu. Definuje základní koncepty daného tématu a zacátecníkumslouží k orientaci. Jinými slovy: jedná se o seznam vysvetlivek. Glosár bývá obvykle publi-kován jako apendix k textu, který se danou oblastí zabývá. Zpravidla obsahuje slova, o kte-rých se predpokládá, že jsou pro ctenáre nová, a slova málo známá. Tzv. jádrový glosár5

3. Pozn.: Volný preklad z anglického názvu „minimizing dictionary“. Minimalizující slovník je takový, kterýse snaží podat minimální množinu výrazu, relevantních k jeho tématu ci oboru. Príkladem takového slovníkuje slovník 2000 nejfrekventovanejších anglických slov.4. Pozn.: Volný preklad z anglického názvu „maximizing dictionary“. Maximalizující slovník se pokouší zahr-nout co možná nejvíce slov ze svého oboru. Príkladem takového slovníku je Oxford English Dictionary.5. z anglického core glossary

3

1.3. KORPUSY

má blízko k pojmu minimální ontologie, což je ontologie, která obsahuje základní výchozíkoncepty, potrebné pro definici konceptu dalších. [8]

1.3 Korpusy

Textový korpus je rozsáhlá a strukturovaná množina textu v jednom nebo více jazycích,dnes už prevážne uchováných a zpracovávaných elektronicky. Korpusy jsou hlavním zdro-jem znalostí v korpusové lingvistice. Analýza a zpracování korpusu jsou rovnež duležitýmipostupy pri rozeznávání reci a strojovém prekladu, kde se používají k vytvárení zkrytýchMarkovových modelu6. Textové korpusy jsou také využívány pri studiu historických doku-mentu a luštení starovekých skriptu. [6]

1.4 Funkce slovníku

Z predchozího textu je zrejmé, že slovníku existuje celá rada, pricemž se liší jak úcelem,tak formou. Jejich hlavní funkce však zustává spolecná, a tou je vyhledávání definic. Každýslovník své definice prezentuje vlastním zpusobem a formou tak, aby co nejlépe plnil svujúcel. Slovníky také casto plní ruzné speciální funkce. Toto byl jeden z hlavních problému,které bylo pri tvorbe jednotného rozhraní potreba vyrešit.

6. Zkrytý Markovuv model (z angl. hidden Markov model, zkrácene HMM) je statistický model, ve kterém seo modelovaném systému predpokládá, že jde o tzv. Markovuv proces s neznámými parametry. Úcelem je z po-zorovatelných parametru odvodit parametry zkryté, a ty potom využít pri další analýze, napr. pri rozeznávánívzoru.

4

Kapitola 2

Platforma NetBeans

Platforma NetBeans je platformou pro vývoj modulárních Java aplikací. Umožnuje vyvíjetsoftware v podobe modulu. Modul pro NetBeans je Java archiv, který obsahuje trídy, pracu-jící s NetBeans Open API, a soubor manifest, který ho umožnuje identifikovat jako modul.Aplikace mohou být jednoduše rozšíreny pridáváním dalších modulu.

NetBeans API podstatne zjednodušují a urychlují vývoj, protože obsahují služby, spo-lecné pro vetšinu aplikací. Dovolují tak vývojári soustredit se na vlastní logiku aplikace.NetBeans API obstrávají správu uživatelského rozhraní a uživatelkých nastavení, práci sesoubory a datovými objekty, správu oken a další cinnosti.

Historie NetBeans sahá do roku 1997 k projektu Xelfi studentu MFF UK v Praze. Poz-deji byla kolem projektu založena spolecnost, která vyvíjela komercní verze NetBeans IDE.V roce 1999 spolecnost koupila firma Sun Microsystems, která se o rok pozdeji rozhodlaposkytovat zdrojové kódy jako open source.

NetBeans IDE je integrované vývojové prostredí, napsané v jazyce Java, a postavené naplatforme NetBeans. IDE od verze 5.0 umožnuje vývoj všech bežných typu Java aplikací. Po-skytuje systém projektu, založený na nástroji Ant, nástroje pro správu verzí, refraktorovánía mnoho dalších užitecností. [10]

2.1 Jádro a Open API

Platforma NetBeans sestává ze dvou základních soucástí: jádra a množiny rozhraní OpenAPI1. Tyto jsou umísteny v Java balíccích org.netbeans.core.*, resp. org.openide.*. Jádroimplementuje mnoho rozhraní deklarovaných v Open API a zajišt’uje vlastní beh NetBe-ansovské aplikace. Open API nabízejí sadu nástroju, kterých mužou využít autori samostat-ných modulu. Funkcní modul existuje v souboru JAR (Java ARchiv), který obsahuje Javatrídy a soubor manifestu, kterým je modul popsán.

Zdrojové kódy NetBeans jsou distribuovány pod licencí Sun Public License. Tato licencedovoluje programátorum použít NetBeans k vytvárení jak nekomercního, tak i komercníhosoftware, vytváret a distribuovat moduly a aplikace, založené na NetBeans, a používat sou-cásti NetBeans ve vlastních aplikacích.

Všechny zdrojové kódy NetBeans jsou volne dostupné na webovém portálu netbeans.org.

1. Pozn.: API je anglický akronym pro Application Programming Interface, volne preloženo: aplikacní progra-movací rozhraní.

5

2.2. MODULARITA

[3]

2.2 Modularita

Jedním ze základních konceptu NetBeans je modularita. Funkcionalita by mela být delitelnáa melo by být možné ji jednoduše pridávat a odebírat. Instalace, správa a odinstalace mo-dulu je zajišt’ována pomocí Modules API.

Každý modul muže nabízet své vlastní API, a tak svou funkcionalitu zprístupnit modu-lum ostatním. Napríklad XML moduly nabízejí základní podporu pro práci s XML soubory.Této mohou využít moduly, zamerené na nejaké specifické rysy XML. Pro tyto prípady jemožné deklarovat mezimodulové závislosti. Jádro aplikace NetBeans zabezpecuje integritutechto závislostí tím, že nedovolí nainstalovat modul, pokud nejsou prítomny moduly, najejichž funkcionalite je tento závislý, a rovnež jej nedovolí prímo odebrat, pokud nejaké dalšímoduly zavisí na nem. [3]

2.3 System Filesystem

Pri vývoji rozsáhlejších rozširitelných aplikací vzniká potreba trídit prezentovaný obsah afunkcionalitu do hierarchické struktury. V aplikaci NetBeans existuje pro tento úcel tzv. Sys-tem Filesystem, virtuální souborový systém pro ukládání konfiguracních údaju. Jedná seo jakési verejne dostupné uložište, kterého moduly mohou využívat.

Struktura System Filesystemu je popsána a reprezentována XML dokumentem, jež vy-hovuje speciálnímu DTD2, filesystem (http://www.netbeans.org/dtds/filesystem-1_1.dtd).[3]

2.3.1 Mapování souboru na Java objekty

NetBeans definují semantiku pro mapování souboru na instance Java objektu. V souboro-vém systému jsou uloženy soubory se jmény jako org-myorg-MyClass.instance, které mo-hou být pomocí Loaders API prevedeny na instance dané trídy.

Tento zpusob jednak umožnuje modulum registrovat si v souborovém systému své ob-jekty, jednak umožnuje registraci objektu bez nutnosti jejich nactení virtuálním Java stro-jem3. Objekty jsou nacteny až v dobe, kdy je existence jejich instancí explicitne vyžádána,címž se šetrí pamet’. Pro snadné vyhledávání objektu registrovaných ve speciálních slož-kách System Filesystemu slouží pomucka Lookup.

V systémovém souborovém systému vypadá registrace objektu obdobne, jako na násle-dujícím príkladu.

Výsledným efektem je vytvorení instance trídy MyAction, která poskytne ikonku a jméno,jež se zobrazí v menu, a kód, který se provede po spuštení akce uživatelem.

2. DTD je akronym pro anglický výraz Document Type Definition.3. z aglického Java Virtual Machine, zkrácene JVM

6

2.3. SYSTEM FILESYSTEM

<filesystem><folder name="Menu">

<folder name="View"><file name="org-myorg-MyAction.instance"/>

</folder></folder>

</filesystem>

Príklad 2.3.1: Pridání nové instance do souborového systému

2.3.2 Modulové vrstvy

Primární zpusob, kterým moduly pridávají svoji funkcionalitu do aplikace, je pomocí výšezmíneného virtuálního systémového systému souboru. Duležitou vlastností tohoto systémutotiž je, že se skládá z vrstev, pricemž každý modul má svou vlastní vrstvu, ve které si regis-truje objekty. Tato vrstva je v podstate samostatný souborový systém, který je po spušteníspojen se systémovým. Je rovnež reprezentován XML dokumentem. Na tento dokument jeodkazováno ze souboru manifestu daného modulu.

7

Kapitola 3

Tvorba základního modulu a NetBeans API

V této kapitole je popsána tvorba základního modulu od návrhu až po implementaci. Abyctenár neznalý architektury ruzných NetBeans API byl s to modul pochopit, je kapitola dálerozclenena do sekcí podle jednotlivých API, kterých modul využívá. V každé sekci jsou shr-nuty základní vlastnosti a úcel daného API, a vysvetlen zpusob, jakým modul toto API po-užívá. Výjimkami jsou dve úvodní sekce, z nichž první se zabývá návrhem modulu, druhájeho jádrem, které je postaveno na architekture Java BeansTM a žádných speciálních NetBe-ans API nevyužívá.

Pri programování modulu jsem vycházel ze seznamu NetBeans API na webových strán-kách NetBeans [1]. Informace jsem cerpal také z tutoriálu, dostupných na témže webserveru[5].

3.1 Návrh modulu

Pri navrhování modulu jsem narazil na problém, jak sjednotit pomerne ruznorodou funkci-onalitu slovníku tak, aby byla jednak umožnena co nejsnadnejší tvorba dalších rozširujícíchmodulu, jednak aby tato funkcionalita byla uživateli poskytnuta v jednotné a použitelnépodobe. Pritom jsem se snažil pro tyto úcely využít všech vhodných NetBeans API.

Jak jsem nastínil v úvodní kapitole, slovníku existuje celá rada. Ruzní se jak úcelem, takformou. Duležitým cílem, pri navrhování tohoto modulu, bylo abstrahovat jejich spolecnévlastnosti. Základním spolecným rysem všech slovníku je vyhledávání a definování pojmu.Minimálne tyto funkce musí podporovat každý slovník. Mnoho slovníku ale nabízí i jinéfunkce, napr. hledání synonym, hypernym, okolí slov, apod.

Základem modulu je tzv. Java Bean komponenta Dictionary, která predstavuje v aplikacipráve jeden slovník, se kterým uživatel pracuje, je nositelem jeho vlastností, a je prostred-níkem mezi konkrétním zdrojem slovíku (napr. slovníkovým serverem, nebo souborem) aaplikací. Každý rozširující modul definuje vlastní podtrídu trídy Dictionary, která obsahujedalší specifická nastavení, potrebná pro komunikaci s daným typem slovníku. Rozširujícítrída rovnež zajišt’uje vlastní komunikaci. Samotná trída Dictionary neposkytuje funkciona-litu pro žádný konkrétní slovník.

V následující sekci je strucne popsána architektura Java BeansTM, která je výchozím kon-ceptem NetBeans, a které je využito i pri tvorbe tohoto modulu (zejména jádra a trídy Dicti-onary). Java Beans mimo jiné nabízí možnost trvalého uložení stavu Java Bean komponent.Této možnosti je využito ve spojitosti s Filesystems API k perzistentnímu uložení jednotli-

8

3.2. JÁDRO ROZHRANÍ

vých slovníku. Slovníky jsou ukládány do zvláštní složky v systémovém systému souborujako samostatné soubory. Zde jsou ukládány také soubory s vyhledanými definicemi.

O rozpoznávání souboru a jejich logickou reprezentaci v programovacím prostredí sestará Loaders (Datasystems) API.

Nodes API ve spolupráci s Explorer API umožnuje uživateli pracovat s jednotlivýmislovníky a jejich vlastnostmi. Jednotlivé slovníky jsou prezentovány jako tzv. uzly, což jsouhierarchicky usporádané vizuální objekty. Jejich vlastnosti je možné spravovat standardnepomocí tzv. PorpertySheet komponent1, nebo pomocí nastavené tzv. Customizer kompo-nenty2.

Actions API poskytuje uživatelskému rozhraní jednotlivé spustitelné akce, které mohoubýt spojeny s uzly.

Hierarchie uzlu je zobrazována komponentami Explorer view, jež bývají zpravidla obsa-ženy v tzv. TopComponent komponentách. TopComponent komponenty jsou soucástí Win-dow System API a predstavují jednotlivá podokna aplikace, se kterými uživatel pracuje,muže je premist’ovat, apod.

Poslední sekce se zabývá uložením ruzných nastavení pro modul. Vytvorení vlastní ka-tegorie v dialogu nastavení je pomerne snadné, protože o velkou cást práce se postará Net-Beans IDE automaticky. Vlastní funkcionalitu poskytuje Options Settings API.

3.2 Jádro rozhraní

3.2.1 Java BeansTM

Technologie Java BeansTM prináší do programovacího jazyka Java komponentovou archi-tekturu. Java Beans byly puvodne zamýšleny jako opetovne použitelné vizuální kompo-nenty pro stavbu uživatelských rozhraní bežných aplikací, nicméne dnes jsou používányi v prostredích jako JSP3 a EJB4. Trídy, které souvisí s vývojem Java Bean komponent, senachází v balícku java.beans. [2]

Komponenty Java Bean. Komponenta Java Bean je objekt, který poskytuje okolnímuprostredí urcité své vlastnosti, metody a události. Standardní zpusob, jak v programu zjis-tit informace o techto vlastnostech, metodách a událostech, je pomocí trídy Introspector,která danou koponentu analyzuje. Pokud si autor ke své komponente preje dodat nejakédalší informace, vytvorí k ní popisnou trídu, implementující rozhraní BeanInfo, nejcastejirozšírením trídy SimpleBeanInfo. Jméno príslušné BeanInfo trídy by melo být stejné, jakou popisované Java Bean komponenty, pouze s pripojeným „BeanInfo“5. Pokud Introspec-tor najde k dané komponente príslušné BeanInfo, pridá ho do své analýzy. V prípade, žeBeanInfo nenalezne, prozkoumá jednotlivé atributy a metody dané trídy pomocí Java Re-

1. PropertySheet je standardní komponenta pro úpravu vlastností uzlu. Je soucástí Explorer API.2. Customizer je vizuální komponenta pro úpravu vlastností Java Bean objektu, ke kterému je prirazena.3. JSP – anglický akronym pro Java Server Pages4. EJB – anglický akronym pro Enterprise Java Beans5. Tj. napr. pro trídu Dictionary bude název pro BeanInfo DictionaryBeanInfo.

9

3.2. JÁDRO ROZHRANÍ

flection API6. Jejich jména musí vyhovovat standardnímu návrhovému vzoru. Napr. proatribut String name musí ve tríde komponenty existovat get/set metody String getName()a void setName(String).

BeanInfo. Popisná trída, implementující rozhraní BeanInfo obsahuje množinu tzv. Fea-tureDescriptoru. FeatureDesctriptor je výchozí trídou pro PropertyDescriptor, MethodDe-scriptor, EventSetDescriptor, BeanDescriptor a ParameterDescriptor. Poskytuje základní in-formace pro danou vlastnost, jako jméno, zobrazované jméno, krátky popis, kategorizaceapod. BeanDescriptor obsahuje informace o tríde Java Bean komponenty a umožnuje na-stavit tzv. Customizer, což je vizuální komponenta urcená pro editaci atributu. PropertyDe-scriptor popisuje konkrétní atribut. Umožnuje nastavit prístupová práva (jen pro ctení, jenpro zápis, pro ctení i pro zápis), a tzv. PropertyEditor, pomocí kterého lze provádet editaciatributu netradicních (složitejších) typu.

NetBeans IDE poskytuje množství nástroju pro práci s Java Bean komponentami, jakvizuálními, tak nevizuálními. Na tomto míste je stojí za zmínku pomucka Bean Info Editor,jenž podstatne ulehcuje a urychluje práci pri vytvárení a editaci BeanInfo tríd. Je dostupnýz vyskakovací nabídky uzlu Bean Patterns dané trídy.

Perzistence. Duležitou vlastností Java Bean komponent je možnost trvalého uloženíjejich stavu. Mely by proto implementovat rozhraní Serializable. Balík java.beans nabízív tomto ohledu jakousi alternativu k bežnému zpusobu serializace objektu, a to možnostuložit objekt ve forme XML dokumentu. Tento zpusob uložení byl puvodne navržen proukládání stavu vizuálních komponent, nicméne lze jej použít i pro uložení jiných objektu.Samotný prevod do XML formy zabezpecuje trída XMLEncoder, ctení potom trída XML-Decoder. Objekt je v XML uložen ve forme metod a parametru, které se pri dekódováníprovedou a inicializují tak stav nactené instance.

XMLEncoder e =new XMLEncoder(

new BufferedOutputStream(new FileOutputStream("Test.xml")));

e.writeObject(new JButton("Hello, world!"));e.close();

Príklad 3.2.1: Použití trídy XMLEncoder

Výsledek metody writeObject je videt na následjícím príkladu.

3.2.2 Trída Dictionary

Jak bylo zmíneno v úvodní sekci kapitoly, trída Dictionary, neboli trída, reprezentující slov-ník, je Java Bean komponentou. Obsahuje vlastnosti, jež jsou spolecné všem typum slovníku– zejména ty, které ovlivnují chování a vzhled komponenty v uživatelském rozhraní – jménoa typ souboru pro definice.

6. Java Reflection API slouží k získávání informací o atributech a metodách tríd za behu programu.

10

3.2. JÁDRO ROZHRANÍ

<?xml version="1.0" encoding="UTF-8"?><java version="1.0" class="java.beans.XMLDecoder">

<object class="javax.swing.JButton"><void property="label">

<string>Hello, world!</string></void>

</object></java>

Príklad 3.2.2: Výsledný soubor trídy XMLEncoder

Definice. Vzhledem k velkému množství ruzných slovníku a rozmanitosti forem, jakýmiprezentují definované pojmy, existuje u každého slovníku možnost nastavit typ souboru, dokterých se ukládají vyhledané definice. Každý typ slovníku, resp. trída, která ho reprezen-tuje, muže nastavit výchozí typ souboru definic. Základní modul zavádí pro definice jedno-duchý typ souboru text/x-definition, s príponou „def“. Jedná se o jednoduchý, ciste textovýsoubor, editovatelný v základním textovém editoru. Více informací o vytvárení a registracivlastních typu souboru je v sekci o Loaders API. Tímto zpusobem je prípadným autorumrozširujících modulu ponechána možnost bud’ nastavit pro svuj typ slovníku nejaký obecneznámý formát, napr. HTML, anebo dodat svuj vlastní speciální typ, napr. s barevným zvý-raznením slov pro definice z WordNetu, nebo typ pro formát wiki, atp.

PropertyChangeSupport. Jelikož Dictionary poskytuje vlastnosti, které lze v prostredíaplikace upravovat (což je zejména z duvodu perzistence potreba hlídat), vlastní tato trídainstanci trídy PropertyChangeSupport, která v prípade zmeny nekteré z vlastností, obe-známí všechny instance PropertyChangeListener, jež jsou u ní zaregistrovány. Všechny setmetody trídy Dictionary by mely oznamovat zmeny príslušné vlastnosti pomocí metodyfirePropertyChange trídy PropertyChangeSupport. Tento požadavek se týká i tríd, rozširu-jících trídu Dictionary.

public void setName(String name) {String oldName = this.name;this.name = name;getPropertyChangeSupport()

.firePropertyChange("name", oldName, name);}

Príklad 3.2.3: Set metoda pro vlastnost name

Základní funkcionalita. Trída Dictionary zajišt’uje základní funkci slovníku – vyhledá-vání definic. Tato funkce je rozdelena do dvou nezávislých metod: match a define.

public List<String> match(String expression);public String define(String expression);

11

3.2. JÁDRO ROZHRANÍ

Metoda match vrací seznam slov, jež vyhovují zadanému výrazu expression. Pokud ve slov-níku vstupní výraz nalezen není, metoda vrátí prázdný seznam. Metoda define zajistí zís-kání vlastní definice. Autori rozširujících modulu musí minimálne tyto dve metody ve svépodtríde trídy Dictionary predefinovat tak, aby zajišt’ovaly adekvátní funkcionalitu prodaný typ slovníku. Trída Dictionary totiž nereprezentuje žádný konkrétní typ slovníku, anemá tedy v cem vyhledávat.

Dodatecná funkcionalita. Další problém, který bylo treba vyrešit, je podpora pro doda-tecné funkce elektronických slovníku. Po dukladném zvážení charakteristiky techto funkcíjsem dospel k jejich jednotné charakteristice – pro vstupní výraz všechny vracejí seznampojmu, jejichž definice jsou obsaženy ve slovníku. Tedy typove jsou shodné s metodoumatch 7. Tímto zpusobem se dají jednoduše vyjádrit napr. funkce prefixového, suffixového,regulárního ci libovolného jiného vyhledávání, i vyhledání synonym, antonym, hypernym,aj., a funkce pro ruzné další vztahy. Takto lze prípadne definovat i funkci pro seznam kapitoltextových cástí slovníku, pokud nejaké má8.

Zpusob, který jsem zvolil pro implementaci techto dodatecných funkcí, využívá LookupAPI. Lookup je soucástí Utilities API a je rovnež pomerne duležitou soucástí všech NetBe-ans aplikací. Jak bylo uvedeno v cásti o mapování souboru na Java objekty, Lookup se starámimo jiné o vyhledávání instancí tríd, registrovaných ruznými moduly. Aby trída Dicti-onary mohla jednoduše nabízet seznam funkcí pro svuj slovník, obsahuje vlastní instancitrídy Lookup a implementuje rozhraní Lookup.Provider, respektive implementuje jeho je-dinou metodu getLookup(). Do své instance Lookup si trída muže vkládat libovolné objekty.V tomto prípade si do nej vloží seznam funkcí. Funkce jsou reprezentovány vnorenou trídouDictionary.Function. Tato obsahuje metodu getFunctionResult(String) a umožnuje nastavitnázev, pod kterým bude funkce viditelná v uživatelském rozhraní. Autori rozširujících mo-dulu mohou trídu Dictionary.Function rozšírit o další vlastnosti. K snadnejšímu nastaveníseznamu funkcí slouží metoda Dictionary.setDictionaryFunctions(Dictionary.Function[]). Se-znam bývá zpravidla nastaven hned pri inicializaci instance slovníku, tzn. v konstruktoru,nicméne nic nebrání tomu, aby byl dodatecne menen. Je rovnež možné funkce generovatdynamicky na základe informací, uložených v Java Bean komponente, jako je to implemen-továno napr. v prípade slovníku DICT, kde se funkce generují na základe vyhledávacíchstrategií, podporovaných serverem.

Perzistence Posledním problémem, který bylo v souvislosti se trídou Dictionary nutnévyrešit, je perzistence – cili jak zarídit, aby seznam slovníku pretrval mezi jednotlivýmispušteními aplikace. Vzhledem k tomu, že Dictionary je Java Bean komponentou, lze ji jed-noduše uložit do souboru pomocí trídy Encoder, resp. XMLEncoder, jehož použití je vy-svetleno v sekci o Java Beans. Tady je vhodné podotknout, že trída Dictionary není v tétoaplikaci serializovaná standardním zpusobem, ale je ukládána externe – trídou, která ji ob-sahuje a naslouchá zmenám jejích vlastností. Duvod tohoto rešení bude vysvetlen a disku-tován v podkapitole o Loaders API (dilema c. 1).

7. Metoda match je ovšem narozdíl od rozširujících funkcí povinnou soucástí trídy Dictionary, jelikož je spo-lecná pro všechny typy slovníku. Z tohoto duvodu je ve tríde deklarována zvlášt’.8. Príkladem zvláštní textové cásti muže být napr. gramatická prírucka v prekladovém slovníku.

12

3.3. FILESYSTEMS API

3.3 Filesystems API

NetBeans interne používají koncept virtuálního souborového systému, jež byl strucne pred-staven v kapitole o platforme NetBeans. Rozhraní Filesystems API je používáno vyššímivrstvami NetBeans k provádení operací se soubory jako ctení, zápis, presuny, apod.

Prostrení NetBeans samo o sobe podporuje dva základní systémy souboru – lokální sou-borový systém, který umožnuje pracovat se soubory v souborovém sytému operacního sys-tému, a souborový systém JAR, který uživatelum dovoluje pripojit Java Archiv jako složku(pouze pro ctení). Autori modulu, které pro svou práci potrebují nejaký netradicní systém,mohou poskytnout jeho vlastní implementaci – napr. databázový systém souboru.

Filesystems API podporuje také zamykání souboru behem zapisovacích operací a odpo-slouchávání zmen stavu souboru.

Filesystems API se nestará o konkrétní obsah a typ souboru, ani o jejich vlastní použitív aplikaci. Z pohledu Filesystems API jsou soubory pouze datovými proudy. Funkcionalitatohoto API bývá obvykle využívána neprímo, pomocí Loaders API, které prezentuje obsahsouboru ve forme datových objektu a umožnuje jejich další zpracování v programu.

3.3.1 Bežné operace

Základní operace Filesystems API jsou stejné, jako v kterémkoli jiném systému pro prístupa práci se soubory. Základním kamenem API je trída FileObject, jenž obaluje funkcionalitujava.io.File. API navíc podporuje odposlech zmen stavu souboru, který v tradicních systé-mech podporován není.

Vyhledání. Vyhledávání souboru v systému je pomerne snadná záležitost. Standardnípostup vyhledání souboru podle jména je patrný z následujícího príkladu.

fileObject = FileUtil.toFileObject(new File("/some/path/to/file.txt"));

Výsledkem operace je instance trídy FileObject, se kterou je možné dále pracovat. Vyhle-dání souboru a složek v urcité složce ilustruje následující príklad.

FileObject children[]=folder.getChildren();

Vytvárení, mazání a prejmenovávání. Aby bylo možné tyto operace provádet, je nutnéuž mít k dispozici instanci nejakého FileObjectu. V prípade vytvárení musíme mít složku vekteré chceme soubor ci podsložku založit.

FileObject folder = ......FileObject newFile = folder.createData("newFileName", "xml");FileObject newFolder = folder.createFolder("newFolderName");

Prejmenování je rovnež velmi snadné. Provádí se pomocí metody rename (FileLock,String, String) trídy FileObject. Pred touto operací je ovšem nutné soubor zamknout a pooperaci opet odemknout. Mazání obstará metoda delete().

13

3.4. LOADERS API A DATOVÉ OBJEKTY

FileLock lock = null;try {

lock=newfile.lock();} catch (FileAlreadyLockedException e) {

return;}try {

newfile.rename(lock, "NewSrc", "java");} finally {

lock.releaseLock();}

Ctení a zápis. Vlastní ctení ze souboru a zápis do nej probíhá pomocí vstupního, resp.výstupního proudu. Ten lze získat pomocí getInputStream() trídy FileObject, resp. getOut-putStream(FileLock).

Repository. Repository je standardní prostredek pro prístup k systémovému systémusouboru, jež se využívá k ukládání konfguracních dat NetBeans aplikace. Objekty z tohotosystému souboru, aneb konfiguracní soubory, lze obdržet napr. následujícím zpusobem.

FileSystem sfs = Repository.getDefault().getDefaultFileSystem();FileObject menus = sfs.findResource("Menu");

3.4 Loaders API a datové objekty

Loaders API, nekdy také Datasystems API, slouží v NetBeans k práci s datovými objekty.Úcelem je abstrahovat složitejší logickou struturu z fyzických soubroru. V systému existujetzv. systémový Loader Pool, což je jakýsi registr pro objekty Data Loader. Tento LoaderPool pri nacítání souboru ze složky dokáže rozpoznat typy jednotlivých souboru tak, žese postupne ptá všech svých registrovaných Data Loader instancí, jestli daný soubor umínacíst. První Data Loader, který toto dokáže, vytvorí k danému souboru, nebo množinesouboru, príslušný datový objekt, se kterým je v aplikaci dále pracovat.

Je nekolik duvodu proc používat datové objekty místo prímého prístupu k souborum.S datovými objekty mohou být spojeny ruzné druhy chování a akcí ve forme tzv. cookies,napr. otevrení príslušného editoru. Tento datový prístup také umožnuje seskupovat vícesouboru do jednoho datového objektu. Je možné rozpoznávat skupinové vzory, podobnejako na tomto príklade. Tímto zpusobem je také možné odfiltrovat soubory, které pro práciaplikace nemají žádný význam.

myform.javamyform.formmyform.classmyform$1.classmyform$2.class

Príslušný datový objekt k souboru lze vytvorit pomocí DataObject.find(FileObject), nicméneto ve spoute prípadu ani není potreba, protože systémový loader pool toto delá automaticky,vcetne prezentace uživateli jako tzv. Node (více viz. sekce o Nodes API).

14

3.4. LOADERS API A DATOVÉ OBJEKTY

3.4.1 Dilema c. 1: Centralizace

Pri navrhování datového objektu pro slovník jsem rešil pomerne obtížné dilema. Šlo o torozhodnout, zda budou všechny slovníky, nezávisle na typu, ukládány do jednoho typusouboru, anebo naopak, každý typ slovníku bude mít svuj vlastní typ souboru. Obe variantymají své výhody i nevýhody.

První varianta – mít centrálne jeden typ souboru pro všechny druhy slovníku – je po-merne výhodná pro autory rozširujících modulu, protože ti nemusí definovat speciální typsouboru a k nemu príslušný datový objekt a prezentacní vrstvu, a využijí služeb základníhomodulu, který se o vše postará. Nevýhodou tohoto rešení je, že si vynucuje netradicní zpu-sob serializace slovníkové Java Bean komponenty, který jsem již zmínil na konci kapitolyo jádru modulu. Je to zpusobeno tím, že DictionaryDataObject obsahuje Java Bean kompo-nentu Dictionary pouze jako Object, a ne jako trídu príslušnou k danému typu slovníku.Toto by ani nebylo technicky možné, vzhledem k tomu, že tyto rozširující trídy základnímodul nezná. Ukládání a nacítání stavu Java Bean tedy zabezpecuje DictionaryDataObject,který ji v sobe obsahuje jako atribut, pomocí trídy XMLEncoder. Další nevýhodou této vari-anty je nutnost ošetrit prípady, kdy se (napr. po odebrání rozširujícího modulu) konfiguracislovníku nacíst a vytvorit pro nej Java Bean komponentu.

Druhá varianta – mít v každém rozširujícím modulu definovaný speciální typ slovníkui s príslušnými datovými a prezentacními objekty – je výhodnejší zhlediska konzistenceaplikace a je o neco elegantnejší. Pri odebrání modulu napr. automaticky zmizí i jeho pre-zentacní vrstva pro datové objekty. Také by bylo možné uchovávat Java Bean v datovémobjektu jako instanci príslušné trídy, tudíž i použít bežnou metodu serializace. Tato variantaje ale pomerne nevýhodná a zatežující pro autory rozširujících modulu, protože ti nemohoujednoduše využít funkcionality hlavního modulu a musí se o mnoho vecí postarat sami.

Po úvaze jsem tedy nakonec zvolil implementaci varianty první, protože mi prišla cel-kove výhodnejší. Je ovšem možné, že v prubehu prípadného dalšího vývoje, modul v tétooblasti dozná urcité zmeny.

3.4.2 Datový objekt pro slovníky

DictionaryDataLoader. K tomu, aby NetBeans aplikace dokázala rozpoznat urcitý typ sou-boru v souborovém systému, je potreba pro nej definovat tzv. DataLoader. DataLoader jeodpovedný za rozpoznání souboru, ci v tomto prípade skupiny souboru, a za vytvorení da-tového objektu. DictionaryDataLoader – DataLoader pro rozpoznávání souboru se slovníkyje potomkem trídy MultiFileLoader, který dokáže rozeznat výše zmínené skupinové vzory.Vždy jeden ze skupiny souboru figuruje jako primární, zbylé soubory jsou sekundární. Dvadatové objekty jsou stejného typu, pokud mají stejný primární soubor.

DictionaryDataLoader rozpoznává skupiny dvou souboru. Primárním souborem je XMLdokument s príponou „xdict“ pro uložení konfigurace slovníku, sekundárním souborem jesložka, do které se ukládají vyhledané definice. Jméno složky je shodné se jménem primár-ního souboru, až na koncovku „-definitions“.

15

3.4. LOADERS API A DATOVÉ OBJEKTY

WordNet.xdictWordNet-definitions

Hlavní funkci trídy MultiFileLoader – vlastní rozpoznávání – plní metoda findPrimary-File. Tato k vstupní souboru vrátí príslušný primární soubor. Pokud vstupní soubor nepatrído rozeznávaného vzoru, metoda vrátí null. Metoda createMultiObject vytvorí datový ob-jekt, v tomto prípade DictionaryDataObject.

DictionaryDataLoader dále odpovídá za prirazení akcí k svému datovému objektu. Tytoakce jsou uvedeny v XML vrstve modulu ve složce Loaders/MIME-TYP/Actions. V našemprípade jsou ve složce Loaders/text/x-dictionary/Actions umísteny akce: Open, Cut, Copy,Rename, Delete, Clear history, Customize a Properties.

DictionaryDataObject. DictionaryDataObject je datový objekt, vytvorený trídou Dicti-onaryDataLoader. Je potomkem trídy MultiDataObject. Odpovídá za manipulaci s prísluš-nými soubory a složkami – zajišt’uje správné provádení operací jako presun, kopírování amazání.

Datový objekt slovníku v sobe obsahuje Java Bean komponentu Dictionary, resp. obsa-huje komponentu vždy pro nejaký konkrétní typ slovníku; stará se o její nactení ze souboru9

a o uložení pri každé zmene nejaké její vlastnosti. DictionaryDataObject proto implementujerozhraní PropertyChangeListener.

V prípade, že nactení probehne bez problému, je pomocí metody createNodeDelegatedatového objektu vytvoren príslušný DataNode, jenž je prostredkem pro vizuální prezen-taci tohoto objektu. Pokud se operace nactení nepodarí, znamená to, že je dokument bud’poškozen, anebo se nepodarilo najít trídu, která je v souboru uložena, napr. v dusledku ode-brání nekterého z rozširujících modulu. V takovém prípade je metodou createNodeDelegatevytvoren pouze tzv. AbstractNode10, kterému se nastaví príznak hidden, címž se tento pre-zentacní uzel zkryje.

DictionaryDataNode. DictionaryDataNode je potomkem trídy DataNode. Úcelem Da-taNode je prezentovat relevantní datový objekt uživateli a umožnit práci s ním – spouš-tet akce, presouvat objekt v hierarchii, apod. DataNode vychází z trídy AbstractNode, jejížvlastnosti jsou blíže popsány v cásti o Nodes API.

DictionaryDataNode behem své inicializace extrahuje z Java Bean komponenty v dato-vém objektu její vlastnosti, aby mohly být prezentovány a dále upravovány pomocí kom-ponenty PropertySheet. Pro tento úcel využívá metody BeanNode.computeProperties, kterédodá instanci Bean komponenty a k ní príslušné BeanInfo. DataNode si dále z Bean kompo-nenty zjistí specifickou ikonku a Customizer.

3.4.3 Datový objekt pro definice

Zpusob tvorby datových objektu pro definice je velmi podobný zpusobu u slovníku.

9. Pozn.: Nactení probehne pri vytvárení instance DictionaryDataObject, tzn. v jejím konstruktoru, pomocítrídy XMLDecoder. Pokud se nactení nezdarí, instace Java Bean komponenty slovníku dostane hodnotu null.10. Viz sekci o Nodes API.

16

3.5. NODES API

DefinitionDataLoader. Tento Loader je narozdíl od trídy DictionaryDataLoader tzv. Uni-FileLoader, což je podtrída MultiFileLoader, která rozpoznává práve jeden typ souboru. De-finitionDataLoader rozpoznává soubory s príponou „def“. Akce prirazené k objektu defi-nice jsou: Open, Delete, Rename, Properties 11.

DefinitionDataObject a DefinitionDataNode jsou jednoduchými rozšíreními tríd Data-Object, resp. DataNode.

3.4.4 Typy souboru a NetBeans IDE

NetBeans IDE 5.0 obsahuje nástroj, který podstatne urychlí tvorbu vlastních jednoduchýchtypu souboru. Základní šablony podle pokynu uživatele vytvorí a vyplní pruvodce12– vy-tvorí DataLoader, DataObject, DataNode a jednotlivé šablony a pridá do XML vrstvy prí-slušné akce.

3.5 Nodes API

Uzel, neboli Node, poskytuje vizuální reprezentaci pro vetšinu objektu v NetBeans. Mužebýt použit pro reprezentaci datového objektu, nebo muže být vytvoren nezávisle, pro ruznéúcely. Uzel samotný by nemel obsahovat konkrétní data, ta by mela být uložena v datovémobjektu nebo pomocí jiného mechanismu.

Koncept uzlu v NetBeans využívá architektury Java beans a pridává k ní vlastnosti, ježjsou potreba pro plnohodnotné zobrazení datových struktur a pro práci s nimi. Pomocí No-des API se dá napr. implementovat prakticky libovolná datová hierarchie, kdežto Java Beansposkytují prostrednictvím BeanContext API pouze základní podporu hierarchizace.

Pomocí Explorer API lze potom implementovat množství ruzných zpusobu prezentacetechto hierarchií. Explorer13 prezentuje akce spojené s daným uzlem, zpravidla pomocí vy-skakovací nabídky, zajišt’uje presuny, mazání poduzlu a vytvárení nových.

3.5.1 Typy uzlu

Node. Node je výchozí trídou pro všechny ostatní typy uzlu. Reprezentuje jeden prvekv objektové hierarchii. Hlavní cíle uzlu jsou:

• vizuálne reprezentovat objekt ve stromové hierarchii,

• poskytnout vlastnosti reprezentovaného objektu, napr. k editaci a

• nabídnout dostupné akce, spojené s daným objektem.

11. Poznámka pro autory rozširujících modulu: Akce Open a Delete by mely být dostupné i pro jiné typy sou-boru definic.12. Pozn.: typický preklad pro anglický termín wizard13. Pozn.: Bežný ceský preklad je pruzkumník.

17

3.5. NODES API

Každý uzel Node muže obsahovat nekolik množin vlastností. Každá množina, tzv. Pro-pertySet, má svuj název, který je viditelný v komponente PropertySheet14, a poskytuje se-znam jednotlivých Java Bean vlastností (resp. jejich popisu).

Pomocí tzv. Node.Cookie je možné dodat libovolnému uzlu rozširující funkcionalitu.Metoda getCookie(Class) vrací pro vstupní trídu príslušnou instanci, pokud ji uzel obsahuje.

Uzel obsahuje množinu potomku, jež je popsána trídou Children. Vetšinou je ovšempoužívána její podtrída Children.Keys, která dokáže pro vstupní klíc vrátit podmnožinu po-tomku. Další podtrídy Children jsou napr. Children.Map, Children.Array, Children.SortedMapa Children.SortedArray.

AbstractNode. Základní implementace uzlu. Zjednodušuje práci s ikonami. Z této trídydále vycházejí uzly BeanNode, IndexedNode a predevším pro nás zajímavý DataNode z Lo-aders API.

BeanNode. Pro snadnejší práci s Java Bean komponentami je urcen tzv. BeanNode. Tentouzel dokáže z pridelené komponenty automaticky vyabstrahovat její vlastnosti, vytvoritz nich príslušné PropertySet skupiny, a prezentovat je pomocí PropertySheetu.

FilterNode. Tento typ uzlu slouží jako zástupce pro jiné uzly. Standardne deleguje všechnymetody puvodního uzlu.

3.5.2 Dilema c. 2: BeanNode vs. DataNode

Pri rozhodování o zpusobu využití Nodes API pro základní modul jsem stál pred dalšímdilematem – jaký typ uzlu použít pro prezentaci slovníku? Jelikož slovníky jsou v aplikacireprezentovány Java Bean komponentami, první typ, který mi prirozene prišel na mysl, byluzel BeanNode. Po ryhclé a snadné implementaci tohoto rešení však vyvstal podstatný pro-blém – perzistence. BeanNode prímo nepodporuje napojení na datový objekt, a tudíž anina fyzické uložení své Java Bean komponenty, protože vychází z trídy AbstractNode, stejnejako DataNode, který toto napojení podporuje. Napadla me dve možná rešení tohoto pro-blému: bud’ doimplementovat toto napojení do vlastní podtrídy BeanNode, anebo pridatautomatickou extrakci a správu vlastností Java Bean komponenty do vlastní podtrídy Data-Node. V této cásti textu je již zrejmé, které rešení jsem zvolil. Pro prezentaci slovníku jsempoužil DictionaryDataNode, podtrídu DataNode.

3.5.3 Uzly základního modulu

DictionaryFolderNode. FilterNode, který predstavuje složku slovníku. Jejími potomky jsouuzly DictionaryDataNode. Korenový uzel DictionaryRootFolderNode, jež z této trídy vy-chází, odkazuje na složku Dictionaries v systémovém systému souboru. K tomuto uzlu jsouprirazeny akce pro pridávání dalších slovníku pomocí tzv. NewType a akce pro mazání jed-notlivých slovníku.

14. Komponenta PropertySheet je soucástí Explorer API. Predstavuje standardní zpusob pro práci s vlastnostmiuzlu.

18

3.6. ACTIONS API

NewType dovoluje prizpusobit chování systémové akce NewAcion. Pro každou položkuNewType, kterou uzel poskytuje, zobrazí v menu zvláštní akci. DictionaryFolderNode sipomocí Lookup API zjistí všechny dostupné DictionaryNewType, cili NewType pro pri-dání nového slovníku. Každý rozširující modul musí poskytnout svuj vlastní Dictionary-NewType, který bude provádet vytvárení Java Bean komponent pro jeho typ slovníku.

DictionaryDataNode. Uzel, který reprezentuje slovník. Tato trída byla blíže popsánav cásti o Loaders API, protože vychází z trídy DataNode, která je jeho soucástí. Na tomtomíste pouze podotknu, že DictionaryDataNode poskytuje tzv. LookupDefinitionCookie, ježje podtrídou Node.Cookie, a která zajistí vyhledání definice v reprezentovaném slovníku, ijejí uložení do souboru ve složce pro definice datového objektu15.

S uzlem DictionaryDataNode jsou asociovány akce OpenAction, DeleteAction, Customi-zeAction, PropertiesAction a speciální akce ClearDefinitionsAction, pro vymazání historievyhledaných definic. Preferovanou akcí uzlu je CustomizeAction, která otevre Customizerpro príslušný slovník. OpenAction je momentálne prítomna pouze z testovacích duvodu,aby bylo možné sledovat správné uložení vlastností Bean komponenty do XML. Ve verzipro nasazení do aplikace tato akce nebude viditelná.

DefinitionDataNode. Tato trída byla rovnež popsána v cásti o Loaders API. K tomutouzlu jsou pripojeny minimálne systémové akce OpenAction a DeleteAction.

ResultsNode a ostatní uzly. Uzel ResultsNode spolu s trídou ResultsNodeChildren bylnavržen za úcelem zobrazení výsledku vyhledávání. Vychází z nej jednak uzel Headword-sResultsNode, jež zobrazuje vyhledané výrazy ve slovníkovém tvaru16, jednak uzel Dictio-naryFunctionsResultNode, který je urcen pro zobrazení výsledku dodatecných funkcí jed-notlivých slovníku.

Výsledky dodatecných funkcí jsou trídeny podle jednotlivých slovníku17 a podle názvufunkcí18

Vyhledaný výraz je vyjádren uzlem ExpressionNode. Tento obsahuje odkaz na uzel slov-níku, ve kterém byla definice nalezena. Zobrazovaný název sestává ze jména slovníku a vy-hledaného výrazu. Jediná akce, kterou uzel ExpressionNode nabízí, je vyhledání definicev tomto slovníku. Pro tento úcel je využita výše popsaná Node.Cookie, poskytovaná uzlemslovníku.

3.6 Actions API

Actions API umožnuje uživateli spouštet kód modulu pomocí akcí. Akce mohou být spouš-teny z nabídek, z panelu nástroju, nebo pomocí klávesových zkratek. Pro používání bežnýchakcí není Actions API vubec potreba. Stací pouze zaregistrovat bežnou akci Action balíkuSwing do správné složky systémového systému souboru. Druhou možností je poskytnutí

15. To je ona složka, jejíž jméno koncí retezcem „-definitions“.16. Headword je anglický výraz pro slovo ve slovníkovém tvaru (viz úvodní kapitola).17. Slovník je v uzlu DictionaryFunctionsResultsNode reprezentován uzlem ResultsDictionaryNode.18. Uzel pro seznam výsledku dané funkce je reprezenován uzlem ResultsDictionaryFunctionNode a je potom-kem uzlu ResultsDictionaryNode. Seznam obsahuje uzly s vyhledanými výrazy.

19

3.6. ACTIONS API

seznamu akcí prímo uzlem – pomocí metody Node.getActions(). Vetšinou není nutné vy-tváret podtrídy akcí z Actions API.

Akce jsou typicky bud’ prezentovány pomocí vyskakovací nabídky uzlu, nebo jsou pri-pojeny k jiné komponente, datovému objektu, souborovému systému, anebo jsou prostred-nictvím modulových vrstev instalovány globálne v nabídkách ci panelech nástroju.

Actions API obsahuje kolekci globálních, bežne používaných akcí, jako napr. akce: vy-jmout, kopírovat a najít. Výchozí trídy pro vytvárení vlastních akcí jsou umísteny v UtilitiesAPI19. SystemAction je základní trídou NetBeans akcí. Implementuje rozhraní Action z ba-líku Swing. Z ní vychází tzv. CallableSystemAction, která muže být volána programove, ty-picky pomocí své metody performAction(). Potomkem této trídy je tzv. CallbackSystemAction,která umožnuje priradit jedné akci ruznou funkcionalitu v závislosti na aktivní kompo-nente.

Za zmínku zde stojí rovnež CookieAction z Nodes API, jejíž funkcionalita závisí namnožine Cookie objektu, které aktivovaný uzel nabízí. Její metoda protected void perfor-mAction(Node[] activatedNodes) dostane jako parametr seznam aktivních uzlu. Její chováníby melo být závislé na dostupných Cookie objektech.

3.6.1 Akce hlavního modulu

Hlavní modul zavádí akce pro otevrení svých panelu20. Jedná se o akce: DictionariesOpe-nAction, která otevre panel se seznamem slovníku, HeadwordsOpenAction, která otevrepanel pro vyhledávání, a DictionaryFunctionsOpenAction, která otevre panel pro zobra-zení výsledku slovníkových funkcí. Tyto vycházejí ze trídy AbstractAction z balíku Swing.Modul dále zavádí nekolik akcí CookieAction.

FindInDictionariesAction. Tato akce je CookieAction, která je spojená s textovým edi-torem. Je spustitelná z jeho vyskakovací nabídky, tzn. že je dostupná behem editace textu,podobne jako napr. akce kopírovat nebo vyjmout. Její metoda performAction získá z ak-tivního uzlu tzv. EditorCookie, který jí poskytne prístup k textu editovaného dokumentu ak informacím o stavu editoru, jako napr. pozici kurzoru a oznacení textu.

Po spuštení akce je treba zjistit, jaké slovo ci výraz z dokumentu si uživatel preje vyhle-dat. V prípade, že je v dokumentu vybrán nejaký text, dá se predpokládat, že si preje vyhle-dat práve tento. V prípade, že žádný text vybrán není, zjistí si metoda z EditorCookie pozicikurzoru a extrahuje z dokumentu slovo, na kterém se kurzor nachází. Vybraný výraz potéakce nastaví do vyhledávacího textového polícka na panelu HeadwordsTopComponent21 aspustí vlastní vyhledávání.

Vlastní pripojení k editoru je provedeno registrací na príslušném míste v sysytémovémsouborovém systému – ve složce Editors/MIME_TYP_DOKUMENTU.

Akci je nutné registrovat pro každý editor zvlášt’. V této verzi modulu je registrovánapouze u editoru pro ciste textové dokumenty (jak je videt na príkladu) a editoru XML a

19. balík org.openide.util.actions20. Panelem je zde myšlena komponenta TopComponent. Více viz sekce o využití Window System API.21. viz sekci o Window System API

20

3.7. EXPLORER API...<folder name="Editors">

<folder name="text"><folder name="plain">

<folder name="Popup"><file name="FindInDictionariesAction.shadow">

<attr name="originalFile"stringvalue="Actions/Edit/cz-...-FindInDictionariesAction.instance"/>

</file></folder>

</folder></folder>

</folder>...

Príklad 3.6.1: Registrace akce CookieAction – pripojení k editoru

HTML dokumentu. Registraci je možné pozdeji snadno rozšírit na další textové editory,které budou dostupné v autorském systému.

Na príklade je uveden tzv. shadow, který pouze odkazuje na puvodní instanci akce, re-gistrovanou ve složce Actions/Edit. Toto je bežný postup, který dovoluje uživateli následnepracovat s nastavením akce v aplikaci – napr. ji muže premíst’ovat, prejmenovat, umístit napanel, ci priradit k ní klávesovou zkratku.

ClearDefinitionsAction. Tato akce CookieAction je spojena s uzlem nejakého slovníku.Jejím úcelem je odstranit slovníkem vyhledané definice. K tomu je potreba jednak fyzickyodstranit soubory definic, uložené v príslušné složce slovníku, jednak je nutné obeznámito tom trídu uzlu slovníku, aby aktualizovala svuj stav. Pripojení akce ke tríde DictionaryDa-taNode, resp. DictionaryDataObject, se provede pridáním instance do složky Loaders/text/x-dictionary/Actions.

3.7 Explorer API

3.7.1 Explorer View

Explorer API obsahuje sadu tzv. Explorer view22. Explorer view je komponenta v uživatel-ském rozhraní, která vykresluje hierarchii uzlu, respektive nejakou její podcást a zajišt’ujezobrazování akcí k daným uzlum. Pomocí Explorer view jsou rovnež provádeny presuny,razení a kopírování uzlu.

Explorer view bývá obsaženo v nejaké komponente, která implementuje rozhraní Explo-rerManager.Provider, typicky v komponente TopComponent. Explorer view nalezne v kom-ponentové hierarchii nejbližší ExplorerManager. Pomocí metody setRootContext prísluš-ného manažera ExplorerManager je treba nastavit korenový uzel.

22. dalo by se preložit, jako náhled pruzkumníka

21

3.8. WINDOW SYSTEM API

Do standardní kolekce Explorer view komponent, kterou Explorer API nabízí patrí Bean-TreeView, ContextTreeView, ListView, IconView, ChoiceView, TreeTableView, a MenuView.Hlavní modul využívá pouze BeanTreeView a ListView. BeanTreeView zobrazuje stromo-

vou hierarchii uzlu. Je použit jednak pro zobrazení uzlu slovníku a v nich vyhledanýchdefinic v komponente DictioanriesTopComponent, a jednak pro zobrazení výsledku rozši-rujících funkcí. ListView zobrazuje seznam uzlu a je použit pro výpis nalezených výrazuv komponente HeadwordsTopComponent.

3.7.2 Property Sheet

PropertySheet je standardní komponenta pro editaci vlastností uzlu. Zobrazuje sady vlast-ností editovaného uzlu v rozbalovacích tabulkách. V levém sloupecku tabulky je názevvlastnosti a v pravém príslušný PropertyEditor. PropertySheet podporuje editaci základníchtypu atributu. Dnes se místo techto komponent využívají spíše komponenty Customizer,které uživateli poskytují vetší komfort.

3.8 Window System API

Windows System API poskytuje podporu pro vytvárení vizuálních komponenet a prostredkypro manipulaci s nimi. Tyto komponenty, jež jsou hlavním protredkem komunikace aplikaces uživatelem, vetšinou spravuje standardní implementace správce oken (z angl. windowmanager). Moduly by nemely vytváret své vlastní okenní komponenty (napr. Window z ba-líku AWT), ale mely by ke správe techto komponent využít práve služeb správce oken. Win-dow manager dokáže s aplikacními okny a panely manipulovat, vcetne jejich zakotvovánído záložkových rámu, premíst’ování a podpory perzistence jejich stavu mezi jednotlivýmisezeními (spušteními aplikace). Ke standardnímu správci oken lze pristupovat pomocí Win-dowManager.getDefault().

3.8.1 Komponenta TopComponent

Trída TopComponent je zakotvitelná vizuální komponenta, která se uživateli zobrazuje v apli-kacním prostredí. Je potomkem trídy javax.swing.JComponent (tudíž i trídy java.awt.Containera java.awt.Component). Aby mohlo být s komponentou manipulováno pomocí okenníhosprávce, musí být zakotvená v tzv. módu. Komponenta, která zakotvená není, muže býtnicméne používána, jako bežná JComponent komponenta23.

3.8.2 Módy

Window System API poskytuje prístup k množine tzv. módu, které mohou obsahovat ne-které z vizuálních komponent TopComponent. Módy predstavují urcitou oblast na plošeokna aplikace. Napr. mód explorer se nachází v levé horní cásti, mód properties, ve kterém

23. tj. mimo kontrolu správce oken, napr. v dialogovém okne apod.

22

3.8. WINDOW SYSTEM API

se zpravidla zobrazuje panel s vlastnostmi práve aktivního uzlu, najdeme v levé spodnícásti. Tyto módy nelze vytváret prímo prostrednictvím API, nicméne modul si je muže de-finovat pomocí své XML vrstvy.

Definice vlastního módu je pomerne jednoduchou záležitostí. Prvním krokem je vytvo-rení popisného XML souboru, který urcuje pozici a rozmery. Dalším krokem je registracemódu v XML vrstve modulu. To se provede jednak pridáním popisného souboru (resp.odkazu na nej) do složky /Windows2/Modes, a zadruhé vytvorením složky pro souborys odkazy na komponenty TopComponent, které jsou v módu zakotvené (rovnež do složky/Windows2/Modes)24. Chceme-li, aby v módu byla nekterá komponenta primárne zakot-vena, uvedeme na ní soubor s odkazem práve v této složce25.

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE tc-ref PUBLIC"-//NetBeans//DTD Top Component in Mode Properties 2.0//EN""http://www.netbeans.org/dtds/tc-ref2_0.dtd">

<tc-ref version="2.0"><tc-id id="HeadwordsTopComponent" /><state opened="true" />

</tc-ref>

Príklad 3.8.1: Soubor odkazu na komponentu HeadwordsTopComponent pro zakotvenív módu

Uživatel Window System API muže jednotlivé módy vyhledávat pomocí funkce Win-dowManager.findMode(String name) a prípadne do nich za behu programu zakotvovatkomponenty pomocí funkce Mode.dockInto(TopComponent tc).

Mode mode =WindowManager.getDefault().findMode("explorer");

if (mode != null)mode.dockInto(myTopComponent);

3.8.3 Skupiny

K nekterým cinnostem, které uživatel v aplikaci provádí je casto treba mít otevrených ne-kolik samostatných panelu. Window Sytem API proto umožnuje clenit okna do skupin, po-mocí rozhraní TopComponentGroup. Skupiny se definují podobne, jako módy, uvedenímpopisného souboru skupiny a príslušné složky s odkazy na komponenty v XML vrstve da-

24. Pozn.: Jméno popisného souboru i složky pro odkazy na komponenty TopComponent musí být shodnése jménem vlastního módu, jež je definováno uvnitr popisného souboru. Pod tímto jménem je mód dostupnýpomocí Windows API. Popisný soubor má príponu wsmode.25. Pozn.: Soubor s odkazem má príponu wstcref.

23

3.9. OPTIONS SETTINGS API

ného modulu, ve složce /Windows2/Groups 26. Skupinu je možné vyhledat pomocí funkcesprávce oken WindowManager.findTopComponentGroup(String name).

TopComponentGroup group =WindowManager.getDefault().findTopComponentGroup("myGroup");

if (group != null)group.open(); // resp. group.close();

3.8.4 Uživatelské rozhraní modulu

Hlavní modul definuje tri vlastní panely TopComponent: DictionariesTopComponent – pa-nel pro správu slovníku, HeadwordsTopComponent – panel pro vyhledávání výrazu a zob-razení výsledku a DictionaryFunctionsTopComponent panel pro zobrazení výsledku rozši-rujících funkcí. Komponenta HeadwordsTopComponent nabízí druhou alternativu pro vy-hledání výrazu. Ve svrchní cásti má panel s textovým polem27 pro hledaný výraz a tlacítkopro spuštení vyhledávání.

Modul nezavádí žádné vlastní módy, místo toho zakotvuje své komponenty do módubežne dostupných. DictionariesTopComponent je zakotvena v módu explorer v levé hornícásti, komponenta HeadwordsTopComponent v módu commonPalette v pravé horní cásti,a komponenta pro výsledky slovníkových funkcí v módu properties v pravé spodní cástiplochy aplikace.

Na druhou stranu je pro tyto tri panely vytvorena skupina, aby bylo možné otevrít cizavrít všechny panely najednou.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE group PUBLIC"-//NetBeans//DTD Group Properties 2.0//EN""http://www.netbeans.org/dtds/group-properties2_0.dtd">

<group version="2.0"><name unique="DictionariesGroup" /><state opened="false" />

</group>

Soucástí základního modulu je i jednoduchý Customizer pro slovníky. Umožnuje editacijména.

3.9 Options Settings API

Options Settings API nabízí možnost jednoduchého ukládání nastavení pro modul. Net-Beans IDE 5.0 obsahují pruvodce pro automatické vytvorení potrebných tríd. Existují dve

26. Pozn.: Popisný soubor pro skupinu má príponu wsgrp. Soubor odkazu na komponentu TopComponent mápríponu wstcgrp.27. Pozn.: Pri spuštení vyhledávání z editoru je do tohoto pole vloženo slovo automaticky.

24

3.9. OPTIONS SETTINGS API

možnosti, jak pridat do hlavního okna nastavení vlastní kategorii. První možnost je pridathlavní kategorii – OptionsCategory. Druhá možnost je vytvorit podkategorie v kategoriiMiscelaneous28 – AdvancedOption. Pro danou kategorii je ješte potreba vytvorit vizuálníkomponentu pro editaci možností – OptionsPanel a k nemu OptionsPanelController.

Hlavní modul momentálne nemá žádná globální nastavení, proto vlastní kategorii ne-pridává. Pokud by nejaká nastavení byla v dusledku dalšího vývoje potrebná, není problémkategorii dodatecne vytvorit.

28. Ceský význam slova: ruzné.

25

Kapitola 4

Tvora modulu pro slovníky dostupné pres protokol DICT

V této kapitole je popsán postup pri tvorbe rozširujícího modulu, který využívá API zá-kladního modulu. Tvorba je pomerne jednoduchá, protože vlastní práci se slovníky a jejichvlastnostmi, i uživatelské rozhraní podporuje hlavní modul. Je možné se proto soustreditpredevším na implementaci vlastností konkrétního typu slovníku.

Tento konkrétní modul implementuje vyhledávání na slovníkových serverech dostup-ných pomocí protokolu DICT.

4.1 Protokol DICT

Protokol DICT, nebo také Dictionary Server Protocol1, je transakcní TCP protokol typu do-taz/odpoved’, který umožnuje klientovi pristupovat k definicím ze sady slovníkových da-tabází, dostupných na slovníkovém serveru.

Na linkové úrovni DICT protokol predpokládá spolehlivý datový kanál, jako napr. TCP.Pokud server beží nad TCP, zpravidla poslouchá na portu 2628.

Príkazy a odpovedi jsou složeny ze znaku sady UCS2, kódovaných v UTF-83. Protokolpoužívá gramatické konvence definované v RFC 822.

4.1.1 Seznam príkazu

Protokol definuje jednoduchou množinu príkazu.

• DEFINE

DEFINE database word

Vyhledá definici slova word v databázi database.

• MATCH

MATCH database strategy word

Najde slovo word v indexu databáze database pomocí strategie strategy.

1. Z anglictiny by se tento název dal preložit jako Protokol slovníkového severu.2. ISO 106463. RFC 2044

26

4.1. PROTOKOL DICT

• SHOW

SHOW DATABASESSHOW DB

Vyžádání seznamu dostupných databází. DB muže být použito jako zkratka pro DA-TABASES.

SHOW STRATEGIESSHOW STRAT

Vyžádání seznamu dostupných vyhledávacích strategií. STRAT muže být použitojako zkratka pro STRATEGIES. DICT server by mel minimálne podporovat strategieexact a prefix.

SHOW INFO database

Získá ze serveru informace o databázi database.

SHOW SERVER

Informace o serveru.

• Další príkazy

OPTION MIME

Zapne používání MIME hlavicek.

CLIENT info

Odešle serveru informace o klientovi.

AUTH user string

Poskytnutí autentizacních údaju.

STATUS

Zobrazí casovací informace.

QUIT

Ukoncí spojení.

27

4.2. JÁDRO ROZŠIRUJÍCÍHO MODULU

4.2 Jádro rozširujícího modulu

Každý modul musí dodat své vlastní rozšírení trídy Dictionary z jádra hlavního modulu.K vlastnostem této Java Bean komponenty by mel prípadne pridat dodatecné vlastnosti, ježbudou ovlivnovat vyhledávání.

Tento konkrétní modul pridává vlastnosti potrebné pro nastavení spojení s DICT serve-rem. Pro uskutecnení tohoto spojení je potreba znát IP adresu serveru, port a jméno data-báze, ve které chceme vyhledávat.

Rozširující trída se nazývá DICTDictionary. Metody define a match definuje takovýmzpusobem, aby pro vstupmní parametr String expression uskutecnily požadované operacena nastaveném serveru. Vlastní funkcionalita je pro prehlednost oddelena od trídy DICT-Dictionary, a je umístnena ve tríde DICTUtils. Metody této trídy zajišt’ují klientskou cástprotokolu DICT – konkrétne príkazy: DEFINE, MATCH, SHOW DATABASES a SHOWSTRATEGIES. Pri programování jsem se nechal inspirovat zdrojovými kódy JDictd, což jeDICT server napsaný v jazyce Java. [4]

Prostrednictvím ruzných vyhledávacích strategií, dostupných na slovníkových serve-rech, nabízí trída DICTDictionary množinu svých rozširujících funkcí. V komponente JavaBean je uložen seznam kódu strategií. Z techto srategií se vygenerují príslušné trídy Dicti-onary.Function, jejichž funkce getFunctionResult vrací pro vstupní výraz seznam výrazu,nalezených pomocí dané strategie. Mezi nejcasteji podporované strategie patrí exact, prefixa suffix match a regulární výrazy.

4.3 Nodes API

Aby bylo možné v aplikaci pridávat slovníky daného typu, je nutné v systémovém soubo-rovém systému zaregistrovat vlastní podtrídu DictionaryNewType, jež muže být pomocíLookup API vyhledána uzlem složky slovníku, a posléze prezentována jako akce pro pri-dání slovníku.

<folder name="Services"><folder name="Hidden">

<folder name="NewTypes"><file name="cz-...-DICTDictionaryNewType.instance"/>

</folder></folder>

</folder>

DictionaryNewType pro tento modul nese název DICTDictionaryNewType. Zajišt’ujevytvorení instance Java Bean komponenty DICTDictionary a její uložení do souboru.

4.4 Customizer

Pro specializované editování vlastností Java Bean komponent slouží vizuální komponenta,implementující rozhraní Customizer. Customizer pro DICT slovník umožnuje nastavit jméno

28

4.5. OPTIONS SETTINGS API

slovníku, adresu DICT serveru a port, a zejména dokáže z tohoto serveru stáhnout a zobra-zit seznam dostupných databází a strategií. Uživatel tak nemusí znát jednotlivé kódy data-bází, resp. strategií, ale muže tyto vybírat ze seznamu podle serverem dodaného popisnéhonázvu. Dialog Customizeru dále dovoluje editovat a odmazávat jednotlivé strategie, což jevýhodné, pokud si uživatel preje nekteré strategie (tzn. príslušné funkce slovníku) prejme-novat, ci nepoužívat.

4.5 Options Settings API

OptionsPanel modulu umožnuje spravovat seznam uložených slovníkových serveru, cožusnadnuje konfiguraci slovníku v Customizeru. Seznam je ukládán do systémového soubo-rového systému pomocí XMLEncoderu – podobne, jako Java Bean komponenty slovníku.Modul pridává do okna pro nastavení vlastní podkategorii kategorie Miscelaneous.

29

Kapitola 5

Záver

Záverem strucne shrnu a zhodnotím dosažené výsledky.Hlavní cíl práce – poskytnout autorskému systému modul s univerzálním rozhraním pro

práci se slovníky – byl splnen. Modul zajišt’uje pridávání, mazání slovníku a úpravu jejichvlastností jak pomocí standardní komponenty Property Sheet, tak i prostrednictvím specia-lizovaných komponent Customizer. Podporuje rozširující funkce pro ruzné typy slovníku amožnost nastavit typ dokumentu pro definice. Dále nabízí uživatelské rozhraní pro vlastnívyhledávání a zobrazování výsledku.

Cílem tvorby rozširujícího modulu bylo predvést použitelnost hlavního rozhraní. Tentocíl byl také splnen. Modul pridává podporu pro slovníky dostupné pres Dictionary ServerProtocol. Splnuje základní požadavky: vyhledávání výrazu a získávání jejich definic. Navícvyužívá i podpory rozširujících funkcí – u slovníku je možné nastavit rozširující funkci prokaždou vyhledávací strategii, kterou podporuje príslušný slovníkový server. Modul obsa-huje Customizer, který usnandnuje úpravu vlastností DICT slovníku.

Na tomto míste bych rád podotknul, že vytvorené moduly zatím nebyly testovány v re-álném aplikacním provozu, vzhledem k tomu, že projekt Open Platform je v dobe jejichvytvárení na svém pocátku a samotná aplikace autorského systému v této dobe ješte nee-xistuje. Moduly pro slovníky jsou jedny z prvních, které byly v rámci Open Platform vytvo-reny. Je proto možné, že jejich chování nebude (v této prvotní verzi) v nekterých aspektechzcela bezchybné. Prepodkládá se jejich další vývoj, který bude zrejme také záviset na vývojiautorského systému.

30

Literatura

[1] Sun Microsystems: NetBeans API List, Sun Microsystems, Inc., 2006, <http://www.netbeans.org/download/dev/javadoc> . 3

[2] Sun Microsystems: JavaBeans API Definitions, Sun Microsystems, Inc., 2006, <http://java.sun.com/j2se/1.5.0/docs/api/java/beans> . 3.2.1

[3] Boudreau, T. a Glick, J. a Greene, S. a Spurlin, V. a Woehr, J.: NetBeans The Defi-nitive Guide, O’Reilly & Associates, Inc., 2003, 0-596-00280-7, oreilly.com – OnlineCatalog: NetBeans: The Definitive Guide <http://www.oreilly.com/catalog/netbeans> . 2.1, 2.2, 2.3

[4] Ho Ngoc Duc: JDictd, Institut für Informatik [Internet], 6. 4. 2006, <http://www.informatik.uni-leipzig.de/~duc/Java/JDictd> . 4.2

[5] Sun Microsystems: Tutorials for NetBeans Plug-in Module and Rich-ClientApplication Development, Sun Microsystems, Inc., 2006, <http://platform.netbeans.org/tutorials> . 3

[6] Wikipedia: Corpus, Wikipedia, The Free Encyclopedia, 16. 5. 2006, <http://en.wikipedia.org/wiki/Corpus> . 1.3

[7] Wikipedia: Dictionary, Wikipedia, The Free Encyclopedia, 16. 5. 2006, <http://en.wikipedia.org/wiki/Dictionary> . 1.1

[8] Wikipedia: Glossary, Wikipedia, The Free Encyclopedia, 16. 5. 2006, <http://en.wikipedia.org/wiki/Glossary> . 1.2.5

[9] Wikipedie: Lemma, Wikipedie, Otevrená encyklopedie, 16. 5. 2006, <http://cs.wikipedia.org/wiki/Lemma> . 2

[10] Wikipedia: NetBeans, Wikipedia, The Free Encyclopedia, 15. 5. 2006, <http://en.wikipedia.org/wiki/Netbeans> . 2

31

Rejstrík

AbstractNode, 18Actions API, 19AdvancedOption, 24

BeanInfo, 10BeanInfo Editor, 10BeanNode, 18BeanTreeView, 22

ClearDefinitionsAction, 21CookieAction, 20Customizer, 28

datový objekt, 14datový objekt pro definice, 16datový objekt slovníku, 16datový slovník, 3define, 11DEFINE, 26DefinitionDataLoader, 17DICT, 26DICTDictionary, 28DICTDictionaryNewType, 28DictionariesTopComponent, 24Dictionary, 10Dictionary Server Protocol, 26Dictionary.Function, 12DictionaryDataLoader, 15DictionaryDataNode, 16, 19DictionaryDataObject, 16DictionaryFolderNode, 18DictionaryFunctionsTopComponent, 24

ELSW, 1Explorer API, 21Explorer view, 21ExpressionNode, 19

FileObject, 13Filesystems API, 13FilterNode, 18FindInDictionariesAction, 20

glosár, 3

HeadwordsTopComponent, 24hlavní modul, 8

integrace, 1

Java Bean, 9Java Beans, 9jednooborový slovník, 3

komponenta Java Bean, 9korpus, 4

lemma, 2ListView, 22Loaders API, 14

mód, 22match, 11MATCH, 26modul do NetBeans, 6modul slovníku DICT, 26modulová vrstva, 7

NetBeans API, 5NetBeans IDE, 5NewType, 18Node, 17Node.cookie, 18Node.Children, 18Nodes API, 17, 28

Open API, 5Open Platform, 1OptionCategory, 24Options Settings API, 24

prekladový slovník, 2perzistence, 10, 12platforma NetBeans, 5podoborový slovník, 3Property Sheet, 22PropertyChangeSupport, 11protokol DICT, 26

ResultsNode, 19

32

rozširující modul, 26

SHOW, 27skupina, 23Sun Public Licence, 5systémový souborový systém, 6System Filesystem, 6SystemAction, 20

technický slovník, 3TopComponent, 22TopComponentGroup, 23

uzel, 17

víceoborový slovník, 3

Window System API, 22

Xelfi, 5XMLDecoder, 10XMLEncoder, 10

zkrytý Markovuv model, 4znakový slovník, 3

33

Príloha A

Seznam DICT serveru

Toto je pouze strucný výcet. Kompletnejší seznam lze nalézt na webové stránce DICT pro-tocol server list <http://luetzschena-stahmeln.de/dictd/>.

• dict://dict.org – Standardní dictd server. Osahuje nekolik databází souvisících s an-glickým jazykem a FreeDict databáze.

• dict://dict.aioe.org – Standardní slovníky, všechny vydané FreeDict slovníky, Wiki-pedia (anglická, francouzská, španelská, italská a nemecká), experimentální slovníkmanuálových stránek UNIXu, nekolik italských slovníku, španelské glosáre, slovan-ské slovníky.

• dict://vocabulary.aioe.org – To samé, co na dict.aioe.org, ale bez Wikipedie.

• dict://dict.tugraz.at – Standardní a FreeDict slovníky.

• dict://mova.org – Slovanské slovníky.

• dict://dict.tu-chemnitz.de – Standardní slovníky.

• dict://test.dict.org – Stejné databáze jako na dict.org. Prístupný agresivnímu testo-vání klientu.

• dict://dict.trit.org – Standardní databáze.

• dict://dict.die.net – 11 standardních databází. Podporuje krížové odkazy.

• dict://dict.arabeyes.org – Anglicko arabský slovník.

34