Si iiiííi^^/ jiM'l'^rif^v^ -Äclii íMŠm rÉBteli& päSiíiííííiMEfe fefífAlfl í'f Ä !Í?ÍSÍÍÍmPÍ^MwÄ V II íliiíapPíi

fefífAlfl í'f Ä !Í?ÍSÍÍÍmPÍ^MwÄ V II íliiíapPíi

I P l f i i l I k í L. . / a ' li ] B • t1. 1 . , / . H h; / vS < I L - u ' l K i Ľ w l j v , v Í ! » ; J

rÉBteli& rife^áiftiffiisyi, päSiíiííííiMEfe

Si iiiííi^^/ jiM'l'^rif^v^ -Äclii íMŠm

i

! \ r

IhKL í.

i i

; W K i ' C Í Í M U i !

Fakulta mechatroniky, informatiky a mezioborových studií

Studijní program: N2612 - Elektrotechnika a informatika Studijní obor: 1802T007 - Informační technologie

Software pro efektivní tvorbu diktovacích slovníků Software for effective building

of dictation lexicons

Diplomová práce

Autor:

Vedoucí práce:

Konzultant:

UNIVERZITNÍ KNIHOVNA TECHNICKÍ UNIVERZITY V LIBERCI

Bc. Petr Stefan Ing. Petr Červa, Ph.D.

Ing. Jindřich Žďánský, Ph.D.

3146137539

V L i b e r c i 2 0 . 5. 2 0 1 0

U s t a v i n f o r m a č n í c h technologií a e l e k t r o n i k y Akademický rok: 2 0 0 9 / 2 0 1 0

ZADÁNÍ DIPLOMOVÉ PRÁCE

(PROJEKTU, UMELECKÉHO DÍLA, UMELECKÉHO VÝKONU)

Jméno a příjmení: B c . P e t r Š T E F A N

Studijní program: N 2 6 1 2 E l e k t r o t e c h n i k a a i n f o r m a t i k a Studijní obor: I n f o r m a č n í technologie

Název tématu: S o f t w a r e p r o efektivní t v o r b u d i k t o v a c í c h slovníků

Z á s a d y p r o v y p r a c o v á n í :

1. Seznamte se s problematikou jazykového modelování v systémech plynulého diktování vyvinutých na TU v Liberci.

2. Vytvořte software, který bude umožňovat efektivně tvořit nové slovníky pro zmíněné systémy. Aplikace musí být postavena na síťové architektuře, kde všechna již existující slovní zásoba bude z důvodu bezpečnosti uložena na serveru, k němuž se bude připojovat klient umožňující přidávat k již existujícím slovům nové výrazy. Vytvořená klientská aplikace musí dále umožňovat zejména: tvořit výslovnostní varianty

k jednotlivým slovům, vyhledávat je na internetu, zobrazovat reprezentativní okolí každého slova ze zdrojového textového korpusu, provádět normalizaci přidávaných slov, kontrolovat, zda ve slovníku již není dané slovo obsaženo v jiném tvaru, skloňovat slova a jejich výslovnost za využití zvoleného SpellCheckeru, atd.

3. Vytvořte k softwaru kvalitní uživatelský manuál a v práci popište důvody a výhody použitých prostředků a postupů.

ŮY\,

Prohlášení

Byl jsem seznámen s tím, že na mou diplomovou práci se plně vztahuje zákon č. 121/2000 Sb., o právu autorském, zejména § 60 - školní dílo.

Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé diplomové práce pro vnitřní potřebu TUL.

Užiji-li diplomovou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.

Diplomovou práci jsem vypracoval samostatně s použitím uvedené literatury a na základě konzultací s vedoucím diplomové práce a konzultantem.

Datum

Podpis

VJ

Forma zpracování diplomové práce: t i š t ě n á / e l e k t r o n i c k á Seznam odborné literatury:

[1] N o u z a J . ( e d i t o r ) : P o č í t a č o v é z p r a c o v á n í řeči. T U L L i b e r e c 2001.

[2] P u s t k a J . a kol.: M l u v í m e s p o č í t a č e m česky. A c a d e m i a , P r a h a 2006.

Vedoucí diplomové práce:

Konzultant diplomové práce:

Ing. P e t r Č e r v a , P h . D .

Ústav informačních technologií a elektroniky Ing. J i n d ř i c h Zďánský, P h . D .

Ostav informačních technologií a elektroniky

Datum zadání diplomové práce: 16. ř í j n a 2009 Termín odevzdání diplomové práce: 21. k v ě t n a 2010

r faadlf

prof. Ing. Václav Kopecký, <JSc. N ^ S j - v ' prof. Ing. Ondřej Novák, CSc.

děkan vedoucí ústavu

V Liberci dne 16. října 2009

Poděkování *

Rád bych poděkoval vedoucímu mé práce, Ing. Petru Červovi, Ph.D., za odborné připomínky, trpělivost a pomoc při zpracování této práce, svým přátelům a rodinným příslušníkům za různé připomínky, zejména v oblasti slovosledu, možnostech vyjadřování se a celkové grafické úpravě tohoto textu.

Abstrakt |

Cílem této diplomové práce je návrh a vytvoření softwarových a aplikačních prostředků pro efektivní tvorbu diktovacích slovníků. Nejprve však bylo potřeba porozumčt tomu, jak souvisí nutnost existence takových slovníků s rozpoznáváním zaznamenané řeči. Získané vědomosti o vysoké náročnosti na databázi slov a jejich výslovností, respektive fonémů a fonetických přepisů, vytvořily základ pro návrh dané aplikace.

Ustav informačních technologií a elektroniky při Technické univerzitě v Liberci již podobný software využívá. Ten je ovšem desktopového charakteru, a proto je jeho použití vysoce náročné — zejména na čas plynoucí z komunikace mezi uživateli.

Zároveň je platformě závislý (MS Windows, .NET Framework). Tudíž bylo zapotřebí navrhnout a implementovat jiný model této aplikace, postavený zejména na síťových technologiích. Z požadavků na vysokou přístupnost a uživatelskou jednoduchost byla navržena webová aplikace, která bude umístěna na centrálním serveru. K té budou všichni její uživatelé přistupovat pomocí běžného prohlížeče webových stránek, který je standardní součástí téměř všech osobních počítačů.

Tento software bude uživatelům zejména umožňovat opravovat existující slova, přidávat k nim nové výrazy a tvořit jejich výslovnostní varianty spolu s generováním fonetických přepisů. Dále umožní rychle vyhledávat významy slov na různých internetových serverech a zobrazovat jejich reprezentativní okolí ze zdrojového textového korpusu. V neposlední řadě bude umožňovat nahlédnout do výsledného slovníku, zda již někdo daný termín nezpracoval, a ušetřit tím práci.

Součástí této práce by měl být i kvalitní uživatelský manuál, který ulehčí zaškolení jednotlivých uživatelů systému. Zároveň by text měl sloužit i pro vysvětlení použitých technologií (zejména pak aplikačních frameworků) pro případ, že by bylo do budoucna potřeba aplikaci nějak upravit dle aktuálních požadavků.

Poslední část diplomové práce se zabývá problémem, jak ze zadaného textového korpusu zjistit charakteristické okolí konkrétních slov, aby mohly být tyto informace k dispozici během práce s popisovanou webovou aplikací.

Klíčová slova:

Diktovací slovník. Rozpoznávání řeči. Webová aplikace. Textový korpus.

Reprezentativní okolí. Charakteristické okolí. PHP. JavaScript. SQL.

Abstract | ~|

The aim of this thesis is to design and create software and application instruments for the effective creation of dictating dictionaries. Primarily was necessary to understand the connection between existence necessity of such dictionaries to identify the recorded speech. Acquired knowledge about high requirements on a database of words and their pronunciation (phonemes, and phonetic transcriptions of the pronunciations) formed the basis for the design of the application.

The department of Information Technology and Electronics at the Technical University of Liberec has been already using similar software. It is, however, desktop application, and therefore its use is highly intensive - especially in time resulting from communication between users. It is also dependent on platform (Windows, .NET Framework). It was therefore necessary to design and implement a different model of the application, built mainly on network technology. The requirements for high accessibility and user's fřiendliness designed web application, which will be placed on a centrál server. All the users can access it using a standard web browser, which is a standard part of almost all personál computers.

This software will especially allow users to correct existing words, to add new word forms and their pronunciation variants to them, together with the generation of phonetic transcriptions. Furthermore, to quickly find the meanings of words on various Internet servers and to display their representative area from the source corpus. Lastly, it will provide the consultation in the finál dictionary, if someone has already processed the given word o save the work.

A good user's manual, which makes the training of systém easier for the users, should be part of the work. It would also serve as text for an explanation of the technologies (especially application frameworks) for the case, it would be necessary in future to modify somehow the application to meet the demands.

The last part deals with the problém, how to find the characteristic neighborhood of specific words from the given text corpus to allow the information be accessible during the work with the web application.

Keywords:

Dictation lexicon. Speech recognition. Web application. Text corpus.

Representative area. Distinctive neighborhood. PHP. JavaScript. SQL.

Obsah [

1 Úvod 9 1.1 Motivace pro řešení úlohy 9

1.2 Současný postup při zpracovávání kandidátů 10

1.3 Cílové řešení 11 2 Použité technologie 12

2.1 HTTP (HTTPS) 12 2.2 HTML (XHTML) 13 2.3 PHP: Hypertext Preprocessor 14

2.4 JavaScript 14 2.5 SQL 15 2.6 nadstavby 15

2.6.1 PHP - Nette Framework 15 2.6.2 PHP databázová vrstva DIBI 19

2.6.3 jQuery 20 3 Vlastní aplikace 22

3.1 Princip 22 3.2 Uchovávání dat 23

3.2.1 Ukládaná data 24 3.2.2 Návrh databáze 25 3.3 Serverová část aplikace 26

3.3.1 Základ 27 3.3.2 Autentizace 28 3.3.3 Uživatelé 29

3.3.4 Slovník 3 0

3.3.5 Access Control List - seznam pro řízení přístupu 30

3.3.6 Správa projektů 31 3.3.7 Práce na projektu 32 3.3.8 Propojení s knihovnou na generování fonetických transkripcí 36

3.4 Klientská část 3 8

3.4.1 AJAX (Asynchronous JavaScript and XML) 39

3.4.2 Klávesové zkratky 3 9

3.4.3 Ostatní využití 4 0

4 Hledání charakteristického okolí 42

4.1 použité technologie - Perl 4 2

4.2 původní myšlenky 4 2

4.3 použitý algoritmus 4 4

4.3.1 načtení kandidátů 4 4

4.3.2 hledání konkrétních okolí 4 4

4.3.3 nalezení nejčetnčjších okolí 4 5

4.3.4 export výsledků » 46

4.4 použití 46 5 Závěr 47

1 U v o d

1.1 Motivace pro řešení úlohy

Rozpoznávání řeči je oblastí, která je v aktuální době celosvětově intenzivně studována. Systémy schopné rozpoznat mluvenou řeč se stávají součástí běžného života v mnoha aplikacích. Jedná se především o automatizované informační systémy, ovládání různých zařízení hlasem, diktovací systémy převádějící mluvenou promluvu do textové podoby, transkripce audio nahrávek, apod.

Existuje více různých způsobů rozpoznávání slov, ovšem ne všechny se hodí na všechny aplikace. Statistické modely používající celá slova se hodí zejména pro aplikace, jejichž slovníky jsou celkem malé (desítky až stovky slov) a téměř stálé (nemění se často). Je třeba si uvědomit, že tento postup není vhodný pro systémy, kde se data často mění, protože by bylo potřeba veškerá tato slova znovu natrénovat.

Proto je nutné se zaměřit na nižší stavební jednotky slov - fonémy. Těch je podstatně méně než slov (20 až 50 - dle jazyka). Jejich modely je ovšem nutné trénovat na zvukových záznamech, kde každý foném bude zastoupen v mnoha různých tvarech a spojeních (řádově tisíce). Zároveň tato trénovací databáze musí obsahovat i fonetickou transkripci jednotlivých záznamů. Pokud tedy získáme veškeré modely fonémů, je z nich následně možné sestavit libovolná slova. K tomu je ale potřeba jejich fonetický přepis.

Pro rozpoznávání řeči je tedy nutné mít slovník (databázi) jednotlivých slov, jejich tvarů a fonetických transkripcí. Je třeba si však uvědomit, že jde o velmi komplikovanou úlohu, zejména v češtině, jejíž slovník čítá několik milionů různých slovních tvarů. Z toho důvodu je potřeba „všechny" tyto tvary, zejména jejich výslovnosti a přepisy do fonetické abecedy, shromáždit a uchovat.

Proto se získává (z různých zdrojů) co největší počet textů z nejrůznějších oblastí, ze kterých se tyto slovníky vytvářejí. Korpusy ovšem obvykle obsahují spoustu řetězců, které pro rozpoznávání nejsou potřeba (naopak - ovlivnily by správnou funkci), nebo už byly dříve zpracovány, a tudíž jsou již ve slovníku obsaženy. Z toho důvodu jsou texty nejprve normalizovány a poté jsou nežádoucí slova odstraněna porovnáním s tzv.

černým seznamem slov („blacklistem"). Po takto provedené filtraci se korpus ještě porovnává s již vytvořeným slovníkem. Tímto postupem získáme seznam kandidátů na přidání do slovníku.

Ten ale zároveň může obsahovat i překlepy a chyby, které je nutné eliminovat a opravit. Za tímto účelem je potřeba, mimo jiné, mít nčjaký efektivní nástroj, který pomůže tento slovník co nejrychleji tvořit.

1.2 Současný postup při zpracovávání kandidátů

Jelikož zdrojové texty jsou obvykle zaměřené na konkrétní obor (lékařství, právnictví, atd.), není v silách jednoho člověka všechny tyto termíny znát. Proto na jednotlivých druzích textu pracují různí lidé.

Ustav informačních technologií a elektroniky prozatím používá systém desktopového charakteru, proto je nutné jej nainstalovat na všechny počítače osob, které s ním budou pracovat. Zároveň je napsán v programovacím jazyce C#, tudíž jde ruku v ruce s platformou .NET Framework a operačním systémem Microsoft Windows.

Z toho vyplývá, že i tento framework je nutné pro správnou funkci programu mít nainstalovaný. Už zde je vidět vyšší „konfigurační a instalační" náročnost na uživatele.

Toto ovšem není největší problém daného řešení.

Doposud bylo nutné, aby:

1. administrátor odeslal vygenerované kandidáty jednotlivým řešitelům 2. řešitel zpracoval data a výsledek odeslal zpět (více dat)

3. administrátor výsledek porovnal se svým slovníkem a aktualizoval ho.

řešitel

Obrázek 1 - model souíasné komunikace

Z obrázku 1 je vidět, že tento model představuje značnou náročnost (nejen časovou, ale zejména komunikační) na administrátora. Proto se muselo hledat řešení, které by nutnost takovéto správy omezilo.

1.3 Cílové řešení

Zároveň by bylo vhodné současně zamezit potřebě odesílat novou verzi aplikace řešitelům, v případě její aktualizace. Proto byl navržen centralizovaný model, kde se o aplikaci jako takovou stará server a řešitelé se (jako klienti) přihlašují k němu.

Aby se vyřešil problém jeho přenositelnosti mezi platformami a univerzálnosti použití na téměř jakémkoliv počítači, bez nutnosti instalace jakýchkoliv dalších knihoven či doplňků, bylo navrženo řešení pomocí webové aplikace. Jedinou nutnou podmínkou pro její běh je připojení k internetu a standardní prohlížeč webových stránek, kterým disponuje, v současné době, prakticky každý osobní počítač.

A A

řešitel řešitel řešitel řešitel řešitel řešitel

Obrázek 2 - model budoucí komunikace

Z obrázku 2 je patrné, že veškerá komunikace administrátora se omezila jen na server. To samé platí i pro řešitele. Ti tudíž vůbec nemusí přijímat obsáhlá data, vše je uloženo na serveru a stahují tedy jen to, na čem aktuálně pracují.

V následující kapitole budou stručně popsány jednotlivé použité technologie, jejich výhody a vlastnosti, pro ně charakteristické.

2 Použité technologie *

Jelikož je potřeba, aby aplikace byla přístupná odkudkoliv a z jakéhokoliv počítače připojeného k internetu, byly použity ty nejběžnější způsoby komunikace a metody pro stavbu webových aplikací.

2.1 HTTP (HTTPS)

Jako protokol aplikační vrstvy byl využit nej běžnější HTTP (Hypertext Transfer Protocol). Obvykle používá port 80. Slouží se nejen k přenosu dokumentů ve formátu HTML (a podobných), ale pomocí rozšíření MIME (Multipurpose Internet Mail Extensions) umí přenášet v podstatě jakýkoliv soubor. Aby se s využitím tohoto protokolu dalo specifikovat jednoznačné umístění daného zdroje v rámci internetu, používá se jednotný lokátor prostředků (Uniform Resource Locator - URL).

Princip fungování HTTP by se dal popsat následovně. Klient (např. webový prohlížeč) odešle serveru dotaz ve formě čistého textu, který mimo jiné obsahuje základní důležité informace o žádaném dokumentu. Server následně odpoví několika řádky textu (hlavička - zda se podařilo dokument najít, typ dokumentu, atd.) a příslušným dokumentem. Pokud klient následně zažádá o jiný dokument, děje se tak znova, zcela nezávisle na předchozím dotazu. Z toho vyplývá základní vlastnost tohoto protokolu - bezestavovost (nedokáže uchovávat stav, jednotlivé dotazy spolu nemají souvislost). Proto se tato skutečnost musí obejít jinými způsoby.

Standard HTTP definuje několik základních metod, pomocí kterých se dotazy uskutečňují. Nejdůležitější dvě metody jsou GET a POST, ostatní nemá smysl v rámci tohoto textu popisovat.

• GET Éj požadavek na konkrétní objekt se zasláním případných dat (výchozí metoda)

• POST - odesílá data na server, používá se zejména v souvislosti s formuláři, pokud se jedná například o příliš rozsáhlá data, nebo pokud není vhodné, aby se data přenášela jako součást URL

Jelikož tento protokol není nijak zabezpečený a data jsou mezi klientem a serverem přenášena nešifřovaně, používá se nadstavba HTTPS. Ten umožní zabezpečit spojení nejen proti odposlechnutí, ale i proti podvržení dat. Veškerá

přenášená data jsou zašifrována. Tento protokol standardně používá port 443* Využívá se asymetrického šifrování (čili používají se dva klíče - veřejný a soukromý). Více o tomto druhu zabezpečení je možné nalézt v [5],

2.2 HTML (XHTML)

Jedním z jazyků pro publikaci dokumentů na internetu je značkovací jazyk pro hypertext (text s odkazy) SHyperText Markup Language. Je charakterizován množinou značek (tagů) a jejich atributů. Mezi značky se uzavírají části textu a tím se určuje význam v rámci dokumentu. Tyto tágy jsou obvykle párové (mají počáteční i koncovou značku), ovšem existují i nepárové. Základním rozdílem mezi HTML a XHTML (Extensible HyperText Markup Language) je to, že v XHTML dokumentu musí být všechny značky (tedy i ty nepárové) uzavřené a pro názvy a atributy elementů se smějí používat jen malá písmena. Několik příkladů nepárových značek včetně jejich rozdílu v rámci HTML a X H T M L je uvedeno v následující tabulce.

HTML XHTML

Nový řádek <br> <br />

Obrázek <img src="" alt=""> <img src="" alt="" />

Tabulka 1 - Příklad rozdílu HTML a XHTML Několik příkladů párových značek:

i 1. <p>odstavec</p>

! 2. <a href="http://www.tul.cz" title="TUL">odkaz na TUL</a>

: 3. <strong>Tučný text</strong>

Základní struktura XHTML dokumentuje naznačena v následujícím kódu.

ji. <?xml version="l.0" encoding="utf-8"?>

i 2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"DTD/xhtmll-strict.dtd">

i 3. chtml xmlns="http://www.w3.org/1999/xhtml" xml:lang="cs"

lang="cs">

: 4. <head>

; 5. <meta http-equiv="content-language" content="cs" />

| 6. <meta http-equiv="content-type" content="text/html;

charset=utf-8" />

;7. <title>Titulek stránky</title>

; 8. </head>

j 9. <body>

: 10. tělo stránky i 11. </body>

! 12. </html>

Dle specifikace existují určité značky, které mají některé z atributů .povinné.

Například pro obrázek (element img) je vždy nutné definovat atributy pro cestu (src) a alternativní text (alt) v případě jeho nenalezení.

Veškeré značky lze významově rozdělit na tři typy:

1. strukturální - struktura dokumentu, forma dokumentu 2. popisné - specifický obsah elementu

3. stylistické - ovlivňují vzhled, ovšem v moderních aplikacích bývají nahrazeny pomocí CSS (kaskádových stylů)

Podrobnější informace, návody a rady lze nalézt v [6]

2.3 PHP: Hypertext Preprocessor

Český ekvivalent významu zní PHP: Hypertextový preprocesor. Jedná se 0 skriptovací jazyk, který se používá především pro vytváření dynamický webových aplikací a prezentací. Nejčastější využití je takové, že pomocí PHP je generován vlastní (X)HTML dokument. Lze ho ale samozřejmě použít i k tvorbě konzolových 1 desktopových aplikací. Jeho skripty jsou obvykle vykonávány na straně serveru, k uživateli je přenesen jen jejich výsledek. Jeho specifikace, dokumentace a rady lze dohledat v [7].

Mezi jeho základní vlastnosti patří například:

• dynamické typy - datový typ se určí až v okamžiku přiřazení

• dvojí porovnávání (== a ===), druhý porovnává jak hodnotu, tak dat. typ

• pole indexované jak čísly, tak řetězci (hashe)

• heterogenní pole - různé datové typy v rámci pole

Mezi hlavní výhody tohoto jazyka spadá jeho multiplatformost, vysoká podpora na hostingových službách a velmi široká uživatelská základna (což usnadňuje vývoj).

2.4 JavaScript

JavaScript je multiplatformní, objektově orientovaný skriptovací jazyk, který se zpravidla používá jako interpretovaný jazyk pro webové aplikace, často vkládaný přímo

do (X)HTML kódu. Jeho pomocí jsou především ovládány interaktivní prvk> v rámci dokumentu.

Skripty v JavaScriptu jsou obvykle vykonávány až v počítači (prohlížeči) klienta.

To znamená, že se musejí jejich zdrojové kódy předem stáhnout ze serveru, z čehož vyplývají určitá bezpečnostní omezení. Zároveň s tím souvisejí vyšší nároky na přenos dat. Toto ovšem prohlížeče řeší tak, že pokud je skript přiložen v externím souboru, tak daný soubor uloží do pamčti a při každém dalším požadavku ho nestahují.

2.5 SQL

SQL (Structured Query Language - strukturovaný dotazovací jazyk) je jazyk, který se používá pro práci s daty v relačních databázích. Jeho příkazy se dčlí na čtyři základní skupiny:

1. manipulace s daty (SELECT, INSERT, UPDATE, DELETE, atd.) 2. definice dat (CREATE, ALTER, DROP, atd.)

3. řízení práv (GRANT, REVOKE)

4. řízení transakcí (START TRANSACTION, COMMIT, ROLLBACK) Podrobnější informace o tomto jazyku lze dohledat v [8].

2.6 nadstavby

Jelikož práce se základními jazyky je velice zdlouhavá a vysoce náchylná k vytvoření všemožných chyb, byly použity určité nadstavby (fřameworky) pro jednotlivé technologie. Cílem fřameworků je převzetí typických problémů dané oblasti, čímž se usnadní vývoj tak, aby bylo možné se soustředit pouze na konkrétní zadání.

V následujících kapitolách budou vysvětleny základní principy použitých

„nadstaveb". Důraz bude kladen zejména na PHP aplikační framework a to z důvodu snazší orientace v případě nutnosti do aplikace jakkoliv zasáhnout.

2.6.1 PHP - Nette Framework

Nette Framework je framework pro vývoj webových aplikací v programovacím jazyku PHP verze 5. Zaměřuje se na minimalizaci bezpečnostních rizik

a znovupoužitelnost kódu. Z toho vyplývá i to, že je z velké části založen na používání komponent, ze kterých se výsledná aplikace skládá. Jeho autorem je český vývojář, který se navrhováním webových aplikací včnuje již od konce 90. let minulého století, David Grudl.

Minimální požadavky frameworku je PHP ve verzi minimálnč 5.2.0. ovšem s příchodem PHP verze 5.3 dokáže pracovat výkonnéji, nejen využitím jmenných prostorů.

Mezi hlavní přednosti, díky kterým byl tento fřamework zvolen patří:

• zabezpečení - technologie eliminující výskyt bezpečnostních dčr

• ladění - výkonné ladící nástroje (třída Debug)

• výkon - dle testu [9] jeden z nejvýkonnějších

• aktivní komunita - stále rostoucí, česká a především velice aktivní

• moderní technologie - MVC, podpora AJAX, DRY, KISS

• doplňky - užitečné komponenty, znovupoužitelnost kódu

Další příjemnou věcí je skutečnost, že fřamework je velice úsporně napsaný a neobsahuje spoustu běžně nepotřebných funkcí. To se o některých ostatních frameworcích říct nedá. Celý fřamework zabírá něco málo přes 700 kB a pokud je pro produkční server zvolena jeho komprimovaná verze, jedná se pouze o jeden soubor o velikosti cca 330 kB.

Model-View-Controller (Model-View-Presenter)

Základním stavebním kamenem frameworku je návrhový vzor (spíše softwarová architektura) Model-View-Controller (MVC), nebo přesněji Model-View-Presenter (MVP). Tato architektura rozděluje aplikaci do tří vrstev: datový model, uživatelské rozhraní a řídící logiku. Takto navržená aplikace je poté velice přehledná a její znovupoužitelnost je vysoká.

Dle MVC [10] je tedy aplikace rozdělena na:

• Model - přístup k datům a manipulace s nimi

• View (pohled) - převádí data reprezentovaná model uživateli •

• Controller (řadič) - reaguje na události od uživatele a zajišťuje zmčny v modelu či pohledu

Obrázek 3 - Architektura MVC

Logice frameworku však lépe odpovídá architektura MVP, kde Presenter zastupuje Controller. Zjednodušeně řečeno:

• model nemá vědět o tom, že nějaké view a presentery existují

• view o modelu vědět také nemusí (pasivní view), nebo naopak může data tahat přímo z něj

• presenter seznámí view s modelem (ne naopak) a realizuje uživatelské akce. Ty patří do tří kategorií: změna pohledu, změna stavu, příkaz pro model.

Autoloading tříd

Jelikož se v případě objektově orientovaného programovaní většinou ukládají jednotlivé třídy (rozhraní) do zvláštních souborů, je zapotřebí při jejich použití dané soubory nějak vložit do prováděného skriptu. To by mělo například za následek to, že v každém souboru presenteru by musely být všechny použité soubory (které se většinou dle konvence jmenují stejně jako třídy) vloženy například příkazem require_once ( ) . Framework pro toto však nabízí řešení a disponuje třídou RobotLoader pro automatické načítání tříd. Díky ní, už není potřeba dávat pozor, zda je daná třída vložena na správném místě. Navíc se požadovaný soubor vloží až ve chvíli, kdy je skutečně potřeba.

Eliminace chyb , I pro tuto problematiku nabízí fřamework kvalitní pomocníky (lze je ale

samozřejmě využít i zvlášť). Rozlišuje dva základní režimy, ve kterých server běží.

Vývojové a produkční. Fřamework má integrovanou autodetekci těchto dvou režimů (dle IP adresy serveru). Ve vývojovém režimu se snaží podat co nejdetailnější informace (a chyby) potřebné pro programátora, v produkčním naopak veškeré informace skryje, popřípadě chyby loguje do souboru (nebo odesílá na mail).

V první řadě obsahuje třídu Debug, která velmi přehledně zobrazuje veškeré vzniklé chyby v aplikaci a zároveň podává informace o jejím aktuálním stavu. Tato třída zároveň obsahuje několik nástrojů pro srozumitelný výpis jakýchkoliv proměnných.

Dále obsahuje metody pro spolupráci s rozšířením FireBug prohlížeče Firefox, kde komunikace probíhá pomocí samostatného kanálu (prostřednictvím HTTP hlaviček).

Routování, Cool URL

Velkou výhodou frameworku (na rozdíl od většiny ostatních) je skutečnost, že je možné nastavit tvar URL adres až jako poslední věc. Při programování se v podstatě volají funkce jednotlivých tříd, nikoliv konkrétní URL. Tento model úspěšně snižuje možnost vzniku chyb (například duplicitním definováním - vše se nastavuje jen jednou).

Formuláře

Základem téměř každé webové aplikace jsou formuláře a jeho prvky. I pro tuto část nabízí velmi silné prostředky - třídu Form (popř. jejího potomka AppForm, v případě využití uvnitř Nette aplikace). Její pomocí jsou formuláře ochráněny před XSS (Cross-Site-Scripting) - všechny vstupy ošetří escapovaním. Dále nabízí podporu pro CSRF (Cross-site Request Forgery) i jiné možné útoky. Zároveň obsahuje velmi silné validační prvky (jak na straně serveru, tak u klienta) a pokud se jedná o běžný formulář, postará se i o jeho vykreslení. Příklad definování (i vykreslení) přihlašovacího formuláře by mohl vypadat následovně:

! 1. $form = new Forra(); , : 2 . $ form->addText('jméno','Login')

: 3. ->addRule(Form::FILLED,'Zadejte login');

' 4. $form->addPassword('heslo','Heslo')

! 5 . ->addRule (Form: : FILLED, ' Zadejte heslo')';

: 6. $form->addSubmit('login','Přihlásit') ;

; 7. echo $form;

Popsané vlastnosti a možnosti tohoto frameworku jsou pouze nejzákladnější skutečnosti. Pro bližší porozumění, jak framework pracuje, je vhodné odkázat na příručku programátora [11], která obsahuje spoustu cenných informací jak pro začátečníka, tak pro zkušeného programátora. Mimo jiné je zde detailně popsán životní cyklus presenteru [12] a doporučená adresářová struktura [13].

2.6.2 PHP databázová vrstva DIBI

Úkolem databázové vrstvy je zejména ulehčit práci programátorům (zjednodušit zápis SQL příkazů, snadný přístup k metodám), eliminovat výskyt chyb, zajistit přenositelnost mezi databázemi (automatická podpora konvencí, formátování, sjednocení základních funkcí) a samozřejmě KISS (Keep It Simple, Stupid - tj. „udržuj to jednoduché, hlupáku").

Autorem této knihovny je opět David Grudl. Z tohoto důvodu je vysoce kompatibilní s Nette frameworkem a s jejími ladícími nástroji, kde je její použití ještě jednodušší. Lze ji ale samozřejmě použít i v jiných projektech.

Obsahuje několik různých způsobů zápisu SQL příkazů. Mezi ně patří například zápis pomocí statických funkcí se sérií parametrů:

1. $pole = array(

2. 'email' => 'test@example.com', 3. 'aktivni' => TRUE,

4. );

5. dibi::query('INSERT INTO [uživatele]', $pole);

6 .

7. dibi::query('UPDATE 'uživatele' SET ', $pole, 'WHERE 'id'=%i', 25);

Další metoda je zápis za pomocí třídy DibiFluent ve stylu fluent interfaces (zřetězováním metod - čili každá tato funkce vrací daný objekt DibiFluent).

: 1. $vysledek = dibi::select('iď) . : 2. ->from('uživatele')

: 3. ->innerJoin('role')

; 4. ->on(1 uživatele.role = role.název')

! 5. ->where('uživatel.jmeno=%s1Novák') : 6. ->orderBy('email')

[7. ->fetchAll();

Jak je z uvedených kódů zřejmé, tato vrstva pracuje s tzv. „modifikátory", které zajišťují ošetření vkládaných proměnných podle jejich typů. Základní modifikátory jsou následující:

% s string

%sN string, ale" se přeloží jako NULL

%bin binární data

%b boolean

%i %u integer

%iN integer, ale 0 se přeloží jako NULL

%f float

%d datum (očekává string nebo integer)

%t datum & čas (také string či integer)

%n identifikátor (tedy název tabulky či sloupce)

%sql SQL - řetězec ponechá beze změny

%lmt speciální - určuje limit

%of s speciální - určuje offset

%ex speciální - expanduje pole

Tabulka 2 - základni modifikátory SQL příkazů, převzato z 114)

Dále existují také modifikátory pro formátování polí, které usnadňují zápis více hodnot. Jejich popis a jiné užitečné informace je možné najít v [14],

2.6.3 jQuery

Javascriptový framework jQuery [15] slouží především pro usnadnění práce s jednotlivými prvky (X)HTML dokumentu. Jelikož je javascript vykonáván až na straně klienta, může být jeho funkčnost v různých prohlížečích jiná (zejména, pokud se jedná o prohlížeč Internet Explorer). Tudíž je běžně nutné psát skript vícekrát pro různé rodiny prohlížečů. Framework jQuery má, mimo jiné, za úkol tyto nedostatky eliminovat a při jeho správném použití se toto nemusí většinou vůbec řešit. Dále také nabízí podporu pro asynchronní výměnu dat (AJAX), kaskádovými styly (CSS) a obsahuje i funkce pro provádění animací.

Mezi jeho hlavní výhody patří zejména velikost (komprimovaná verze cc^ 24 kB, ze serveru se stahuje pouze jednou, potom zůstává v paměti prohlížeče), velká a aktivní uživatelská základna (existuje spoustu doplňků a rozšíření) a již zmíněná podpora ve většině prohlížečů.

Filozofie se snaží zajistit (stejně jako u CSS) co nejvyšší separaci různých jazyků.

Principiálně se tomuto říká nevtíravý (unobtrusive) JavaScript. Proto by se měl veškerý kód nacházet ve zvláštním souboru, který se (spolu s vlastním frameworkem) k (X)HTML dokumentu přiloží. V něm se teprve přistupuje k jednotlivým prvkům a s těmi se pracuje.

Nejzákladnějším konceptem jQuery je funkce „$", což je vlastně alias pro jmenný prostor ,jQuery". K jednotlivým elementům dokumentu se přistupuje pomocí tzv.

selektoru, které jsou kombinací CSS 1-3, XPath a dalších funkcí, například:

1. // zobrazeni skrytych spanu 2. $ ( " s p a n : h i d d e n " ) . s h o w ( ) ; 3.

4. // prvni, poslední, druhy obrázek 5. $ ( " i m g : f i r s t " ) ;

6. $("img:last");

1 . $ ( " i m g : e q ( 2 ) " ) ;

8 . 9. / / všechny textove inputy z formuláre s ID formulár 10. $("#formular : i n p u t [ t y p e = t e x t ] " ) ;

3 Vlastní aplikace

[3.1 Princip

Uživatelé systému jsou rozděleni na dvě role - administrátor a řeSitel.

Administrátor nejprve vytvoří projekt, tzn. vyplní jeho název (označení), přiřadí konkrétnímu řešiteli, který na něm bude pracovat. V druhé fázi k již vytvořenému projektu importuje seznam kandidátů, které bude nutné zpracovat. Po vložení těchto kandidátů máme ke každému jeho tvar, četnost a několik jeho charakteristických okolí v rámci zdrojového korpusu, ze kterého byl seznam vytvořen.

Takto založený projekt je připraven pro zpracování řešitelem. Každý řešitel má samozřejmě přístup pouze ke „svým" projektům. Po vybrání konkrétního projektu začíná vlastní práce. Zde postupně projde všechny kandidáty na přidání do slovníku a vyplní k nim potřebné informace. Každého kandidáta může smazat (respektive označit ho jako „smazaný"), v případě, že se jedná o zkratku nebo překlep, tuto skutečnost zaznamená. Samozřejmě může slovo opravit (zejména jedná-li se o překlep), napsat poznámku, změnit jeho jazyk (v případě, že se nejedná o český termín).

Dále je možné každý termín velice snadno a hlavně rychle vyhledávat v různých internetových vyhledávačích - ať už na serveru Google (zde se využije označení jazyku slova - výsledky vyhledávaní se omezí jen na vybraný), nebo ve vyhledávači cizích slov.

Zároveň má uživatel možnost nahlédnout do kompletního slovníku (respektive se dotázat, zdaje či není opravený tvar slova již ve výsledném „velkém" slovníku) a ušetřit si tímto způsobem práci, aby nemusel dělat něco, co již provedl někdo jiný. Toto je vhodné zejména u překlepů či chyb ve slovech. Například se v seznamu kandidátů objeví slovo „interdiciplinármnľ, zde je vidět písmeno „m", které je navíc. Řešitel toto slovo opraví a v tu chvíli má možnost se systému dotázat, zda je slovo

„interdiciplinární" již obsaženo ve „velkém" slovníku. Ten mu danou skutečnost potvrdí a tím pádem se o toto slovo uživatel již nemusí starat a označí ho jako smazané.

Při vyplňování údajů o slově je navíc vidět slovo v několika nečastějších kontextech, poněvadž někdy je opravdu těžké vědět, co dané slovo má znamenat. Navíc řešitel v mnoha případech ani nemá přístup ke korpusu, ze kterého byl seznam vytvořen.

Nejdůležitější částí práce na konkrétním kandidátovi je vyplňovali jeho výslovností, ze kterých se automaticky generují jejich fonetické transkripce, které jsou vlastně tím nejdůležitějším výstupem této aplikace.

Po zpracování veSkerých kandidátů, řešitel tento projekt označí jako hotový a administrátor si exportuje výsledek v textovém souboru, který následně zpracuje, porovná s již existujícím slovníkem a vygeneruje nový, který opět nahraje zpět na server.

Kdykoli v průběhu práce na projektu má administrátor možnost nahlédnout na jeho aktuální stav a zpracované kandidáty. Pokud najde nějakou nesrovnalost, může ji opravit s tím, že se tato skutečnost opět zaznamená (tzn. nové hodnoty se uloží a navíc se poznamenají i jejich původní hodnoty), aby vznikla jakási zpětná vazba řešiteli. Ten poté u takto opravených slov vidí, kde udělal chybu, aby sejí mohl pro příště vyvarovat.

Celý systém je založen na seznamu pro řízení přístupů (ACL - Access Control List), tudíž je možné libovolně vytvářet a spravovat uživatele, role, zdroje, akce a spojovat je do konkrétních pravidel přístupů. Ve výsledku si ale nedokážu smysluplně představit využití více rolí než administrátor a řešitel, ale ta možnost je teoreticky i prakticky uskutečnitelná.

3.2 Uchovávání dat

Veškerá data, vytvořená jakýmkoliv uživatelem aplikace (ať už se jedná o uživatele typu administrátor, nebo řešitel), bude nutné uchovávat. Jelikož se snažíme minimalizovat počet uživatelských operací, které jsou potřeba pro předávání výsledků mezi administrátorem a řešitelem, budou se ukládat v databázi v průběhu práce na jednotlivých projektech. Nebude tedy zapotřebí si dosažené výsledky průběžně ukládat, aby bylo možné se k nim později vrátit, nebo abychom se nebáli ztráty vytvořených dat v případě kolapsu systému.

Pro testovací účely byl použit databázový server MySQL, ovšem celá aplikace je navržena tak, aby bylo možné jednoduše změnit ovladač a tím pádem přistupovat k jinému druhu databáze. Toto je možné změnou jediného řádku v konfiguračním souboru

aplikace (config.ini v adresáři app).

Díky použití databázové vrstvy dibi [14] je možné použít například MySQL, PostgreSQL, SQLite, MS SQL, Oracle nebo Access.

3.2.1 Ukládaná data « V první řadě je potřeba ukládat informace o uživatelích systému, zejména jméno,

příjmení, kontaktní email pro případnou korespondenci, přístupové údaje (přihlašovací jméno a heslo) a jejich roli v rámci systému..

Dále je nutné uchovávat data o konkrétních projektech - kdy byl projekt vytvořen, jeho poslední zmčna (např. pro zpětnou kontrolu administrátorem), referenci na uživatele (řešitele), který jej má na starosti, název (označení - pro lepší přehlednost), popř. nějaké poznámky či připomínky. S tímto souvisí i informace o konkrétních slovech (kandidátech), jejich výslovností a fonetických přepisů. U slov je důležité vědět několik informací:

data, se kterými se projekt zakládá - tvar, četnost a charakteristické okolí slov v rámci zdrojového korpusu

data, která vznikají prací na projektu - zda se jedná o zkratku, překlep, jestli je slovo označeno jako uložené, popřípadě jeho jazyk (česky, slovensky, polsky), seznam jejich výslovností a souvisejících fonetických přepisů, předchozí uložené hodnoty (možnost zpětné vazby v případě, že administrátor bude muset cokoliv po řešitelovi opravit)

Další důležitá data k ukládaní jsou informace o seznamu pro řízení přístupu do systému - role, zdroje, akce a jejich propojení.

V poslední řadě je potřeba nějakým způsobem ukládat kompletní slovník, který vzniká spojováním výstupů jednotlivých projektů a jejich následnou filtrací, porovnáváním a normalizací.

3.2.2 Návrh databáze

_J pcMleges v r idTJNYINTM / rw«e VAACMAR(64)

razen> INT(ii)

• ad i

. >d B IONT (20) • rafes alowad ENlXCV ,>ť) »>dT*ffMT(4)

• r«zaii mr(ti} parentjd TWV1NT(4) pnvlegejd T1NYMT(4) » iwe YARCHAR(64) . restwcejd TOY1NT(4) > razeni WT(ll) 1 f rotejd TBTř WT(4)

•

3 resources • t idTlNY]NT(4)

» flint VARCMAR(64) - razeni DMT(n) t idTlNY]NT(4)

» flint VARCMAR(64) - razeni DMT(n)

3 uživatel

I . I d l N T ( l l )

i jnero VAR01AR(60) I - pnynan VARChíRílGG)

emaá VARCHAR(IOO) ogrVMOÄÍSO;

I - hesio (X«t(4D)

5 *poN«iCHM(l) i I o-eafeC INT(ix)

OOOiTEKT V t o vAaoi«(2ocr, -«oxer INT(ll)

| i rolt TJNYWTM

3 P

r «jíht(:i)

rHWWíWnil) aosecr jrv* riT(n) roono BTTÍI) . JUJi—> *1 TB(T

jorr-«i2"B(T

->a»v 1005 ' uMMjd MT(lO

slevo

i Mr.d(jaw>u VMO<«L(éO) VJRO-ARÍ60) xtr-er-ks i ARCHAR(60/

. zkratka BT(1)

<preléeelIT(y eMMMr(ii) i u m B T ( l )

/ jt_uo2Eíio_do_slo\r>lai 8IT(1) o-«r««Bf«ae_wo> TCXT .JU^CHARCZ)

r tnféňjó MT(ll) pu«a4i>M Ibl

J riovnfc

i stovo v ARCH AR (100;

ftaneedtcjrcMadyTEXT i

3 vydovnost

r i d B K W r ( l l )

výstavnost V4RO0>R(45}

fbncBdcy.toar ViRCHAR(45) I siovo VARCHAR(60) f prqjťrtj d INT(11)

Obrázek 4 - ER diagram použité databáze

Základním stavebním prvkem je entita uživatel, která uchovává informace o uživatelích. Zde je, dle mého názoru, vše jasně zřetelné z obrázku Obrázek 4 - ER diagram použité databáze. Za zmínku stojí snad jen skutečnost, že heslo se v databázi

neukládá přímo, ale je „zakódované" pomocí jednosměrného shal algoritmu, který vytvoří 40znakový hexadecimální otisk vstupního řetězce.

Část databáze, která se stará o ukládaní jednotlivých projektů se skládá ze tří entit:

projekt, slovo a výslovnost. Projekt obsahuje základní informace o projektu a referenci

na uživatele (kdo má projekt na starosti). Projekt je se slovem ve vztahu 1 : N, tzn.

jeden projekt může obsahovat více slov. Slovo tedy obsahuje jeho konkrétní data a j e

identifikováno tvarem dle seznamu a konkrétním projektem (projekt id). Slovo je

s výslovnosti opět ve vztahu 1 : N, což znamená, že jedno slovo může obsahovat více

výslovností. Výslovnost proto musí kromě jednotlivých tvarů obsahovat i referenci na

slovo a projekt.

Další sekce se zabývá již zmiňovaným ACL. Zde jsou čtyři entity:

• role - ty mohou vytvářet stromovou strukturu, tudíž je zde kromč názvu i reference na sebe samu

• resources — zdroje

• privileges - akce

• acl - spojují výše uvedené tři entity do skutečných pravidel, například:

,Jiole administrátor má se zdrojem projekt akci editovat povolenou/zamítnutou."

Zde je dobré zmínit, že takto definovaná pravidla lze řadit a tím pádem si ulehčit práci s jejich definováním. Například nejprve povolit všechny akce na všech zdrojích (což se dá zařídít jediným pravidlem) a poté zakázat jen jednu akci na konkrétním zdroji. V obráceném pořadí by pravidla samozřejmě fungovala odlišně.

Poslední částí databáze je entita slovník, která obsahuje již vytvořený, administrátorem potvrzený a nahraný „velký slovník".

3.3 Serverová část aplikace

Tato část zpracovává veškerou komunikaci na serverové úrovni, tzn. vše, co se odehrává na vzdáleném stroji. Když uživatel cokoli změní, aplikace odešle požadavek zpět na server, aby si aktualizoval svá data, popřípadě odeslal odpovídající odezvu zpět do klientova prohlížeče.

Dle architektury frameworku je celá aplikace rozdělena do několika menších celků, kde každý plní svoji určitou funkci tak, aby byl co nejvíce nezávislý. Zde tedy můžeme hovořit o těchto částech:

• správa oprávnění, rolí a akcí

• správa uživatelů

• přihlašování a odhlašování uživatelů

• seznam projektů

• práce na konkrétním projektu

• správa „velkého" slovníku

Každá tato část je zastoupena třemi vrstvami, jak je zřejmé z frameworku.

Pohledy (views) nemá asi smysl představovat, jelikož pouze převádějí připravená data do výsledného XHTML dokumentu. Nejdůležitější k porozumění principu aplikace jsou tedy presentery a modely.

3.3.1 Základ

Jelikož využíváme objektově orientovaného principu programování, můžeme si nadefinovat společného předka pro všechny použité presentery - BasePresenter. Ten se bude starat o záležitosti, které jsou pro všechny potomky společné. Zde je tedy na místě vytvořit komponentu pro navigační menu:

' 1. public function createComponentNavigation($name) { 2. $menu = new Navigation($this, $name);

3. /*

4. vytvořeni stromové struktury navigace...

5. */

6 . }

Nadefinovat funkce pro přidávání potřebných CSS (kaskádové styly) a JS (javascript) souborů do šablon:

1. protected function addCss($css) { 2. /* logika */

3. } 4 .

5. protected function addJs($js) { 6. /* logika */

7. >

8.

9. protected function afterRender() { 1 0 . / *

11. zaregistrováni vytvorenych poli JS a CSS 12 . souboru do šablony

13. */

14. }

Vytvořit zástupnou funkci pro získávání proměnných z GET parametrů getQueryParam () a v poslední řadě veškerou logiku pro řízení přístupu v metodě s t a r t u p ( ) , která nejprve zavolá metodu s t a r t u p () svého předka a poté vykoná svůj kód.

1. protected function startup() { 2. parent::startup();

3.

4. /*

5. přidáni zakladnich CSS a JS souboru 6 . * /

JÍ.

8. $user = Environment::getUser();

9. if ($user->isAuthenticated()) { 10. //pokud je uživatel autentizovan 11. } else {

12. //pokud ne 13. }

14.

15. // kontrola oprávněni na akce/zdroje

16. if (!$user->isAllowed($this->name, this->view)) { 17. //presmerovani na přihlášeni

18. $this->redirect('Auth:login') ; 19. } else {

20. //pravo udeleno 2 1 . }

22. }

Tato pravidla samozřejmě kontrolují přístupy k jednotlivým akcím (pohledům) nad konkrétními zdroji (v tomto případě presentery, které budou od tohoto dědit).

Jelikož ale může nastat situace, kdy potřebujeme takto „ochránit" i jednotlivé modely, jsou proto podobné podmínky aplikovány současně i na jejich úrovni. To je vhodné i z hlediska zvýšené bezpečnosti. Tomuto procesu se říká autorizace a ve výše uvedeném zdrojovém kódu se jedná o druhou podmínku ($user->isAllowed ()).

První podmínka ($user->isAuthenticated ( ) ) zjišťuje, zda je uživatel přihlášený, čemuž se říká autentizace.

3.3.2 Autentizace

Pro řešení problematiky přihlašování a ohlašování uživatelů je vytvořen jeden presenter - AuthPresenter a k němu odpovídající model MyAuthenticator implemetující rozhraní frameworku IAuthenticator.

V autentizačním presenteru je zaprvé nutné vytvořit komponentu pro přihlašovací formulář, o toto se stará metoda:

j 1. protected function createComponentLoginForm() { 2. $form = new AppForm();

3. /*

4. Definováni formuláre 5. */

6. return $form;

7 . 1

Další důležité metody jsou actionLogout () pro odhlášení ze systému a loginFormSubmitted (), která je volána při odeslání přihlašovacího formuláře.

Zde dojde k ověření zadaných přihlašovacích údajů pomocí autentizačního handleni popsaným dále.

V těle třídy MyAuthenticator přepisujeme jedinou nutnou metodu authenticate (), která má jako vstupní parametr asociativní pole nutných údajů k přihlášení (uživatelské jméno a heslo) a vrací novou identitu (new Identity ()) přihlášeného uživatele, nebo vyhazuje výjimku v případě jakékoliv chyby.

3.3.3 Uživatelé

Stěžejní funkce pro správu uživatelů se nacházejí v presenteru UserPresenter:

• createComponentUserForm () o formulář pro přidání a editaci uživatele

• createComponentUserGrid() o přehledová tabulka uživatelů

• handleSaveForm()

o funkce volaná po odeslání formuláře

Související třída modelu se jmenuje Users, ve které jsou definovány potřebné metody: výběr uživatelů (findAll(), find()), editování (update ()), vkládání (insert ()) a mazání (delete ()).

Při vkládání i editaci uživatelů je respektován základní požadavek pro přihlašovací jméno - je kontrolováno, zda ho již v systému nepoužívá někdo jiný.

Zároveň, jak už bylo naznačeno, se heslo neukládá v prosté textové podobě. Z důvodu zvýšené bezpečnosti je nejprve spojeno s přihlašovacím jménem a výsledný řetězec je prohnán jednosměrným algoritmem shal. Teprve takto vygenerované heslo je uloženo do databáze. Stejný postup je použit při každém pokusu o autentizaci, tzn.

neporovnávají se přímo hesla, nýbrž jejich otisky.

3.3.4 Slovník

Práce se slovníkem je vskutku jednoduchá. Stará se o ní presenter SlovnikPresenter a související model Slovník.

V presenteru se jedná o tyto funkce:

• createComponentUploadForm() o formulář pro odeslání souboru se slovníkem

• createComponentSlovnikGrid() o přehledová tabulka slov ve slovníku

• uploadSlovnik()

o funkce volaná po odeslání formuláře

V modelu opět najdeme základní metody: deleteSlovnik () - smaže celý slovník, loadFile () - načte odeslaný soubor do databáze, f indSlova () - výbčr všech slov a v poslední řadě funkce checkWord () - zjištění, zda konkrétní slovo již ve slovníku je.

V této části bylo při vývoji potřeba počítat s tím, že soubor odesílaný na server, může obsahovat kompletní slovník. Takovýto soubor může zabírat desítky MB dat a mít statisíce řádků. Proto ho nebylo možné načítat standardními postupy. Byla by to pro server velká časová i paměťová zátěž. Z tohoto důvodu byla využita funkce přímo v jazyku MySQL (LOAD DATA INFILE). Pro ostatní typy databáze se bohužel tato funkce jmenuje a používá jinak, proto je to jediné místo, kde je potřeba zasáhnout v případě výběru jiné databáze.

3.3.5 Access Control List - seznam pro řízení přístupu

Správu seznamu pro řízení přístupu má na starosti presenter AclPresenter a model AclModel. Ve své podstatě můžeme tuto část rozdělit na 4 velice podobné části - zdroje, akce, role a pravidla.

Důležité metody presenteru:

• createComponentResourcesForm() o formulář pro přidání dalšího zdroje

• createComponentResourcesGrid() o přehledová tabulka zdrojů umožňující řazení

• handleSaveResource() o funkce volaná po přidání zdroje

• handleSortResource() o funkce volaná po přeřazení zdrojů

Pro akce, role a pravidla jsou použity obdobné metody. Řazení bude určovat pořadí načítaných položek, proto má smysl zejména pro role (postupné dědéní - nemůže existovat role, která dědí od jiné, jež zatím neexistuje) a pravidla (postupné vytváření- např. nejprve vše zakážeme a pak jednu konkrétní akci povolíme).

Navíc je zde ještě jedna funkce handle De lete (), která má dva parametry - co smazat (role, zdroj, akce, pravidlo) a identifikátor konkrétní položky.

V modelu jsou obsaženy metody pro výběr všech čtyřech části - getRoles (), getResources (), getPrivileges () a getRules (). Kromě tohoto modelu se využívá i obecnějšího, DbTable, který obstarává základní funkce nad databázovou tabulkou.

3.3.6 Správa projektů

Správa projektů je pro přehlednost rozdělena do dvou celků:

• přehled všech projektů, jejich vytváření a editace

• detail konkrétního projektu a práce na něm

V této podkapitole se budeme zabývat první částí, jež obsluhuje presenter ProjektyPresenter. Jeho důležité metody jsou následující:

• createComponentTextParser()

o Vytvoří předem vytvořenou komponentu, která obsahuje formulář pro odeslání souboru a má za úkol tento soubor, plný kandidátů včetně jejich četností a charakteristického okolí, načíst k danému projektu.

• createComponentProjektForm() o formulář pro přidání a editaci projektu

• createComponentProjektGrid() o přehledová tabulka projektů

o obsah závislý na roli přihlášeného uživatele - řešitel vidí pouze své projekty a nemůže s nimi provádět všechny operace

• handleDelete() o smaže projekt

• handleSetHotovo() o označí projekt za hotový

• createComponentConfirmForm()

o komponenta pro potvrzování akcí nad projekty - v tomto případě mazání a označování za hotový

• formSubmit()

o funkce volaná po odeslání formuláře projektu

Jako model slouží zejména specifický Project. Jeho metody, potřebné k obsloužení této části jsou: deleteProject () - smaže projekt, setProjectHotovo () - označí jako hotový, findAll() - vybere všechny.

Některé základní operace opět obstarává obecný DbTable.

3.3.7 Práce na projektu

Tento segment aplikace se stará především o zpracovávání kandidátlů konkrétního projektu a následný export vytvořených fonetických překladů. O správnou funkci se stará presenter ProjektPresenter. Klíčové metody:

• createComponentKandidatiList()

o komponenta pro seznam nezpracovaných kandidátů

• createComponentUlozeneList()

o komponenta pro seznam již zpracovaných kandidátů

• createComponentCandidateDetail() o komponenta pro detail konkrétního kandidáta

• handlePracujNaSlove()

o funkce, která přiřadí komponentě detailu konkrétního kandidáta

• handleDeleteSlovo()

o označí kandidáta jako smazaného (nepotřebného)

Za zmínku stojí ještě některé vykreslovací (exportovací) funkce:

renderExportMain (), resp. renderExportSub {), které převedou výsledky práce na konkrétním projektu do textového souboru a ten nabídnou ke stažení. První metoda exportuje všechny uložené kandidáty (pouze v případě, že se neopravily na spojení více slov — např. při překlepu s vynecháním mezery) a jejich jednotlivé fonetické přepisy. Druhá exportuje pravý opak, tzn. pouze ty kandidáty, které se opravily na spojení slov.

Pro větší přehlednost byly pro tyto potřeby vytvořeny dvě speciální komponenty:

• CandidateDetail

o zpracovávání konkrétního kandidáta

• WordList o seznam slov

o slouží jak pro seznam kandidátů, tak pro seznam již uložených slov

Komponenta WordList

Tato komponenta se stará o zobrazení předem definovaného seznamu slov, umožňuje jejich filtraci a řazení. Její nejdůležitější proměnné jsou ty, které ovlivňují zobrazovaná data: $orderBy, $orderSmer, $filter, $showSmazane a $pouzeOpravene. Jejich význam asi nemá smysl rozebírat, vše je jasné z jejich názvu. Důležitější je skutečnost, že tyto proměnné by měly být stále (persistentní), tzn.

měly by se přenášet s každým požadavkem na stránce, kde bude tato komponenta

použita. Nette framework pro tyto potřeby používá phpDoc syntaxi komentáře a podmínku, že daná proměnná musí být deklarována jako veřejná. Pokud toto dodržíme, nemusíme se o nic jiného starat a vše se děje zcela automaticky. Například proměnná uchovávající informaci o tom, podle Čeho mají být slova řazená, je definována takto:

: /** gpersistent string */

: 2. public $orderBy;

Mezi nejdůležitější metody této komponenty patří:

• createComponentOrderBar()

o formulář, který se stará o řazení a filtraci vlastního seznamu slov

• createComponentSelectBox() o vlastní seznam slov

• handleSaveOrder()

o funkce, jež je volána po odeslání formuláře na řazení o nastaví komponentě potřebné parametry

Komponenta CandidateDetail

Úkolem této komponenty je zobrazení a práce s konkrétním kandidátem.

Vyplňování potřebných informací a výslovností. Obsah této vykreslitelné komponenty je identifikován pomocí dvou proměnných - $candidate (textový tvar kandidáta) a $pro j ectld (číselný identifikátor projektu). Mezi významné metody patří:

• createComponentForm()

o vytvoří celý formulář, který obsahuje jak prvky pro základní informace o kandidátovi, tak prvky pro jednotlivé výslovnosti a související fonetické transkripce

• ulozSlovoO

o funkce, která je volána po odeslání formuláře

V těle metody ulozSlovoO je několik podmínek, které řídí průběh skriptu.

•

Nejprve zjišťujeme, zda nebyl formulář odeslán pomocí tlačítka „smazat", pokud ano, označíme kandidáta za smazaného. Poté testujeme, zda je přihlášen uživatel (administrátor), jehož úpravy chceme zaznamenat včetně předchozích hodnot (pro zpětnou vazbu řešiteli). V tom případě si připravíme požadovanou strukturu, aby mohla být později uložena. Následuje podmínka, zda byl formulář odeslán tlačítkem, které má za úkol, kromě uložení hodnot, kandidáta rovnou zařadit mezi zpracované. V poslední řídící podmínce testujeme, zda formulář nebyl náhodou odeslán tlačítkem pro zjišťování, jestli už daný opravený tvar není ve výsledném slovníku.

Pro účely rychlého vyhledávání významu slova na internetu byla vytvořena jedna užitečná třída Hledač. Zároveň je v komponentě přítomna metoda

initializeHledaci ( ) , která definuje všechny použité vyhledávací zdroje:

I 1. priváte function initializeHledaci() {

1 2. $this->hledaci[] = new Hledač('google-cs',

'http://www.google.com/search?hl=cs&lr=lang_cs&q=[[slovo]]

&btnG=Search', 'Vyhledat na googlu (CS)');

: 3.

4. // definice dalsich hledačů : 5. }

Zde je vidět, že konstruktor přijímá 3 parametry:

1. řetězec, který bude použit jako identifikátor html elementu (hodí se pro následnou manipulaci v javascriptu)

2. řetězec reprezentující odkaz na daný server, kde je použita zástupná proměnná [ [slovo] ] reprezentující daného kandidáta. O její nahrazení a případné převedení (escapovaní) do podoby vhodné pro URL adresu se komponenta postará sama.

3. řetězec, který bude zobrazen jako text odkazu

Jako model tohoto problému je použita třída Slovo. Obsahuje základní funkce pro ukládání kandidáta: setUlozenoVeSlovniku (), setSmazano(), setZmenaSlova () - uloží připravenou strukturu s původními hodnotami slova před změnou, setVyslovnosti (), setSlovoMainlnf o () - uloží základní informace o kandidátovi. Dále obsahuje funkce pro načtení informací o slově:

getSlovoMainlnfo(), getVyslovnosti() agetVyslovnistiAssoc() - totéž jako předchozí, ovšem výsledek vrátí jako asociativní pole.

3.3.8 Propojení s knihovnou na generování fonetických transkripci

Hlavním cílem aplikace pro tvorbu diktovacích slovníků je získávání fonetických přepisů jednotlivých výslovností daného slova. Z toho důvodu je nutné vyplněné výslovnosti převést do fonetické abecedy. Tato problematika je velice složitá, jelikož obsahuje velký počet vysoce závislých podmínek. Protože se tímto problémem zabýval už dříve někdo jiný v rámci absolventské práce, dostal jsem k dispozici knihovnu napsanou v jazyce C, která byla zkompilována do jediného .dli (Dynamic Link Library) souboru. Obsahuje pro nás důležitou funkci, jež je definována následovně:

' 1. long _stdcall PhoneticTranscription (char* text, char*

pronunc)

První řetězec je vstupní text a druhý výsledný přepis. Na druhý ukazatel tak musí mít knihovna právo zapisovat a musí být alokován volajícím programem.

Původní myšlenka, že by se volání této funkce přesunula ke klientovi, tzn. že by přepis probíhal až v prohlížeči, nebyla dobrá. Nejenže by to z důvodu zabezpečení webových prohlížečů vůbec nemělo být možné - co kdyby se jednalo o virus a tím pádem by se mohl lehce šířit jen tím, že by uživatel danou stránku navštívil. Za druhé by se daná knihovna musela nějak dostat do klientova počítače a tam se zaregistrovat jako COM (Component Object Model) server. V poslední řadě je tato metoda závislá na tom, zda má klient ve webovém prohlížeči javascript vůbec povolený. Přínosem tohoto postupu by byla vysoká rychlost - nemuselo by se čekat na komunikaci se serverem.

Ovšem výše popsané nevýhody tuto skutečnost předčí. Pokud bude aplikace navržena tak, aby v případě zapnutého javascriptu žádala server asynchronně o generování fonetických přepisů a ten tento požadavek obslouží velmi rychle, bude to vhodné řešení.

V případě vypnutého javascriptu se výsledné přepisy vygenerují při uložení jednotlivých výslovností daného kandidáta.

Použití konkrétní knihovny ovšem stále není triviální. Jelikož knihovna neobsahuje COM server, není ji možné zaregistrovat přímo do systému. Proto je potřeba ji použít spolu s vhodným obalovačem (wrapperem). Pro tyto účely je vhodná knihovna DynaWrap [17]. Její dokumentace je ovšem k dispozici pouze ve francouzském jazyce, proto bylo potřeba hledat jinde [18].

Nejprve je potřeba knihovnu DynaWrap zaregistrovat do systému například pomocí příkazové řádky:

1. regsvr32 DynaWrap.dll

Pro práci s knihovnou byla vytvořena třída PhoneticTranscription:

1. class PhoneticTranscription {

2.

3. priváte static $com;

4. priváte static $returnedString;

5.

6. priváte static function initialize() {

7. self::$com = new COM(1DynamicWrapper',null,CP_UTF8);

8. self::$com->

R e g i s t e r ( " t r a n s " , * P h o n e t i c T r a n s c r i p t i o n1,,i = s ll) ; : 9. self::$returnedString =

new VARIANT(sprintf("%1024s", " ")) ;

! 1 0 . }

; 11.

12. public static function translate($slova) {

;13. self::initialize();

! 14. switch (gettype($slova)) {

| 15 I case 1array':

16. $out = array();

: 17. foreach ($slova as $slovo) {

| 18. $out[] = self::translateWord($slovo);

i 19. }

•20. return $out;

j 21. break;

j 22. case 'string¹:

: 23 - return self::translateWord($slova);

: 24. break;

; 25. default:

26. throw new Exception('Unsupported type of input v a r i a b l e¹) ;

! 27.

:

2 8 . }

! 29. }

\ 30.

: 31. priváte static function translateWord($slovo) { 32. $dwBSTRAddr=self::$com->

GetBSTRAddr(self::$returnedString) ; : 33 | self::$com->

PhoneticTranscription($síovo,$dwBSTRAddr);

34. return self::$com->

GetMemlnBSTRAddr($dwBSTRAddr, 0, 0);

35.

36. } 37. }