• No results found

TECHNICKA´ UNIVERZITA V LIBERCI Fakulta mechatroniky, informatiky a mezioborovy´ch studiı´

N/A
N/A
Protected

Academic year: 2022

Share "TECHNICKA´ UNIVERZITA V LIBERCI Fakulta mechatroniky, informatiky a mezioborovy´ch studiı´"

Copied!
54
0
0

Loading.... (view fulltext now)

Full text

(1)

Fakulta mechatroniky, informatiky a mezioborovy´ch studiı´

Studijnı´ program: Elektrotechnika a informatika Studijnı´ obor: Informacˇnı´ technologie

JavaScriptovy´ XML editor JavaScript XML Editor

Diplomova´ pra´ce

Autor: Bc. Jindrˇich Ru˚ zˇicˇka Vedoucı´ pra´ce: Ing. Pavel Tyl

V Liberci 21. 5. 2010

(2)

Zada´nı´ pra´ce

(3)

Prohla´sˇenı´

Byl jsem sezna´men s tı´m, zˇe na mou diplomovou pra´ci se plneˇ vztahuje za´kon cˇ. 121/2000 Sb., o pra´vu autorske´m, zejme´na § 60 — sˇkolnı´ dı´lo.

Beru na veˇdomı´, zˇe Technicka´ univerzita v Liberci (TUL) nezasahuje do my´ch autorsky´ch pra´v uzˇitı´m me´ diplomove´ pra´ce pro vnitrˇnı´ potrˇebu TUL.

Uzˇiji-li diplomovou pra´ci nebo poskytnu-li licenci k jejı´mu vyuzˇitı´, jsem si veˇdom povinnosti informovat o te´to skutecˇnosti TUL; v tomto prˇı´padeˇ ma´ TUL pra´vo ode mne pozˇadovat u´hradu na´kladu˚, ktere´ vynalozˇila na vytvorˇenı´ dı´la, azˇ do jejich skutecˇne´ vy´sˇe.

Diplomovou pra´ci jsem vypracoval samostatneˇ s pouzˇitı´m uvedene´ literatury a na za´kladeˇ konzultacı´ s vedoucı´m diplomove´ pra´ce a konzultantem.

Datum

Podpis

(4)

Podeˇkova´nı´

Me´ podeˇkova´ni patrˇı´ vsˇem, kterˇı´ se jaky´mkoliv zpu˚sobem podı´leli na tvorbeˇ me´ diplomove´ pra´ce.

Zejme´na pak tı´mto deˇkuji me´mu vedoucı´mu diplomove´ pra´ce Ing. Pavlu Tylovi za konzultace, pomoc prˇi vypracova´nı´, odborne´ rady a zkusˇenosti, ktere´ prˇispeˇly ke konecˇne´ verzi pra´ce.

(5)

Abstrakt

U´ kolem te´to pra´ce je napsat jednoduchy´ XML editor v jazyce JavaScript. Editor by meˇl beˇzˇet na straneˇ klienta a obejı´t se tak bez serveru. Cı´lem projektu je vyvinout editor tak, aby jej mohl vyuzˇı´vat i uzˇivatel bez podrobne´ znalosti jazyka XML.

Jednı´m z u´kolu˚ je prozkouma´nı´ jazyka JavaScript jako na´stroje pro vy´voj rozsa´hlejsˇı´ch projektu˚. Du˚lezˇita´ je technologie objektove´ho programova´nı´ a volba spra´vny´ch postupu˚, pomocı´

ktery´ch se da´ tato technika v JavaScriptu realizovat.

V pra´ci je vyuzˇita volneˇ dostupna´ JavasScriptova´ knihovna jQuery, ktera´ se v poslednı´ dobeˇ stala popula´rnı´ na poli programova´nı´ webovy´ch aplikacı´ v JavaScriptu. Da´le je v pra´ci pouzˇita technologie XSLT, ktera´ umozˇnˇuje nasazenı´ WYSIWYG rezˇimu. Ten se hodı´ zejme´na v prˇı´padeˇ kompaktnı´ch webovy´ch editoru˚. Aplikace je navrzˇena´ tak, aby byla dobrˇe rozsˇirˇitelna´ formou jQuery pluginu˚. Jednotlive´ jejı´ cˇa´sti lze snadno vyuzˇı´t i v jiny´ch aplikacı´ch. To mu˚zˇe usnadnit pra´ci i ostatnı´m vy´voja´rˇu˚m webovy´ch editoru˚.

Klı´cˇova´ slova

wysiwyg editor, jquery, javascript, www, xhtml, xml, xslt

(6)

Abstract

The purpose of this work is to develop simple XML editor in JavaScript. Another objective is to make an editor that everybody can use it even without a deep knowledge of XML language.

One of the goals is to inspect the JavaScript language as a tool for developing large projects.

Important is the technology of objective oriented programming and choosing the right method to achieve this technique in JavaScript.

I use the free JavaScript library jQuery in this work. It has been popular in the domain of web application development in last days. I also use the XSLT technology for the WYSIWYG mode realization which is popular mostly in compact web editors. The application is designed to be easilly expandable with custom jQuery plugins. The single parts of editor could be also used in another applications which could could make the work easier for another web editor developers.

Keywords

wysiwyg editor, jquery, javascript, www, xhtml, xml, xslt

(7)

Obsah

1 U´ vod 1

2 Objektoveˇ orientovane´ programova´nı´ a JavaScript 2

2.1 Vznik objektove´ho programova´nı´ . . . 2

2.2 Cˇisty´ a hybridnı´ jazyk . . . 2

2.3 Objekty, jejich vlastnosti a realizace v JavaScriptu . . . 3

2.3.1 Trˇı´dy a zapouzdrˇenı´ . . . 3

2.3.2 Trˇı´dy v JavaScriptu . . . 4

2.3.3 Pra´ce s instancemi . . . 5

2.3.4 Vazby mezi objekty a zası´la´nı´ zpra´v . . . 7

2.3.5 Princip abstrakce . . . 8

2.3.6 Deˇdicˇnost a polymorfismus v JavaScriptu . . . 9

2.4 Zhodnocenı´ prˇı´stupu k JavaScriptu . . . 13

3 Vy´voj JavaScriptove´ho XML editoru 14 3.1 Na´vrh aplikace . . . 15

3.2 Zpracova´nı´ dat forma´tu XML . . . 16

3.2.1 Parserova´nı´ XML do Document Object Modelu . . . 17

3.2.2 Validace XML . . . 19

3.3 Transformace XSLT . . . 21

3.3.1 XSLT a du˚vod jeho pouzˇitı´ . . . 21

3.3.2 Implementace XSLT procesoru . . . 22

3.3.3 Mozˇnosti vy´sledne´ho modulu pro XSLT . . . 23

3.4 Zvy´raznˇovacˇ syntaxe . . . 23

3.4.1 Na´vrh . . . 23

3.4.2 Implementace zvy´raznˇovacˇe syntaxe . . . 25

3.4.3 Vy´sledny´ plugin prakticky . . . 27

3.4.4 Klady a za´pory zvy´raznˇovacˇe . . . 28

3.5 WYSIWYG rezˇim . . . 28

3.5.1 Nejednoznacˇnost XSLT . . . 29

3.5.2 Rˇ esˇenı´ WYSIWYG rezˇimu . . . 30

3.5.3 Implementace WYSIWYG rezˇimu . . . 31

(8)

3.5.4 Pouzˇitı´ pluginu pro WYSIWYG rezˇim . . . 33

3.6 Uzˇivatelske´ rozhranı´ . . . 33

3.6.1 Prvky uzˇivatelske´ rozhranı´ . . . 34

3.6.2 Ovla´dacı´ panel . . . 35

3.6.3 Rezˇim rozbalovacı´ho stromu . . . 35

3.6.4 Dialogova´ okna . . . 37

3.7 Vy´sledna´ aplikace . . . 37

3.7.1 Konfigurace . . . 37

3.7.2 Testova´nı´ aplikace . . . 39

4 Za´veˇr 40

(9)

Seznam obra´zku ˚

1 Diagram trˇı´dy Vector2D . . . 4

2 Trˇı´da Vector2D v JavaScriptu . . . 5

3 Trˇı´da Vector2D v jazyce JavaScript pomocı´ vlastnosti prototype . . . 6

4 Instance Vector2D v jazyce JavaScript . . . 6

5 Trˇı´da XmlNode a jejı´ asociace . . . 8

6 Deˇdicˇnost trˇı´dy xmlNode . . . 9

7 Deˇdicˇnost v JavaScriptu . . . 10

8 Pomocna´ funkce pro deˇdeˇnı´ v JavaScriptu . . . 10

9 Deˇdicˇnost v JavaScriptu pomocı´ funkce inherit . . . 11

10 Polymorfismus v JavaScriptu . . . 12

11 Diagram trˇı´d XML editoru . . . 15

12 Document Object Model (zdroj: vlastnı´) . . . 17

13 Metoda pro nacˇtenı´ XML dokumentu . . . 18

14 Serializace XML veˇtve . . . 19

15 Princip XSLT (zdroj: vlastnı´) . . . 21

16 Metoda pro transformaci XSLT . . . 22

17 Funkce vracejici minimum dvou cˇı´sel v JavaScriptu . . . 24

18 Mozˇnosti rˇa´dkova´nı´ v HTML . . . 25

19 Inicializace zvy´raznˇovacˇe syntaxe . . . 27

20 Pravidla pro zvy´raznˇovacˇ ve forma´tu XML . . . 28

21 Zforma´tovany´ XML dokument . . . 31

22 Uka´zkovy´ styl pro umozˇneˇnı´ WYSYWYG rezˇimu . . . 32

23 Metoda transformNode . . . 32

24 Uzˇivatelske´ rozhranı´ editoru . . . 34

25 Rezˇim rozbalovacı´ho stromu . . . 36

26 Konfiguracˇnı´ skript . . . 38

27 Uka´zka aplikace . . . 41

(10)

Seznam symbolu ˚ , zkratek a termı´nu ˚

API Application Programming Interface – programove´ rozhranı´ aplikace, sbı´rka procedur, funkcı´, objektu˚, ktere´ mu˚zˇe programa´tor vyuzˇı´vat v prˇı´padeˇ, zˇe pouzˇı´va´ danou knihovnu.

CSS Cascading Style Sheets – jazyk pro popis zpu˚sobu zobrazenı´ stra´nek napsany´ch v jazycı´ch HTML, XHTML nebo XML.

DOM Document Object Model – objektoveˇ orientovana´ reprezentace XML nebo HTML doku- mentu.

FILO First In Last Out – druh za´sobnı´ku, ve ktere´m je prvneˇ prˇidany´ prvek prˇı´stupny´ jako poslednı´.

GPL GNU General Public License – licence pro svobodny´ software.

GUI GUI Graphical User Interface – graficka´ forma uzˇivatelske´ho rozhranı´.

HTTP HyperText Transfer Protocol – internetovy´ protokol urcˇeny´ pu˚vodneˇ pro vy´meˇnu hyper- textovy´ch dokumentu˚ ve forma´tu HTML.

JS JavaScript – vysokou´rovnˇovy´ skriptovacı´ programovacı´ jazyk, pouzˇı´vany´ prˇeva´zˇneˇ prˇi vy´vojı´

webovy´ch aplikacı´.

JSON JavaScript Object Notification – jazyk pro popis JavaScriptovy´ch objektu˚.

PDF Portable Document Format – souborovy´ forma´t vyvinuty´ firmou Adobe pro ukla´da´nı´ do- kumentu˚ neza´visle na softwaru i hardwaru, na ktere´m byly porˇı´zeny.

RE Rich Edit – JavaScriptova´ komponenta pro Wysiwyg editory, vy´sledek me´ho magisterske´ho projektu.

SAX Simple API for XML – sekvencˇnı´ programove´ rozhranı´ pro pra´ci s XML, alternativa k DOM.

UML Unified Modeling Language – graficky´ jazyk pro vizualizaci, specifikaci, navrhova´nı´

a dokumentaci programovy´ch syste´mu˚.

URL Uniform Resource Locator – slouzˇı´ k prˇesne´ specifikaci umı´steˇnı´ zdroju˚ informacı´ na Internetu.

(11)

VCL Viual Component Library – knihovna komponent dostupna´ ve vy´vojove´m prostrˇedı´ Delphi.

W3C World Wide Web Consortium – mezina´rodnı´ konsorcium pro vy´voj webovy´ch standardu˚.

WWW World Wide Web – oznacˇenı´ pro aplikace internetove´ho protokolu HTTP.

WYSIWYG What You See Is What You Get – oznacˇuje zpu˚sob editace dokumentu˚ v pocˇı´tacˇi, prˇi ktere´m je verze zobrazena´ na obrazovce vzhledoveˇ totozˇna´ s vy´slednou verzı´ dokumentu.

XHTML eXtensible HyperText Markup Language – znacˇkovacı´ jazyk pro tvorbu hypertexto- vy´ch dokumentu˚ v prostrˇedı´ WWW vyvinuty´ W3C.

XML eXtensible Markup Language – obecny´ rozsˇirˇitelny´ znacˇkovacı´ jazyk, ktery´ byl vyvinut a standardizova´n konsorciem W3C.

XSLT eXtensible Stylesheet Language Transformation – jazyk zalozˇeny´ na XML, definuje, jak se data forma´tu XML prˇevedou do libovolne´ jine´ datove´ struktury (nejcˇasteˇji HTML, XML) na za´kladeˇ stylove´ho prˇedpisu.

(12)

1 U ´ vod

V ra´mci sve´ bakala´rˇske´ pra´ce jsem vytvorˇil jednoduchy´ WYSIWYG editor pracujı´cı´ s dokumenty napsany´mi v jazyce Docbook beˇhem jejich sazby na webove´ stra´nce. Du˚lezˇite´ body v zada´nı´

byly: pouzˇı´t jazyk JavaScript (da´le JS) a XSLT (proces prˇevodu XML dokumentu naprˇ. na HTML dokument). Jazyk JS byl zvolen proto, aby editor mohl pracovat bez HTTP serveru. Beˇhem te´to pra´ce jsem take´ uka´zal mozˇnosti generova´nı´ ru˚zny´ch vy´stupnı´ch forma´tu˚ ze zdrojove´ho Docbook dokumentu.

Po dokoncˇenı´ pra´ce jsem se rozhodl da´le pracovat na tomto projektu a vyvı´jet aplikaci jako editor obecne´ XML se´mantiky. Uzˇ beˇhem bakala´rˇske´ pra´ce jsem se nejprve snazˇil pojmout editor jako obecny´ XML editor, ktere´mu pak jednodusˇe prˇida´m podporu Docbooku. Velmi brzy se to uka´zalo jako nelehky´ u´kol, prˇedevsˇı´m kvu˚li WYSIWYG rezˇimu, jezˇ tvorˇil du˚lezˇitou cˇa´st zada´nı´.

Nakonec jsem aplikaci napsal jako editor pouze pro jazyk Docbook a splnil tak sice zada´nı´, nicme´neˇ prˇestozˇe je editor funkcˇnı´, jeho implementace nebyla nejsˇt’astneˇjsˇı´.

Zacˇal jsem prˇemy´sˇlet, procˇ je proble´m napsat WYSIWYG editor v jazyce JS pro „ne-HTML“

znacˇkovacı´ jazyky, vzˇdyt’dnesˇnı´ web je plny´ jazyka XML a XHTML. Jeden ze za´sadnı´ch proble´mu je absence „rozumne´ho“ HTML prvku, ktery´ by umozˇnˇoval editaci forma´tovane´ho textu — za´klad WYSIWYG editoru. Du˚lezˇite´ je, aby ru˚zne´ cˇa´sti textu byly forma´tova´ny podle ru˚zny´ch pravidel. Protozˇe vyvı´jı´m XML editor, vsˇechny operace s dokumentem jsou prova´deˇny na u´rovni zdrojove´ho XML ko´du, nikoliv HTML, ktere´ prˇedstavuje jakousi vizualizaci XML pro umozˇneˇnı´

WYSIWYG rezˇimu. K teˇmto u´cˇelu˚m se API navrzˇene´ pro HTML editory nehodı´, cozˇ je i du˚vodem procˇ ma´ pu˚vodnı´ mysˇlenka napsat bakala´rˇskou pra´ci jako obecny´ XML editor neuspeˇla.

Na zacˇa´tku˚ sve´ho magisterske´ho studia jsem zacˇal pracovat na vlastnı´m API pro WYSIWYG edtiory, ktere´ poskytuje lepsˇı´ mozˇnosti nezˇ API prohlı´zˇecˇe a rˇesˇı´ neˇktere´ nekompatibility. Tuto knihovnu jsem napsal jako plugin pro framework jQuery, ktery´ dnes patrˇı´ mezi nejpopula´rneˇjsˇı´

frameworky pro jazyk JS. Vy´sledny´ plugin umozˇnˇuje naprˇı´klad vy´voja´rˇu˚m reagovat pomocı´

vlastnı´ch skriptu˚ na urcˇite´ operace s dokumentem, potlacˇovat je cˇi jakkoliv prˇizpu˚sobovat. Da´le umozˇnˇuje pohodlne´ nastavova´nı´ resp. zjisˇt’ova´nı´ pozice kursoru (neboli caret) v dokumentu.

Plugin je uzˇitecˇny´ jak pro tento projekt, tak pro libovolny´ webovy´ WYSIWYG editor. Kompo- nentu kterou realizuje tento plugin jsem nazval RichEdit (da´le RE). Pra´ci jsem obha´jil jako magistersky´ rocˇnı´kovy´ projekt.

Tato pra´ce je pokracˇova´nı´m prˇedchozı´, jednotlive´ cˇa´sti budou reprezentova´ny dalsˇı´mi pluginy pro jQuery tak, aby ve vy´sledku tvorˇily webovy´ XML editor.

(13)

2 Objektoveˇ orientovane´ programova´nı´ a JavaScript

2.1 Vznik objektove´ho programova´nı´

Sˇedesa´ta´ le´ta dvaca´te´ho stoletı´ prˇinesla programovacı´ jazyky trˇetı´ generace a jednalo se o jeden z nejveˇtsˇı´ch zlomu˚ v historii programova´nı´. Jsou to strojoveˇ neza´visle´ programovacı´ jazyky, podporujı´cı´ metody strukturovane´ho programova´nı´. Ty jsou prˇenositelne´ a rozcˇleneˇne´ do mensˇı´ch autonomnı´ch modulu˚, ktere´ obsahujı´ rozhranı´ a teˇlo. Prˇı´kladem modulu je procedura (resp.

funkce), jejı´mzˇ rozhranı´m jsou jejı´ parametry a teˇlem je jejı´ implementace. Prvnı´mi takovy´mi jazyky byly Fortran (IBM 1957), Algol a Cobol. Jazyk PL/1 z poloviny 60. let byl pokusem o co nejuniverza´lneˇjsˇı´ programovacı´ jazyk, nicme´neˇ pozdeˇji vznikl jiny´ univerza´lnı´ avsˇak jednodusˇsˇı´

jazyk — Pascal, pouzˇı´vany´ dodnes zejme´na k vy´uce. Asi nejvy´znamneˇjsˇı´m jazykem te´to generace je jazyk C, ktery´ polozˇil standard pro syntakticka´ pravidla mnoha budoucı´ch jazyku˚, vcˇetneˇ jazyku JavaScript. Na mikropocˇı´tacˇı´ch se prosadil snadno zvla´dnutelny´ Basic a take´ se objevily databa´zove´ programovacı´ jazyky, naprˇ. jazyk SQL.

Objektoveˇ orientovane´ programovacı´ jazyky jsou oznacˇova´ny jako jazyky „trˇı´apu˚lte´“ ge- nerace. Prˇina´sˇı´ sebou neˇkolik uzˇitecˇny´ch technik, ktere´ usnadnˇujı´ na´vrh programu, redukujı´

redundance zdrojovy´ch kodu˚, prˇina´sˇı´ efektivneˇjsˇı´ rozsˇirˇitelnost vyvı´jeny´ch API a v konecˇne´m du˚sledku i lepsˇı´ prˇehlednost vyvı´jeny´ch ko´du˚. To vsˇe za cenu urcˇite´ ztra´ty pocˇetnı´ho vy´konu.

Objektoveˇ orientovane´ programova´nı´ (da´le OOP) je neˇkdy oznacˇova´no jako programa´torske´

paradigma, nebot’popisuje nejen zpu˚sob vy´voje a za´pisu programu, ale i zpu˚sob, jaky´m na´vrha´rˇ programu o proble´mu prˇemy´sˇlı´. Prˇi vy´voji rozsa´hlejsˇı´ch projektu˚ je efektivnı´ vyuzˇı´t pra´veˇ OOP.

Protozˇe jazyk JS podporuje OOP, vyuzˇı´va´m jej v te´to pra´ci. Existuje vsˇak rˇada protichu˚dny´ch na´zoru˚, zda se jedna´ o kvalitnı´ na´stroj z hlediska OOP. V na´sledujı´cı´m textu prˇiblı´zˇı´m principy OOP a prˇedvedu spra´vny´ zpu˚sob, jak je vyuzˇı´t v JS.

2.2 C ˇ isty´ a hybridnı´ jazyk

Za´kladnı´m hlediskem, podle ktere´ho se deˇlı´ OOP jazyky je tzv. objektova´ cˇistota vyvı´jene´ho ko´du. Rˇ ada jazyku˚ s OOP vznikla jako rozsˇı´rˇenı´ neˇktere´ho jazyku trˇetı´ generace (naprˇ. Object Pascal, C++, nebo Objective-C). Je zde mozˇnost psa´t ko´d v dane´m jazyce bez OOP nebo obeˇ techniky libovolneˇ kombinovat. I kdybychom se vsˇak snazˇili v teˇchto jazycı´ch psa´t objektoveˇ cˇisty´

ko´d sebevı´c, nikdy by se na´m to nepodarˇilo. Vzˇdy by zde existovala cˇa´st zdrojove´ho ko´du, ktera´

by nebyla tvorˇena objektem. Prˇı´kladem je funkce main() v jazyce C++, kterou musı´ obsahovat

(14)

kazˇdy´ program a nemu˚zˇe nikdy tvorˇit cˇa´st objektu. Tyto jazyky, ktere´ nevytva´rˇı´ objektoveˇ cˇisty´, ko´d se nazy´vajı´ jazyky hybridnı´ a patrˇı´ mezi neˇ i JS.

Opakem hybridnı´ch jsou cˇiste´ jazyky. V nich nelze napsat program, ktery´ by nebyl objektoveˇ cˇisty´. Patrˇı´ mezi neˇ popula´rnı´ jazyk Java. Cˇiste´ jazyky se nehodı´ pro vy´voj maly´ch aplikacı´, pro ktere´ je JS urcˇen a zrˇejmeˇ proto nenı´ JS cˇisty´m jazykem. Dajı´ se ale pomocı´ OOP v JS psa´t efektivneˇ i strˇedneˇ velke´ a veˇtsˇı´ projekty?

2.3 Objekty, jejich vlastnosti a realizace v JavaScriptu

Aby byl programovacı´ jazyk objektovy´, musı´ umozˇnit programa´torovi definovat objekty, vytva´rˇet jejich instance a vyuzˇı´vat deˇdicˇnost a polymorfismus. Definicı´ objektu je trˇı´da (angl. class) a ta na za´kladeˇ sve´ho konstruktoru (konstrukcˇnı´ funkce) umozˇnˇuje vytva´rˇenı´ instancı´. Prˇı´tomnost konstruktoru je jednou z vlastnostı´, kterou se objekty lisˇı´ od prosty´ch promeˇnny´ch. Deˇdicˇnost a polymorfismus jsou za´kladnı´ prvky OOP a budu se jim veˇnovat podrobneˇji v dalsˇı´ch cˇa´stech te´to pra´ce.

Prˇi na´vrhu objektove´ho ko´du se cˇasto vyuzˇı´va´ tzv. diagram trˇı´d. Jedna´ se o grafickou re- prezentaci urcˇity´ch trˇı´d a urcˇity´ch vztahu˚ mezi nimi tak, zˇe jsou v neˇm prvky OOP vyznacˇeny podle standardu˚ definovany´ch jazykem UML (Unified Modelling Language). V na´sledujı´cı´ch kapitola´ch se budu veˇnovat jednotlivy´m metodika´m OOP a uka´zˇi, jak je lze zaznamenat pomocı´

diagramu trˇı´d. Pozdeˇji v pra´ci budou uka´za´ny UML diagramy navrzˇene´ pro vyvı´jeny´ XML editor.

2.3.1 Trˇı´dy a zapouzdrˇenı´

Objekt je u´lozˇisˇteˇm dat, ke ktery´m je prˇistupova´no pomocı´ instance. Data v ra´mci trˇı´dy se nazy´vajı´ vlastnosti (atributy, angl. properties). By´va´ zvykem promeˇnne´ v objektu „zapouzdrˇit“, tzn. deklarovat je tak, aby k nim nebylo mozˇne´ prˇistupovat mimo trˇı´du. Trˇı´da tyto „zapouzdrˇene´“

polozˇky obvykle zprˇı´stupnı´ pomocı´ metod. Metody (cˇlenske´ funkce) jsou funkce, ktere´ tvorˇı´

soucˇa´st objektu.

„Zapouzdrˇene´“ atributy tvorˇı´ tzv. soukrome´ rozhranı´. To je skryto prˇed okolı´m (objektem prˇistupujı´cı´m k te´to instanci — klientem). Soukrome´ polozˇky si objekt spravuje sa´m a nemu˚zˇe se sta´t, zˇe by naprˇ. klient jejich prˇı´mou zmeˇnou narusˇil spra´vnou cˇinnost instance. Pomocı´ verˇejne´ho rozhranı´ objekt urcˇı´, ktere´ soukrome´ atributy mu˚zˇe klient meˇnit (prˇı´padneˇ jake´ vedlejsˇı´ operace zmeˇna vyvola´), ktere´ budou k dispozici pouze pro cˇtenı´ a ktere´ budou prˇed klientem u´plneˇ schova´ny.

(15)

Obra´zek 1: Diagram trˇı´dy Vector2D

V diagramu trˇı´d jsou trˇı´dy vyobrazeny jako entity obsahujı´cı´ trˇi cˇa´sti. V prvnı´ je na´zev trˇı´dy, ve druhe´ jejı´ atributy tvorˇene´ prosty´mi promeˇnny´mi a ve trˇetı´ se zapisujı´ metody. Prefix plus resp.

mı´nus znamena´ zda je polozˇka verˇejna´ resp. soukroma´. Na obr. 1 je diagram jednoduche´ trˇı´dy Vector2D. Konstruktor je zaznamena´n jako metoda s na´zvem trˇı´dy.

Kompilovane´ programovacı´ jazyky by´vajı´ beˇzˇneˇ staticke´ — prˇi deklaraci promeˇnny´ch pevneˇ prˇirˇazujı´ datovy´ typ. Kazˇda´ trˇı´da tvorˇı´ novy´ datovy´ typ, takzˇe prˇi deklaraci novy´ch trˇı´d programa´- tor deklaruje nove´ datove´ typy. Naproti tomu dynamicke´ jazyky (prˇekla´dane´ zpravidla interpretem za beˇhu) prˇistupujı´ k datovy´m typu˚m daleko svobodneˇji a promeˇnne´ deklarujı´ bez nich. JS je dy- namicky´m jazykem, neprˇirˇazuje typy v deklaraci promeˇnny´ch a nelze v neˇm definovat trˇı´dy tak jak je zvykem naprˇ. v jazycı´ch C++ nebo Java. Mozˇna´ pra´veˇ proto nezkusˇenı´ vy´voja´rˇi cˇasto nevı´, zˇe JS patrˇı´ mezi objektove´ jazyky.

2.3.2 Trˇı´dy v JavaScriptu

JS nema´ klasicke´ trˇı´dy a i proto je OOP v tomto jazyku trochu neobvykle´. Existujı´ na´zory, zˇe trˇı´dy v JS nejsou pravy´mi trˇı´dami, ale opak je pravdou. JS trˇı´dy totizˇ splnˇujı´ definici, zˇe trˇı´da je konstrukt, ktery´ je vyuzˇı´va´n jako prˇedpis slouzˇı´cı´ k vytva´rˇenı´ objektu˚ te´to trˇı´dy. Za trˇı´du v JS povazˇujeme samotny´ konstruktor, ktery´ vyuzˇı´va´ vlastnosti prototype.

V JS vsˇe, co nenı´ primitivnı´m datovy´m typem, je objektem. Naprˇ. funkce, pole i regula´rnı´

vy´razy jsou objekty. Vsˇechny trˇidy v JS jsou odvozeny od datove´ho typu Object, ktery´ tvorˇı´

vrchol hierarchie trˇı´d.

Funkce, metody, konstruktory i trˇı´dy jsou v JS jednou a tou samou funkcı´. Pojmenova´nı´ funkce urcˇuje roli, kterou funkce hraje. Funkce je prostou funkcı´, pokud netvorˇı´ soucˇa´st zˇa´dne´ho objektu a metodou pokud soucˇa´stı´ objektu je. Trˇı´da a konstruktor je v JS jedno a to same´, pro vytvorˇenı´

nove´ trˇı´dy v JS je zkra´tka trˇeba definovat konstruktor, cˇili funkci. Mozˇnostı´ jak v JS realizovat

(16)

Obra´zek 2: Trˇı´da Vector2D v JavaScriptu

zapouzdrˇenı´ a jak deklarovat verˇejne´ metody je vı´ce. Veˇtsˇina postupu˚ neˇjaky´m zpu˚sobem vyuzˇı´va´

klı´cˇove´ slovo this, to pomocı´ opera´toru tecˇka zprˇı´stupnˇuje kontext — neboli funkci resp. objekt v ktere´m je pouzˇito. Pokud se this nenacha´zı´ uvnitrˇ zˇa´dne´ funkce (objektu), odkazuje na objekt window. Na obr. 2 je uka´za´no, jak lze v JS definovat trˇı´du Vector2D z prˇedchozı´ uka´zky1. Prˇestozˇe tento zpu˚sob nenı´ u´plneˇ spra´vny´, uva´dı´m jej zde, protozˇe je velmi rozsˇı´rˇeny´. Z hlediska spra´vne´ho OOP v JS je vsˇak nesˇt’astnou uka´zkou, jak se to deˇlat nema´.

Jediny´m spra´vny´m zpu˚sobem jak v JS definovat rozhranı´ trˇı´dy je vyuzˇitı´m vlastnosti jme´nem prototypetak, jak je uka´za´no na obr. 3. Vlastnost prototype ma´ kazˇda´ funkce a jejı´ vy´chozı´

hodnotou je pra´zdny´ objekt. Tato deklarace je prˇirozena´ a plyne z na´vrhu jazyka. Protozˇe je JS dynamicky´ jazyk, lze jeho trˇı´dy meˇnit za beˇhu. Jaka´koliv zmeˇna trˇı´dy za beˇhu se musı´ projevit i ve vsˇech jejı´ch instancı´ch. Toho lze docı´lit pouze pouzˇitı´m prototype, je to totizˇ vlastnost sdı´lena´ vsˇemi instancemi jedne´ trˇı´dy. V uka´zce na obr. 3 nejsou mozˇne´ prˇı´padne´ dalsˇı´ modifikace trˇı´dy za beˇhu a problematicka´ by byla i spra´vna´ realizace deˇdicˇnosti.

2.3.3 Pra´ce s instancemi

Instance jsou vytva´rˇeny vola´nı´m konstruktoru. Po alokaci lze pracovat s verˇejny´m rozhranı´m objektu (dle potrˇeb vyvı´jene´ho programu) a kteroukoliv instanci lze smazat (uvolnit z pameˇti pocˇı´tacˇe). Prˇi uvolnˇova´nı´ instance je vola´n destruktor, neboli metoda volana´ teˇsneˇ prˇed okamzˇi- kem, kdy instance prˇestane fyzicky existovat.

1Autorem te´to metody je Douglas Crockford.

(17)

Obra´zek 3: Trˇı´da Vector2D v jazyce JavaScript pomocı´ vlastnosti prototype

Obecneˇ mu˚zˇe kazˇda´ trˇı´da obsahovat vı´ce konstruktoru˚ a programa´tor tak mu˚zˇe mezi nimi vybı´rat a prova´deˇt tak ru˚zne´ inicializace stejne´ trˇı´dy. Destrukor je vsˇak v trˇı´deˇ vzˇdy maxima´lneˇ jeden. Jak jizˇ bylo rˇecˇeno, vlastnosti objektu jsou prˇı´stupne´ pomocı´ instance, vy´jimkou jsou tzv.

staticke´ vlastnosti, ktere´ jsou spolecˇne´ vsˇem instancı´m a jsou prˇı´stupne´ pomocı´ trˇı´dy. Lze je volat i kdyzˇ neexistuje zˇa´dna´ instance dane´ trˇı´dy, existujı´ vzˇdy pra´veˇ jednou nehledeˇ na pocˇtu instancı´.

Obra´zek 4: Instance Vector2D v jazyce JavaScript

V JS nelze definovat trˇı´dy s vı´ce jak s jednı´m konstruktorem a nelze jim prˇirˇadit destruktor.

Alokace novy´ch instancı´ se v JS prova´dı´ pomocı´ opera´toru new a dealokace pomocı´ opera´toru delete. V uka´zce na obr. 4 je vytvorˇenı´ instance Vector2D, uka´zkove´ pouzˇitı´ jejı´ho verˇejne´ho rozhranı´ vola´nı´m metod definovany´ch v te´to trˇı´deˇ a na´sledna´ dealokace objektu. Instance nenı´

nutne´ rucˇneˇ dealokovat, JS obsahuje tzv. garbage collector, ktery´ automaticky uklı´zı´ objekty, ktere´ nejsou nada´le vyuzˇı´va´ny. Avsˇak rucˇnı´ dealokace pomocı´ delete mu˚zˇe usˇetrˇit pameˇt’

a zefektivnit tak vy´sledny´ skript.

(18)

2.3.4 Vazby mezi objekty a zası´la´nı´ zpra´v

Odkazy na objekty se v JS realizujı´ pomocı´ tzv. referencı´. Reference, neboli referencˇnı´ promeˇnna´, je promeˇnna´, ktera´ nevytva´rˇı´ novou promeˇnnou jako takovou, ale slouzˇı´ jako alias jine´ promeˇnne´

resp. instance. Reference jsou velmi du˚lezˇitou soucˇa´stı´ jazyka JS, JS totizˇ pracuje s objekty, o jejichzˇ alokaci se stara´ sa´m prohlı´zˇecˇ, ktery´ je zprˇı´stupnˇuje skriptu˚m pra´veˇ pomocı´ referencı´.

Referencˇnı´ promeˇnna´ se v JS deklaruje obdobneˇ jako beˇzˇna´ promeˇnna´ s vynecha´nı´m klı´cˇove´ho slova var.

Objekty by´vajı´ zpravidla obklopeny jiny´mi objekty, ktery´m poskytujı´ sve´ sluzˇby, prˇı´padneˇ po nich sluzˇby pozˇadujı´. Okolnı´ objekty pracujı´ s objektem pomoci jeho metod a tomuto procesu se neˇkdy rˇı´ka´ zası´la´nı´ zpra´v mezi objekty. Hlavicˇka (deklarace) metody totizˇ definuje jaky´si komunikacˇnı´ protokol, pomocı´ ktere´ho se objekt dorozumı´va´ s okolnı´m sveˇtem. To znamena´, zˇe reference v jednom objektu na jiny´ objekt poskytuje objektu s referencı´ mozˇnost vyuzˇı´vat druhy´ objekt. Obecna´ vazba mezi objekty se nazy´va´ asociace, a v tomto prˇı´padeˇ jde o prostou asociaci. Beˇhem na´vrhu tedy vy´voja´rˇ obvykle cˇlenı´ konkre´tnı´ problematiku do jednodusˇsˇı´ch celku˚ — objektu˚ a vazby mezi nimi zaznamena´va´ a vytva´rˇı´ tak diagramy UML. Prosta´ asociace se zapisuje jako souvisla´ hrana, ktera´ mu˚zˇe a nemusı´ by´t ohodnocena tak, aby vystihovala danou problematiku (jejı´ hodnota za´lezˇı´ na na´vrha´rˇi). Smeˇr hrany vyjadrˇuje smeˇr asociace, naprˇ. pokud trˇı´da A asociuje trˇı´du B, smeˇrˇuje i hrana od trˇı´dy A k trˇı´deˇ B. Da´le zde mu˚zˇe na´vrha´rˇ zaznamenat, kolik asociacı´ vazba vytva´rˇı´. Symbol * znamena´ libovolne´ mnozˇstvı´, dalsˇı´mi mozˇnostmi jsou naprˇ.: 1 (pra´veˇ jedna); 5, 10, 20 (5, 10, nebo 20); 1..3 (1 azˇ 3); 8..* (8 a vı´ce) atp.

Dalsˇı´mi druhy asociace jsou agregace a kompozice (neboli kompozitnı´ agregace). Ty by´vajı´

zaznamena´ny pomocı´ hran zakoncˇeny´ch kosocˇtvercem (ten je na straneˇ celku), u kompozice je kosocˇtverec vyplneˇn. Opeˇt je zde mozˇnost vycˇı´slit mnozˇstvı´ asociace obdobneˇ jako u proste´ aso- ciace. Agregace je specia´lnı´ formou asociace, ktera´ specifikuje vztah mezi agregujı´cı´m (celkem) a jeho konstituentem (cˇa´stı´). Jeden agregovany´ objekt mu˚zˇe by´t potencia´lneˇ cˇa´stı´ vı´ce objektu˚.

Kompozitnı´ agregace je silneˇjsˇı´ formou, ktera´ vyzˇaduje, aby jaka´koliv instance konstituenta byla soucˇa´stı´ nejvy´sˇe jednoho agregujı´cı´ho celku. Ten pokud je smaza´n, smazˇe i vsˇechny sve´ cˇa´sti kompozice. Specifikace UML pomeˇrneˇ prˇı´sneˇ definuje jednotlive´ druhy asociacı´, v praxi k nim vsˇak vy´voja´rˇi obvykle neprˇistupujı´ tak striktneˇ. Naprˇ. mnoho na´vrhu˚ nerozlisˇuje mezi agregacı´

a kompozicı´, navı´c jsem se pa´rkra´t setkal se stejny´mi na´vrhovy´mi vzory (standardnı´mi postupy na´vrhu objektove´ aplikace) vyja´drˇeny´mi pokazˇde´ odlisˇny´mi asociacemi. V praxi zkra´tka za´lezˇı´

prˇedevsˇı´m na citu konkre´tnı´ho na´vrha´rˇe, se ktery´m k dane´ problematice prˇistupuje. Je zrˇejme´, zˇe

(19)

o alokaci konstituentu˚ se stara´ konstruktor objektu, ktery´ prˇedstavuje celek.

Obra´zek 5: Trˇı´da XmlNode a jejı´ asociace

Jednotlive´ druhy asociacı´ jsou prˇedvedeny v uka´zce na obr. 5, kde je na´vrh trˇı´dy, ktera´ repre- zentuje veˇtev stromu XML dokumentu. Ta asociuje sve´ sousednı´ a nadrˇazene´ veˇtve (prevSibling, nextSibling a parent) a agreguje podrˇı´zene´ veˇtve (children). V tomto na´vrhu lze libovolneˇ pro- cha´zet cely´ strom XML na za´kladeˇ reference na kteroukoliv jeho veˇtev. Obdobny´ na´vrh vyuzˇı´va´

i DOM (objektove´ API pro XML, viz 3.2).

2.3.5 Princip abstrakce

Abstrakce v OOP u´zce souvisı´ s pojmy deˇdicˇnost a polymorfismus. Dı´ky teˇmto technika´m, mu˚zˇe programa´tor prˇihlı´zˇet na urcˇitou problematiku v urcˇite´ abstraktnı´ rovineˇ, kde neexistujı´ konkre´tnı´

implementace. Prˇi na´vrhu se tak lze snadno oprostit od detailu˚, ktere´ nejsou v dane´ situaci du˚lezˇite´.

Trˇı´da XmlNode z prˇedchozı´ uka´zky je abstraktnı´, proto je jejı´ na´zev vyznacˇen kurzı´vou.

Tato trˇı´da definuje asociace resp. vztahy mezi okolnı´mi veˇtvemi, prˇedstavuje vsˇak obecnou veˇtev XML stromu formou obecne´ho rozhranı´ pro konkre´tnı´ typy XML veˇtvı´. Jednotlive´ XML veˇtve mohou by´t ru˚zne´ho druhu, ale vlastnosti trˇı´dy XmlNode budou spolecˇne´ vsˇem, nehledeˇ na to jestli jde o veˇtev typu element cˇi veˇtev typu komenta´rˇ atp. Vlastnosti trˇı´d, ktere´ jsou definovane´, ale nemajı´ konkre´tnı´ implementaci, se nazy´vajı´ abstraktnı´ vlastnosti a kazˇda´ trˇı´da obsahujı´cı´

neˇjakou abstraktnı´ vlastnost je abstraktnı´ trˇı´dou.

Deˇdicˇnost (generalizace), je hierarchicky´ vztah, kdy nova´ trˇı´da prˇedstavujı´cı´ potomka (angl.

subclass) obsahuje vsˇechny vlastnosti trˇı´dy prˇedstavujı´cı´ jejı´ho prˇedka (angl. superclass). Prˇedek by´va´ neˇkdy oznacˇova´n jako ba´zova´ trˇı´da (angl. base class). Generalizace se v diagramu trˇı´d vyznacˇı´ orientovanou hranou zakoncˇenou troju´helnı´kem, smeˇrˇujı´cı´m k trˇı´deˇ prˇedka. V prˇı´padeˇ trˇı´dy XmlNode bude tato trˇı´da prˇedstavovat ba´zovou trˇı´du pro trˇı´dy tvorˇı´cı´ konkre´tnı´ typy XML veˇtvı´ (XmlElement, Comment...), cozˇ vyjadrˇuje diagram trˇı´d na obr. 6 (nejsou zde zachyceny vsˇechny druhy XML veˇtvı´, protozˇe u´cˇel kapitoly nenı´ podrobny´ rozbor jazyka XML).

(20)

Obra´zek 6: Deˇdicˇnost trˇı´dy xmlNode

Potomek mu˚zˇe krom zdeˇdeˇny´ch vlastnostı´ obsahovat neˇktere´ sve´ specificke´ vlastnosti cˇi vlastnosti prˇedka meˇnit neboli prˇekry´vat. Pokud chceme pouzˇı´vat instanci potomka abstraktnı´

ba´zove´ trˇı´dy, musı´ potomek prˇekry´t vsˇechny abstraktnı´ vlastnosti prˇedka neabstraktnı´mi, tj. dopl- nit chybeˇjı´cı´ implementace prˇedka. Stejne´ rozhranı´ tak v ru˚zny´ch deˇdicı´ch vyvola´ ru˚zne´ operace lisˇı´cı´ se konkre´tnı´ implementacı´. To, zˇe se odkazovany´ objekt chova´ podle toho, jake´ trˇı´dy je instancı´, je pra´veˇ principem polymorfismu. Staticke´ programovacı´ jazyky vyuzˇı´vajı´ tzv. polymor- fismus podmı´neˇny´ deˇdicˇnostı´. To znamena´, zˇe na mı´sto, kde je ocˇeka´va´na instance neˇjake´ trˇı´dy, mu˚zˇeme dosadit i instanci libovolne´ho jejı´ho deˇdice, nebot’ rozhranı´ trˇı´dy je podmnozˇinou roz- hranı´ deˇdice. Dynamicke´ jazyky (jako je i JS) vyuzˇı´vajı´ jednodusˇsˇı´ polymorfismus nepodmı´neˇny´

deˇdicˇnostı´, kde je dostacˇujı´cı´, jestlizˇe se rozhranı´ (nebo jejich pozˇadovane´ cˇa´sti) u ru˚zny´ch trˇı´d shodujı´, avsˇak jejich implementace se lisˇı´ — pak jsou vza´jemneˇ polymorfnı´.

2.3.6 Deˇdicˇnost a polymorfismus v JavaScriptu

Acˇkoliv ma´ JS urcˇite´ prvky deˇdicˇnosti, nejdena´ se o klasickou deˇdicˇnost, cˇili deˇdicˇnost na za´kladeˇ trˇı´d (angl. classical inheritance) zna´mou ze staticky´ch jazyku˚. Jde spı´sˇe o jakousi simulaci, protozˇe JS nepodporuje za´pis trˇı´d (umozˇnˇuje pouze za´pis konstruktoru˚). Deˇdicˇnost je v JS tzv. prototypova´ (angl. prototypal inheritance). Klı´cˇovy´ prostrˇedek deˇdicˇnosti v JS je vlastnost prototypezmı´neˇna´ v kapitole 2.3.2.

Trˇı´da Vector2D z kapitoly 2.3.1 by mohla slouzˇit jako prˇedek pro trˇı´du Vector3D, ktera´

trˇı´du Vector2D rozsˇı´rˇı´ o zetovou sourˇadnici. Pouzˇitı´m prototype to lze udeˇlat obdobneˇ jako v uka´zce na obr. 7. Tuto techniku pro realizaci deˇdicˇnosti uva´dı´ mnoho ucˇebnic a cˇla´nku˚

o JS. Prˇestozˇe je toto doporucˇenı´ funkcˇnı´, nepouzˇil jsem ho z du˚vodu˚ uvedeny´ch v na´sledujı´cı´m odstavci.

Takto definovana´ trˇı´da Vector3D inicializuje priva´tnı´ vlastnosti x a y zdeˇdeˇne´ od trˇı´dy Vector2D. Ty jsou ale take´ inicializova´ny uzˇ v konstruktoru Vector2D, jejich inicializace jsou

(21)

Obra´zek 7: Deˇdicˇnost v JavaScriptu

za´lezˇitostı´ te´to trˇı´dy a je neefektivnı´ deˇlat to znovu v konstruktoru Vector3D. Vlastnosti x a y jsou za´sadnı´ pro obeˇ trˇı´dy, jsou inicializova´ny v konstruktoru, aby mohli mı´t platne´ hodnoty hned po vytvorˇenı´ instance. Aby to ale platilo i prˇi vytva´rˇenı´ instancı´ Vector3D, musı´ se o inicializaci vlastnostı´ trˇı´dy Vector2D postarat konstruktor Vector3D, musı´me tedy psa´t znovu stejny´ ko´d a vytva´rˇı´me tak zbytecˇne´ redundance. Proble´m je v tom, zˇe vola´me konstruktor prˇedka beˇhem deklarace trˇı´dy potomka (rˇa´dek 9 na obr. 7). To odporuje za´sadeˇ OOP, zˇe konstruktor trˇı´dy je vola´n prˇi vytva´rˇenı´ instance, nikoliv beˇhem deklarace trˇı´dy. Pokud bychom volali konstruktor trˇı´dy Vector2Dv konstruktoru trˇı´dy Vector3D, nemusela by trˇı´da Vector3D prova´deˇt znova inicializace vlastnostı´ Vector2D. Navı´c v prˇı´padeˇ, zˇe by konstruktor prˇedka obsahoval du˚lezˇite´ alokace dalsˇı´ch naprˇ. kompozitnı´ch objektu˚, prˇi pouzˇiti techniky z uka´zky na obr. 7 by se tyto objekty alokovaly uzˇ beˇhem na´vrhu trˇı´dy, cozˇ je zcela sˇpatneˇ.

Obra´zek 8: Pomocna´ funkce pro deˇdeˇnı´ v JavaScriptu

Pro spra´vnou realizaci deˇdicˇnosti v JS je potrˇeba funkce inherit2. Ta netvorˇı´ standardnı´

soucˇa´st jazyka JS, proto je jejı´ implementace uvedena na obr. 8. Nejprve je vytvorˇen pomocny´

2Mimochodem naprosto stejnou techniku pouzˇı´va´ i JavaScriptova´ knihovna Google Closure od Googlu.

(22)

Obra´zek 9: Deˇdicˇnost v JavaScriptu pomocı´ funkce inherit

docˇasny´ konstruktor, pomocı´ ktere´ho je vytvorˇen prototype potomka a obejde se tak nutnost volat konstruktor prˇedka. Prototype prˇedka si potomek udrzˇuje ve vlastnosti superClass, cozˇ je uzˇitecˇne´ zejme´na v prˇı´padeˇ, kdy potomek prˇekry´va´ neˇkterou metodu prˇedka a v ra´mci jejı´

nove´ implementace potrˇebuje volat metodu, kterou prˇekry´va´ (mu˚zˇe tak naprˇ. prˇekrytı´m rozsˇı´rˇit pu˚vodnı´ metodu o novou funkcionalitu, namı´sto jejı´ho u´plne´ho prˇekrytı´).

Trˇı´da Vector3D odvozena´ pomocı´ funkce inherit je na obr. 9. Je zde videˇt, zˇe trˇı´da neobsahuje prˇedchozı´ redundance, vola´ konstruktor Vector2D ve sve´m konstruktoru (rˇa´dek 4 v uka´zce) a ne beˇhem deˇdeˇnı´.

V kapitole 2.3.5 jsem zmı´nil, zˇe abstraktnı´ trˇı´da XmlNode slouzˇı´ jako prˇedek pro konkre´tnı´

druhy XML veˇtvı´. Zatı´m jsem ale neuvedl zˇa´dnou jejı´ abstraktnı´ metodu. Mohla by jı´ by´t naprˇ.

metoda pro tzv. serializaci XML veˇtve, tj. prˇevod na textovy´ rˇeteˇzec. Jednotlive´ druhy XML veˇtvı´

totizˇ mohou by´t serializova´ny ru˚zneˇ. V poslednı´ uka´zce kapitoly veˇnovane´ OOP v JS na obr. 10 uva´dı´m, jak by mohla vypadat trˇı´da xmlNode s abstraktnı´ metodou serialize a jejı´ odvozene´

trˇı´dy XmlAttrbute a Comment implementujı´cı´ tuto metodu. V JS neexistujı´ abstraktnı´ trˇı´dy jako takove´, protozˇe nelze vytva´rˇet metody bez implementace. Abstraktnı´ metoda je urcˇena pouze pro prˇekry´va´nı´ a nemeˇla by by´t nikdy vola´na v ra´mci abstraktnı´ trˇı´dy, ale pouze v ra´mci potomku˚, kterˇı´ ji prˇekry´vajı´. Opeˇt neexistuje konkre´tnı´ rˇesˇenı´, jak vytva´rˇet v JS abstraktnı´ trˇı´dy.

Moje rˇesˇenı´ je vyvola´nı´ vyjı´mky (angl. exception), ktera´ upozornı´ programa´tora na to, zˇe vola´

abstraktnı´ metodu.

(23)

Obra´zek 10: Polymorfismus v JavaScriptu

(24)

2.4 Zhodnocenı´ prˇı´stupu k JavaScriptu

JS je cˇasto kritizovany´m jazykem, at’uzˇ kvu˚li neusta´ly´m potrˇeba´m optimalizace, nebo z du˚vodu˚

jeho implementace OOP. JS nenı´ sˇpatny´ jazyk pro OOP, za´lezˇı´ spı´sˇ na prˇı´stupu vy´voja´rˇe. Je to dynamicky´ jazyk a pra´veˇ dynamika je jeho silnou stra´nkou. Da´va´ programa´torovi urcˇitou svobodu, kterou by v jiny´ch jazycı´ch nemeˇl, dı´ky cˇemuzˇ mu˚zˇe naprˇ. meˇnit trˇı´dy za beˇhu, cozˇ je prvek u staticky´ch (kompilovany´ch) jazycı´ch nevı´dany´. Dı´ky te´to svobodeˇ pak ale mohou programa´torˇi realizovat stejne´ prvky OOP ru˚zny´mi zpu˚soby a vytva´rˇet tak odlisˇna´ rˇesˇenı´, ktera´

jsou sice na prvnı´ pohled funkcˇnı´, ale prˇi podrobneˇjsˇı´m rozboru selha´vajı´.

Dynamika JS mu˚zˇe take´ ve´st k mnohy´m chyba´m, protozˇe programa´tor JS nikdy nema´ jistotu, zˇe jiny´ programa´tor neˇjakou jeho promeˇnnou nezmeˇnı´ resp. neprˇedefinuje svy´m skriptem, at’uzˇ je tato promeˇnna´ sebevı´c zapouzdrˇena. Zmeˇna te´to promeˇnne´ mu˚zˇe nakonec zpu˚sobit, zˇe pu˚vodnı´

skript prˇestane zcela fungovat a zda´ se, zˇe je chyba na straneˇ programa´tora tohoto skriptu, acˇkoliv ve skutecˇnosti ji zpu˚sobil neˇkdo jiny´.

V te´to kapitole jsem uka´zal, zˇe existuje zpu˚sob, jaky´m lze v JS spra´vneˇ vytva´rˇet trˇı´dy, implementovat deˇdicˇnost a s nı´ spjaty´ polymorfismus. Pomocı´ uka´zany´ch technik nenı´ proble´m z JS udeˇlat korektnı´ prostrˇedek pro OOP a nakonec to znamena´, zˇe prˇestozˇe je JS pu˚vodneˇ navrzˇen pro kra´tke´ jednora´zove´ skripty, hodı´ se i pro vy´voj veˇtsˇı´ch aplikacı´. Rˇ ekl bych zˇe to je jeden z hlavnı´ch du˚vodu˚, procˇ je JS sta´le rozsˇı´rˇeny´, i kdyzˇ jeho konkurence sta´le sı´lı´ (viz pomeˇrneˇ nove´

rozhranı´ Silverlight od Microsoftu). Webovy´ prohlı´zˇecˇ je dnes cha´pa´n spı´sˇe jako rozhranı´ pro webove´ aplikace, nezˇ jako prosty´ prostrˇedek pro prohlı´zˇenı´ HTML dokumentu˚, vy´voj skriptu˚ uzˇ proto da´vno nenı´ jen o „ozˇivenı´“ stra´nek pomocı´ dynamicke´ho HTML (DHTML), ale o vy´voji aplikacı´ jako takovy´ch, proto je u´loha OOP v ra´mci webovy´ch aplikacı´ sta´le vı´ce du˚lezˇita´.

Nejveˇtsˇı´ proble´my zpu˚sobujı´ webove´ prohlı´zˇecˇe, ktere´ JS zprostrˇedkova´vajı´. Nutnost opti- malizace mnohdy deˇla´ z pomeˇrneˇ jednoduchy´ch zada´nı´ zbytecˇneˇ slozˇita´ rˇesˇenı´, roste tak velikost skriptu˚, jejich prˇehlednost klesa´ a prˇedevsˇı´m roste cˇasova´ na´rocˇnost spojena´ s vy´vojem takove´ho skriptu. Dalsˇı´ slabinou JS jsou „mystifikace“ a omyly spojene´ s tı´mto jazykem. Se spra´vny´m prˇı´stupem vsˇeobecneˇ uzna´vane´ doporucˇene´ publikace [1] se z JS sta´va´ u´cˇinny´ na´stroj.

(25)

3 Vy´voj JavaScriptove´ho XML editoru

Vy´voj XML editoru, je pomeˇrneˇ rozsa´hle´ te´ma a naba´da´ k diskusi, co vsˇechno by editor mohl nabı´zet. Nezˇ jsem zacˇal se samotny´m na´vrhem editoru, prˇemy´sˇlel jsem, ktere´ funkce do aplikace implementuji. Ty uva´dı´m v na´sledujı´cı´m odstavci, jejich realizace bude postupneˇ probra´na v te´to kapitole.

Rezˇim zdrojove´ho ko´du – v tomto rezˇimu je zobrazeno zdrojove´ XML dokumentu a jeho editacı´

je mozˇne´ jej libovolneˇ upravovat obdobneˇ jako naprˇ. v Pozna´mkove´m bloku v prostrˇedı´

Windows. Je du˚lezˇity´ zejme´na v prˇı´padeˇ, kdy uzˇivatel chce do dokumentu prˇidat neˇjaky´

element, ktery´ v uzˇivatelske´m prostrˇedı´ editoru nenı´ prˇı´tomen. Tento postup editace XML je asi nejme´neˇ pohodlny´ a vyzˇaduje po uzˇivateli urcˇitou odbornost.

Editace elementu˚ a atributu˚ – je zrˇejme´, zˇe hlavnı´m u´cˇelem editoru je zmeˇna editovane´ho kontextu. V prˇı´padeˇ XML jde o prˇida´va´nı´, resp. maza´nı´ elementu˚ a editace jejich obsahu.

Zvy´raznˇ ova´nı´ syntaxe – pro lepsˇı´ prˇehlednost zdrojove´ho XML snad kazˇdy´ editor nabı´zı´ mozˇ- nost zvy´raznˇova´nı´ syntaxe v rezˇimu zdrojove´ho ko´du (acˇkoliv webove´ editory jsou vy´jim- kou).

Kontrola validity – uzˇivatelske´ rozhranı´ editoru by meˇlo umozˇnˇovat uzˇivateli prˇida´vat na urcˇite´

pozice takove´ elementy, ktere´ jsou v dane´m kontextu platne´. Aplikace by meˇla zabra´nit operacı´m, jejichzˇ vy´sledkem by byl nevalidnı´ dokument.

Nacˇı´tanı´ a ukla´da´nı´ dokumentu – samozrˇejmostı´ je mozˇnost ulozˇenı´ a opeˇtovne´ nacˇtenı´ vyvı´- jeny´ch dokumentu˚.

Rezˇim rozbalovacı´ho stromu – jde o rezˇim, ve ktere´m je dokument zobrazen jako rozbalovacı´

strom, ktery´ je prˇehledneˇjsˇı´ nezˇ samotny´ zdrojovy´ ko´d. Pro cˇloveˇka, ktery´ se s XML teprve seznamuje, ma´ tento rezˇim na´zorny´ vy´znam.

Podpora jmenny´ch prostoru˚ – v jazyce XML je mozˇne´ kombinovat neˇkolik jazyku˚ do jednoho dokumentu pomocı´ tzv. jmenny´ch prostoru˚. I s tı´m by meˇl editor pocˇı´tat naprˇ. formou dyna- micke´ho uzˇivatelske´ho rozhranı´, ktere´ se aktualizuje na za´kladeˇ pra´veˇ aktivnı´ho jmenne´ho prostoru.

(26)

WYSIWYG rezˇim – mu˚j editor navı´c nabı´zı´ WYSIWYG rezˇim, ktery´ umozˇnˇuje editaci XML bez znalosti konkre´tnı´ho XML jazyka a dokonce i bez znalosti jazyka XML jako takove´ho. Je to du˚lezˇity´ prvek jake´hokoliv editoru, ktery´ existuje na webove´ stra´nce. Protozˇe vyvı´jı´m webovy´ editor, lze v neˇm takto psa´t pouze XML pro takove´ jazyky, ktere´ lze prˇeve´st na HTML ekvivalent. V opacˇne´m prˇı´padeˇ, lze pouzˇı´t editor bez WYSIWYG rezˇimu.

3.1 Na´vrh aplikace

Framework jQuery, ktery´ vyuzˇı´va´m v tomto projektu, nabı´zı´ rˇadu uzˇitecˇny´ch funkcı´. Jednou z nich je pohodlny´ vy´voj za´suvny´ch modulu˚ (pluginu˚) libovolneˇ rozsˇirˇujı´cı´ jQuery o novou funk- cionalitu. Psanı´ pluginu˚ v jQuery je velmi snadne´ a pohodlne´, stacˇı´ rozsˇı´rˇit objekt prˇedstavujı´cı´

jQuery (ten je prˇı´stupny´ pomocı´ funkce $) o metodu tvorˇı´cı´ novy´ plugin. V prˇı´padeˇ OOP prˇi vy´voji jQuery pluginu˚ definuje kazˇdy´ novy´ plugin novou trˇı´du a uvnitrˇ inicializacˇnı´ metody pluginu je vytvorˇena instance te´to trˇı´dy.

Obra´zek 11: Diagram trˇı´d XML editoru

Instance trˇı´d navrzˇene´ pro u´cˇely me´ho XML editoru spolupracujı´ prostrˇednictvı´m korˇenove´ho objektu xmlEdit. Jde o kompozitnı´ objekt spravujı´cı´ jednotlive´ cˇa´sti editoru. Jakmile je in-

(27)

stanciova´n objekt xmlEdit, jsou take´ automaticky inicializova´ny ostatnı´ pluginy reprezentujı´cı´

podrˇı´zene´ cˇa´sti kompozice xmlEditu. Jednotlive´ pluginy lze pouzˇı´t samostatneˇ bez xmlEditu v jiny´ch JS aplikacı´ch. Dalsˇı´ vy´hodou tohoto na´vrhu je pohodlna´ orientace ve zdrojovy´ch skrip- tech, ladeˇnı´ a rozsˇı´rˇitelnost, protozˇe jednotlive´ u´pravy jsou prova´deˇny na u´rovni jednotlivy´ch modulu˚, neza´visle na zbytku aplikace.

3.2 Zpracova´nı´ dat forma´tu XML

Prˇi vy´voji aplikacı´, ktere´ jakkoliv pracujı´ s XML je du˚lezˇite´ veˇdeˇt, jak zpracova´vat data forma´tu XML pomocı´ programove´ho rozhranı´ dostupne´ho v dane´m programovacı´m jazyce. Nejprosteˇjsˇı´

mozˇnost je zpracova´vat XML jako textovy´ rˇeteˇzec a vyuzˇı´t dostupne´ API pro pra´ci s textem (v prˇı´padeˇ JS naprˇ. regula´rnı´ vy´razy, nebo metody, ktere´ nabı´zı´ objekt String). Neˇkdy je tento prˇı´stup postacˇujı´cı´, ale mnohe´ operace jsou v neˇm obtı´zˇneˇ realizovatelne´ a neefektivnı´.

Proto existujı´ API specializovane´ prˇı´mo pro pra´ci s XML, jsou to SAX, ve ktere´m programa´tor pomocı´ tzv. callback funkcı´ reaguje na urcˇite´ uda´losti XML dokumentu a o neˇco pomalejsˇı´ avsˇak flexibilneˇjsˇı´ DOM, ktery´ je v podstateˇ odrazem XML na poli OOP.

DOM byl standardizova´n W3C a lze ho pouzˇı´t i v prˇı´padeˇ HTML dokumentu˚, proto ho webove´ prohlı´zˇecˇe nativneˇ podporujı´ a v prˇı´padeˇ XML v JS se vyuzˇı´va´ pra´veˇ DOM. Z hlediska optimalizace je velky´m proble´mem fakt, zˇe ru˚zne´ prohlı´zˇecˇe implementujı´ ru˚zne´ cˇa´sti DOM a do- konce neˇkdy stejne´ vlastnosti zprˇı´stupnˇujı´ pod ru˚zny´mi symbolicky´mi na´zvy. Cı´lem ru˚zny´ch JS frameworku˚ vcˇetneˇ jQuery cˇasto by´va´ mimo jine´ i rˇesˇenı´ teˇchto nekompatibilit.

DOM je robustnı´ rozhranı´ a proto je rozdeˇleno do neˇkolik cˇa´stı´ (tzv. DOM levels), cˇasto webovy´m vy´voja´rˇu˚m stacˇı´ pouze jeho za´kladnı´ cˇa´st (DOM level 1), kterou implementujı´ snad vsˇechny webove´ prohlı´zˇecˇe. V nı´ je mozˇne´ libovolneˇ procha´zet dokument a modifikovat jeho obsah. DOM dokument zabere v pameˇti pocˇı´tacˇe vı´c nezˇ samotny´ zdrojovy´ ko´d dokumentu, avsˇak jednotlive´ operace s dokumentem jsou daleko efektivneˇjsˇı´ a rychlejsˇı´, nezˇ kdyby se procha´zel zdrojovy´ ko´d reprezentovany´ textovy´m rˇeteˇzcem. Prˇedstavte si naprˇ., zˇe se potrˇebujete odka´zat na textovy´ obsah dokumentu. V prˇı´padeˇ textove´ho rˇeteˇzce, i za pouzˇitı´ regula´rnı´ch vy´razu˚ budou vy´sledkem atomicke´ operace procha´zejı´cı´ rˇeteˇzec znak po znaku. Prˇi pouzˇitı´ DOM se stacˇı´ odka´zat na jednu adresu v pameˇti pocˇitacˇe. Na druhou stranu, pokud chcete vytvorˇit novy´ element, by´va´ to zpravidla jednoduche´ realizovat pomocı´ textove´ho rˇeteˇzce. Stacˇı´ v neˇm mı´t ulozˇeny´ jeho zdrojovy´

ko´d, nicme´neˇ naprˇ. vytvorˇenı´ jednoduche´ho odstavce s jednou textovou veˇtvı´ vyda´ v DOM na neˇkolik rˇa´dku˚ ko´du a vy´sledek nenı´ zrovna prˇehledny´.

(28)

Framework jQuery se da´ z urcˇite´ho hlediska cha´pat jako nadstavba DOM. Metody jQuery pro manipulaci dokumentu prˇipomı´najı´ DOM, dokonce ho rozsˇirˇujı´ o neˇktere´ nove´ funkce a rˇesˇı´

neˇktere´ nekompatibility. Velikou vy´hodou take´ je, zˇe lze v jQuery libovolneˇ kombinovat textove´

rˇeteˇzce prˇedstavujı´cı´ dokument nebo CSS selektor s rozhranı´m DOM. Je tak mozˇne´ naprˇ. vlozˇit do dokumentu novy´ element zadany´ textovy´m rˇeteˇzcem a na´sledneˇ se na neˇj odkazovat pomocı´

jQuery nebo prˇı´mo DOM API. Na druhou stranu jQuery jako framework pro JS se zameˇrˇuje na jazyk HTML, prˇestozˇe v neˇm lze jednotneˇ prˇeva´deˇt DOM dokument v HTML na rˇeteˇzec a naopak, v prˇı´padeˇ XML to nelze.

3.2.1 Parserova´nı´ XML do Document Object Modelu

Protozˇe XML data prˇedstavujı´cı´ kontext editoru zpracova´va´m v JS pomocı´ DOM, steˇzˇejnı´m atri- butem objektu XMLedit je reference na XML DOM. Ten prˇedstavuje objektovy´ obraz editovane´ho XML dokumentu a je tvorˇen instancemi objektu˚, ktere´ reprezentujı´ jednotlive´ XML veˇtve (tzv.

DOM nodes). Veˇtve jsou na sebe nava´za´ny pomocı´ asociacı´ tak, zˇe ve vy´sledku vytva´rˇı´ cely´ strom XML, pro na´zornost uva´dı´m jednoduchy´ prˇı´klad na obr. 12. V kombinaci s jQuery lze s takovy´m XML stromem velmi efektivneˇ pracovat (vy´hodou je mozˇnost vyuzˇitı´ CSS selektoru˚), aby to vsˇak bylo mozˇne´, je du˚lezˇite´ instance DOM dokumentu nejprve vytvorˇit.

Obra´zek 12: Document Object Model (zdroj: vlastnı´)

O prˇevod XML (resp. HTML) dat ze zdrojove´ho ko´du do DOM se stara´ parser. Je to program (prˇı´padneˇ objekt), ktery´ obecneˇ prova´dı´ analy´zu dat textove´ho forma´tu. XML parsery kontrolujı´

validitu (viz kapitola 3.2.2) a v prˇı´padeˇ JS je jeho vy´stupem DOM resp. instance objektu DOM dokument. Acˇkoliv zde existujı´ drobne´ rozdı´ly mezi objekty XML DOM dokument a HTML

(29)

DOM dokument, azˇ na drobne´ odlisˇnosti je jejich rozhranı´ totozˇne´ (tvorˇı´ soucˇast specifikace W3C). Jazyk JS vyuzˇı´va´ XML parser zabudovany´ ve webove´m prohlı´zˇecˇi. IE vyuzˇı´va´ sve´ vlastnı´

nestandardnı´ rozhranı´, takzˇe skript vyuzˇı´vajı´cı´ XML parser musı´ by´t optimalizovany´, aby byl prˇenositelny´.

U´ lohy parserova´nı´ XML do DOM a jeho zpeˇtna´ serializace jsou za´sadnı´ pro cˇinnost neˇktery´ch cˇa´stı´ me´ho editoru. K tomu je vyuzˇı´va´n objekt XmlParser, ktery´ jsem navrhl tak, aby byl co mozˇna´ nejflexibilneˇjsˇı´. Stejneˇ jako jine´ cˇa´sti me´ aplikaci, lze jej pouzˇı´t samostatneˇ bez XmlEdit kdekoliv, kde je potrˇeba pracovat s XML v JS.

Obra´zek 13: Metoda pro nacˇtenı´ XML dokumentu

Mu˚j XmlParser umozˇnˇuje parserova´nı´ XML do DOM na za´kladeˇ jeho zdrojove´ho ko´du, nebo URL adresy. Protozˇe k u´loze prˇevodu XML do DOM ma´ blı´zko u´loha zpeˇtne´ho prˇevodu (serializace XML, neboli prˇevod DOM do textove´ho rˇeteˇzce), prˇidal jsem do XmlParseru i metody na serializaci. XmlParser navı´c doka´zˇe vra´tit zdrojovy´ ko´d XML na za´kladeˇ URL.

Na obr. 13 je soucˇa´st XmlParseru nacˇı´tajı´cı´ XML z jeho URL. Je to metoda, ktera´ pomocı´

argumentu url vra´tı´ referenci na noveˇ vytvorˇenou instanci trˇı´dy XML DOM dokument. K tomu vyuzˇı´va´ jednoduchy´ HTTP pozˇadavek (soucˇa´st specifikace DOM level 2), jehozˇ vy´sledek vra´tı´.

V prˇı´padeˇ IE, ktery´ DOM level 2 neimplementuje, se pouzˇije proprieta´rnı´ API Microsoftu. Rˇ a´dek 10 urcˇuje, zˇe skript nejprve pocˇka´ na odpoveˇd’. To je du˚lezˇite´, protozˇe jinak by nacˇı´ta´nı´ XML probı´halo paralelneˇ na pozadı´ a prˇed jeho dokoncˇenı´m by vy´sledek obsahoval nulovou referenci.

Ekvivalentem u HTTP pozˇadavku je parametr false v metodeˇ open na rˇa´dku 4.

Prˇi serializaci je pouzˇit obdobny´ postup. Opeˇt je to DOM level 2, kde je definova´na trˇı´da XMLSerializera API Microsoftu. V nı´ je definova´na vlastnost xml, ktera´ slouzˇı´ pouze pro cˇtenı´ a ukla´da´ text prˇedstavujı´cı´ prˇı´slusˇnou XML veˇtev (viz obr. 14).

Acˇkoliv takto optimalizovany´ XmlParser funguje ve vsˇech webovy´ch prohlı´zˇecˇı´ch, nenı´

vy´sledek vsˇude stejny´. Je to proto, zˇe specifikace DOM level 2 se lisˇı´ od implementacı´ Microsoft

(30)

Obra´zek 14: Serializace XML veˇtve

API. Take´ to je uka´zka toho, kdy prˇestozˇe je JS ko´d standardneˇ optimalizova´n a funkcˇnı´, ve skutecˇnosti v ru˚zny´ch prostrˇedı´ch vyprodukuje ru˚zny´ vy´sledek. To mu˚zˇe v neˇktery´ch prˇı´padech vyvolat nezˇa´doucı´ chova´nı´ vy´sledne´ho skriptu. Takovy´ch prˇı´padu˚ je v JS mnoho a prˇina´sˇı´ to dalsˇı´

komplikace beˇhem jeho optimalizace. DOM parser Microsoftu nezarˇazuje do vy´sledku textove´

veˇtve obsahujı´cı´ pouze bı´le znaky (tzv. white spaces, cˇili tabela´tory a zalomenı´ rˇa´dku˚), zatı´mco ostatnı´ prohlı´zˇecˇe to deˇlajı´. Ktery´ z prˇı´stupu˚ je lepsˇı´, je sporne´. Po odstraneˇnı´ teˇchto veˇtvı´ je manipulace s DOM stromem rychlejsˇı´, nakonec tyto veˇtve nenesou zˇa´dnou informaci tak procˇ je prosteˇ nesmazat? Z hlediska XML sice doopravdy nenesou zˇa´dnou informaci, ale nesou informaci o tzv. „sˇta´bnı´ kulturˇe“. Pokud chceme takto „osekany´“ DOM zobrazit v non-WYSIWYG rezˇimu, chybı´ v neˇm pu˚vodnı´ „sˇta´bnı´ kultura“ a vy´sledek vypada´ dost neprˇehledneˇ. Dalsˇı´ proble´m mu˚zˇe nastat prˇi procha´zenı´ DOM stromem, protozˇe elementy v DOM se „sˇta´bnı´ kulturou“ mohou tvorˇit jinou veˇtev stromu nezˇ v DOM zkonstruovane´m na za´kladeˇ stejne´ho dokumentu v IE.

3.2.2 Validace XML

Jednou ze silny´ch stra´nek jazyka XML je jeho flexibilita. Kazˇdy´ uzˇivatel si mu˚zˇe definovat vlastnı´

znacˇky (tagy) a v jake´m usporˇa´da´nı´ je lze prˇida´vat do XML dokumentu˚. Z toho plyne potrˇeba noveˇ vznikly´ jazyk zalozˇeny´ na XML neˇjaky´m zpu˚sobem definovat. Definicı´ XML jazyka je tzv.

sche´ma a existuje neˇkolik forma´tu˚, jsou to DTD ktere´ mimo jine´ pouzˇı´va´ jazyk HTML (pocha´zı´

z dob spolecˇne´ho prˇedka HTML a XML — jazyka SGML), moderneˇjsˇı´ XML Schema a RELAX NG.

Validace je v technologii XML proces, beˇhem ktere´ho je analyzova´n cı´lovy´ XML dokument, za u´cˇelem kontroly spra´vnosti konzistence dat vzhledem k dane´mu sche´matu. Je to du˚lezˇity´

proces, protozˇe nevalidnı´ XML by mohlo zpu˚sobit proble´my beˇhem dalsˇı´ho zpracova´nı´. Krom obecny´ch pravidel urcˇujı´cı´ch jak ma´ korektnı´ XML dokument vypadat (naprˇ. tagy musı´ by´t maly´mi pı´smeny), je du˚lezˇite´ se beˇhem psanı´ XML dokumentu˚ drzˇet dane´ho sche´matu. Tzn. prˇida´vat do dokumentu pouze elementy (resp. atributy), ktere´ jsou definova´ny ve sche´matu. Sche´ma navı´c vymezuje kam je mozˇne´ dany´ element prˇidat.

(31)

Kontrolu validity prova´dı´ parser (viz kapitola 3.2.1). Parsery mı´vajı´ vlastnosti beˇzˇny´ch konverzacˇnı´ch (interaktivnı´ch) prˇekladacˇu˚, takzˇe se dajı´ integrovat do na´stroju˚ pro pra´ci s XML.

Doka´zˇı´ uzˇivatele upozornit na rˇadu beˇzˇny´ch chyb, vcˇetneˇ jejich pozice. V prˇı´padeˇ webovy´ch parseru˚ je prˇi vy´skytu chyby vy´stupem nulova´ reference a ne reference na noveˇ vytvorˇeny´ DOM.

Platı´ to i v prˇı´padeˇ, zˇe XML data neodpovı´dajı´ zadane´mu sche´matu. Jednou z dobry´ch vlastnostı´

XML editoru˚ je, zˇe pomocı´ XML parseru doka´zˇı´ nabı´dnout uzˇivateli takove´ operace, ktere´ jsou v dane´m kontextu platne´. To je velmi uzˇitecˇne´, protozˇe se tak da´ prˇedejı´t mnoha chyba´m.

O kontrolu validity se v prˇı´padeˇ me´ho editoru stara´ objekt xmlValid. Jeho hlavnı´ u´lo- hou je oveˇrˇova´nı´ operacı´ typu vkla´da´nı´ a maza´nı´ elementu˚. Kdykoliv je potrˇeba, lze po- lozˇit xmlValidu jednoduchy´ dotaz formou jeho metody, jejı´zˇ na´vratovou hodnotou je hod- nota typu boolean. Mezi tyto metody patrˇı´: canAddElement(), canRemoveElement() a canChangeAttribute(), neboli: mohu prˇidat element, mohu odebrat element, mohu zmeˇ- nit atribut. Funguje tak, zˇe nejprve provede pozˇadovanou operaci (naprˇ. prˇida´ do dokumentu novy´

element) a pomocı´ xmlParseru urcˇı´, zda je vy´sledek validnı´. Pote´ vra´tı´ dokument do pu˚vodnı´

podoby a na´vratove´ hodnoteˇ prˇeda´ vy´sledek testu.

Nejproblematicˇteˇjsˇı´ byla implementace metody canRemoveElement(). Nejprve jsem zkousˇel pro oveˇrˇenı´ mozˇnosti odebra´nı´ elementu cı´lovou veˇtev naklonovat, pote´ odebrat z DOM stromu a po testu validity zpeˇtneˇ prˇipojit klon. Bohuzˇel tento zpu˚sob ma´ drobny´ nedostatek, ktery´

zpu˚soboval nespra´vnou cˇinnost jine´ho skriptu. Naklonovana´ XML veˇtev ma´ jinou adresu v pameˇti nezˇ pu˚vodnı´ a proto je vedlejsˇı´m efektem te´to metody jina´ pozice testovane´ veˇtve v pameˇti pocˇı´tacˇe, protozˇe je tvorˇena svy´m klonem. Proble´m nastane v prˇı´padeˇ, kdy prˇed pru˚beˇhem takto implementovane´ metody odkazuje na testovanou veˇtev neˇjaka´ reference. Tato reference se tak stane neplatnou (zacˇne odkazovat na null cˇily zˇa´dny´ objekt). Uveˇdomil jsem si, zˇe abych se vyhnul potrˇebeˇ klonova´nı´ za u´cˇelem zachova´nı´ mazane´ho objektu, budu potrˇebovat metodu, ktera´ na mı´sto smaza´nı´ DOM veˇtve jı´ pouze odpojı´, takzˇe bude nada´le fyzicky existovat, jenom uzˇ nebude soucˇa´stı´ pu˚vodnı´ho stromu DOM. Po skoncˇenı´ kontroly validity je veˇtev zpeˇtneˇ prˇipojena na pu˚vodnı´ mı´sto a vy´sledkem je pu˚vodnı´ DOM. Hledal jsem ve specifikaci DOM level 1 a metodu pro odpojenı´ veˇtve jsem nenasˇel, nasˇteˇstı´ jsem ale nasˇel v dokumentaci API jQuery metodu detach() vyhovujı´cı´ potrˇeba´m te´to rutiny.

Uzˇivatel mu˚zˇe pouzˇı´vat mu˚j editor i v prˇı´padeˇ, zˇe v XML dokumentu chybı´ informace ohledneˇ pouzˇite´ho sche´matu. V takove´m prˇı´padeˇ platı´ volna´ pravidla a lze prˇida´vat a odebı´rat libovolne´

elementy (korˇenovy´ element nelze odebrat nikdy).

(32)

3.3 Transformace XSLT

XML samo o sobeˇ vyjadrˇuje se´mantiku dat, ktere´ popisuje. Vsˇechny XML sche´mata by se meˇla rˇı´dit tı´mto pravidlem a nedefinovat naprˇ. elementy informujı´cı´ o forma´tova´nı´ resp. sazbeˇ. To je jeden ze za´sadnı´ch rozdı´lu˚ oproti jazyku HTML. Stejneˇ jako HTML dokumenty i XML dokumenty lze forma´tovat pomocı´ kaska´dovy´ch stylu˚ (CSS). Dokonce lze ve webove´m prohlı´zˇecˇi zobrazovat XML dokumenty forma´tovane´ pomocı´ CSS.

3.3.1 XSLT a du˚ vod jeho pouzˇitı´

Vy´hodou jazyka XML oproti HTML je podpora transformacı´ XSLT. Ta pracuje s XSL styly, cozˇ je stylovy´ jazyk navrzˇeny´ prˇı´mo pro XML. Beˇhem vy´voje te´to pra´ce jsem zvazˇoval, ktery´ z jazyku˚

pro forma´tova´nı´ XML vyuzˇiji pro umozˇneˇnı´ WYSWYG rezˇimu. V neˇm je nezbytne´ XML data neˇjaky´m zpu˚sobem forma´tovat. Jake´ jsou tedy pro a proti jazyka XSLT oproti CSS?

Obra´zek 15: Princip XSLT (zdroj: vlastnı´)

Prˇi volbeˇ stylove´ho jazyka pro XML platı´ jednoduche´, ale trefne´ rcˇenı´: „pouzˇij CSS kdyzˇ mu˚zˇesˇ a XSL, kdyzˇ musı´sˇ“. CSS je jednoduche´ na naucˇenı´ i na pouzˇitı´, proto mnoho WYSWYG editoru˚

pro XML vyuzˇı´va´ CSS. Jednoduchost CSS je vsˇak za´rovenˇ jeho slabou stra´nkou. Za cenu urcˇite´

slozˇitosti dostane uzˇivatel volı´cı´ forma´tova´nı´ pomocı´ XSL stylu˚ sˇirsˇı´ mozˇnosti a flexibilitu oproti

(33)

CSS. Vy´voj XSL stylu˚ tak trochu prˇipomı´na´ programova´nı´, existujı´ v neˇm smycˇky a rozhodovacı´

konstrukce obdobneˇ jako v strukturovane´m programova´nı´. Soubor obsahujı´cı´ XSL styl jsou vstupnı´ data pro transformaci XSLT (princip je zna´zorneˇn na obr. 15), na za´kladeˇ ktery´ch se generuje vy´stup. Ten mu˚zˇe prˇedstavovat prakticky jaky´koliv textovy´ forma´t, naprˇ. jine´ XML, cˇasto to by´va´ HTML. Usporˇa´da´nı´ vy´stupu XSLT transformace se mu˚zˇe za´sadnı´m zpu˚sobem lisˇit od pu˚vodnı´ho usporˇa´da´ni ve zdrojove´m XML. Mozˇnost libovolne´ho vy´stupnı´ho forma´tu a usporˇa´da´nı´

deˇla´ z XSLT sˇiroce pouzˇitelny´ na´stroj. Dı´ky mozˇnostem, ktere´ nabı´zı´ XSLT transformace jsem se rozhodl implementovat jej do vyvı´jene´ho XML editoru. Dalsˇı´m du˚vodem je fakt, zˇe veˇtsˇina uzˇivatelu˚ volı´ jazyka XML pra´veˇ dı´ky mozˇnosti prova´deˇt tyto transformace.

3.3.2 Implementace XSLT procesoru

Transformace XSLT ma´ na starost XSLT procesor (viz obr. 15). Existuje rˇada volneˇ dostupny´ch XSLT procesoru˚ prakticky pro vsˇechny platformy. Cˇasem zacˇali implementovat XSLT procesor i webove´ prohlı´zˇecˇe, prvnı´ z nich byl IE verze 5.0, na´sledoval Firefox verze 3 a Opera verze 9.

Stejneˇ jako v prˇı´padeˇ XmlParseru (viz kapitola 3.2.1) zpu˚sob pouzˇitı´ XSLT procesoru ve webove´m prohlı´zˇecˇi se lisˇı´ v IE. Abych tyto rozdı´ly sjednotil, definoval jsem trˇı´du XsltProc, ktera´ na za´kladeˇ dostupny´ch prostrˇedku˚ prova´dı´ transformace.

Obra´zek 16: Metoda pro transformaci XSLT

Trˇı´da XsltProc obsahuje pouze jednu metodu, pro vykona´nı´ samotne´ transformace. V jejı´m argumentu jsou prˇeda´ny: reference na instanci XmlParseru, XML zadany´ jako DOM, ktery´

se ma´ transformovat a URL adresa XSL stylu. Vsˇe je uka´za´no na obr. 16. Stejneˇ jako prˇi serializaci v IE je XSLT ota´zkou jednoho rˇa´dku ko´du (viz 4. rˇa´dek). Veˇtve DOM v IE totizˇ obsahujı´ metodu transformNode(), to je jedna z mnoha veˇcı´ v rozporu se standardy W3C.

V ostatnı´ch prˇı´padech je vytvorˇena instance xsltProcesor, ktera´ prˇedstavuje internı´ XSLT procesor prohlı´zˇecˇe, ktere´ je prˇeda´n XSL styl. Vy´sledkem je tzv. dokument fragment, co je to

(34)

dokument fragment nenı´ v te´to rutineˇ du˚lezˇite´, du˚lezˇite´ je, zˇe je kompatibilnı´ s instancı´ DOM node. Tzn., zˇe jı´ objekt prˇedany´ v referenci xmlParser umı´ serializovat, takzˇe je vra´cen textovy´

rˇeteˇzec prˇedstavujı´cı´ vy´sledek transformace. Serializace je du˚lezˇita´, aby byl vy´sledek schodny´

s vy´sledkem metody transformNode() implementovane´ v IE.

3.3.3 Mozˇnosti vy´sledne´ho modulu pro XSLT

Trˇı´dy XmlParser, XmlValid a XsltProc jsou za´kladnı´ prvky, ktere´ pouzˇı´va´ mu˚j editor.

Nevy´hodou XsltProc je, zˇe nevra´tı´ spra´vny´ vy´sledek, pokud prohlı´zˇecˇ nepodporuje XSLT. Na druhou stranu, pomocı´ XsltProc je mozˇne´ transformovat libovolnou XML veˇtev, takzˇe nenı´

potrˇeba transformovat pokazˇde´ cely´ dokument. Tuto vlastnost XSLT nevyuzˇı´va´ pouze mu˚j editor, jde o obecneˇ zna´mou alternativu Ajaxu (jazyk pro asynchronnı´ zpracova´nı´ XML v JS).

3.4 Zvy´razn ˇ ovacˇ syntaxe

S rozvojem programova´nı´ roste potrˇeba dobre´ orientace v ru˚zny´ch zdrojovy´ch ko´dech. Ko´dy mohou by´t obtı´zˇneˇ cˇitelne´ i prˇesto, zˇe jejich kode´r dodrzˇuje vhodnou sˇta´bnı´ kulturu (organizace tabela´toru˚ a zalomenı´ rˇa´dek). Proto kazˇdy´ kvalitnı´ editor zdrojove´ho ko´du forma´tuje text tak, aby v neˇm vyznacˇil naprˇı´klad klı´cˇova´ slova, komenta´rˇe, cˇi na´zvy identifika´toru˚. Kode´rovi tak usnadnı´ pra´ci a neˇkdy pomu˚zˇe odhalit chybu drˇı´ve nezˇ kompila´tor nebo interpret. Program resp.

objekt, ktery´ ma´ za u´kol takto forma´tovat zdrojove´ ko´dy nazveˇme zvy´raznˇovacˇ syntaxe (angl.

syntax highlighter, da´le ZS).

Vy´voj takove´ho ZS nenı´ trivia´lnı´ za´lezˇitostı´ a v jazyce JS na´rocˇnost jesˇteˇ roste kvu˚li po- trˇebeˇ optimalizace. Mozˇna´ proto webove´ editory zvy´raznˇova´nı´ syntaxe nepodporujı´. Ve webove´

u´schovneˇ pluginu˚ napsany´ch v JQuery se mi podarˇilo najı´t neˇkolik zvy´raznˇovacˇu˚ syntaxe, bo- huzˇel vsˇechny slouzˇı´ pouze ke generova´nı´ staticke´ho obsahu. Jsou tedy urcˇeny spı´sˇe vy´voja´rˇu˚m webu, kterˇı´ chteˇjı´ na sve´ stra´nky umı´stit uka´zky zdrojovy´ch ko´du˚, nezˇ vy´voja´rˇu˚m webovy´ch edi- toru˚. Protozˇe bych mozˇnost zvy´raznˇova´nı´ syntaxe ra´d implementoval do sve´ho editoru, rozhodl jsem se, zˇe se pokusı´m napsat vlastnı´ ZS, ktery´ bude pracovat i beˇhem editacˇnı´ho rezˇimu.

3.4.1 Na´vrh

Pro vy´voj me´ho ZS se hodı´ pouzˇı´t komponentu RE (viz kap.1), kterou jsem napsal v ra´mci sve´ho magisterske´ho rocˇnı´kove´ho projektu. Mu˚j ZS ji pouzˇije pro editacˇnı´ rezˇim a abych zajistil

(35)

Obra´zek 17: Funkce vracejici minimum dvou cˇı´sel v JavaScriptu

lepsˇı´ pouzˇitelnost sve´ho pluginu, umozˇnı´m i generova´nı´ staticke´ho obsahu. Take´ jsem se rozhodl pouzˇı´t pro uka´zky zdrojovy´ch ko´du˚ v te´to pra´ci pra´veˇ svu˚j ZS.

Pro kazˇdy´ jazyk existuje nespocˇet mozˇnostı´, co a jak by meˇl oznacˇovat. Je tedy du˚lezˇite´ ZS do znacˇne´ mı´ry ladit –– zkousˇet ru˚zne´ mozˇnosti a porovna´vat vy´sledky. Aby byl ZS dobrˇe odladi- telny´, je du˚lezˇite´ oddeˇlit od sebe problematiku pravidel na za´kladeˇ ktery´ch pracuje a problematiku samotne´ho algoritmu, ktery´ se postara´ o forma´tova´nı´. Nejdrˇı´ve jsem tedy sestavil rozhranı´ pro pravidla ZS a pak jsem se postaral o to, aby na za´kladeˇ kolekce teˇchto pravidel ZS pracoval.

Takto napsane´mu ZS se mohou prˇedat ru˚zna´ pravidla a realizovat tak ZS ru˚zny´ch jazyku˚. Volil jsem i mozˇnost tato pravidla nacˇı´tat z dat ve forma´tu XML. Stacˇı´ tedy jeden skript, a anizˇ by se meˇnil jeho zdrojovy´ ko´d, mu˚zˇe se pomocı´ neˇho realizovat ZS pro jaky´koliv jazyk.

Vzhled forma´tovany´ch cˇa´stı´ textu u webove´ho ZS je urcˇen pomocı´ CSS definic. ZS tedy zmeˇnı´

libovolne´ HTML na HTML obsahujı´cı´ stejny´ text tak, zˇe jsou v neˇm jednotlive´ cˇa´sti rozdeˇleny do elementu˚ span s prˇı´slusˇny´m atributem class. Uzˇivatel tak mu˚zˇe prˇipojenı´m ru˚zny´ch souboru˚

s CSS definicemi ZS snadno tzv.

”skinovat“. Takto navrzˇeny´ webovy´ ZS vyuzˇı´va´ standardnı´

forma´ty (XML a CSS), ktere´ jsou navı´c realizova´ny textovy´mi soubory. Umozˇnˇuje tak pohodlny´

vy´voj ru˚zny´ch na´stroju˚ pro tento plugin (naprˇ. i v jiny´ch jazycı´ch nezˇ v JS).

Abych prˇiblı´zˇil, jak ZS pracuje, uva´dı´m zde prˇı´klad na obra´zku 17 ty´kajı´cı´ se jazyka JS.

Je na neˇm jednoducha´ funkce vracejı´cı´ minimum dvou cˇı´sel definovany´ch argumentem funkce (identifika´tory a a b). Uka´zka obsahuje na´sledujı´cı´ klı´cˇova´ slova: function a return, ktere´ je potrˇeba zvy´raznit. Stejneˇ tak je vhodne´ zvy´raznit i symboly za´vorek, otaznı´k, dvojtecˇku, zname´nko mensˇı´ nezˇ, cˇa´rku a strˇednı´k. Da´le je zde slovo min, cozˇ je identifika´tor funkce a v poslednı´ rˇadeˇ komenta´rˇ, ktery´m uka´zka zacˇı´na´.

Necht’je da´na forma pravidel podle ktery´ch ZS oznacˇuje neˇjaky´ zdrojovy´ ko´d. Usporˇa´danou k-tici instancı´ teˇchto pravidel nazvu kolekcı´ pravidel ZS. Za´lezˇı´ zde na porˇadı´ pravidel v kolekci, nebot’ru˚zna´ pravidla majı´ ru˚znou prioritu. Pokud naprˇ. ZS oznacˇuje v JS text uvnitrˇ komenta´rˇe, klı´cˇova´ slova a ostatnı´ symboly v neˇm nehrajı´ roli.

ZS musı´ rozeznat, ktere´ u´seky textu˚ ma´ zvy´raznˇovat. Pravidla tedy obsahujı´ kromeˇ na´zvu trˇı´dy pro CSS styl i startovnı´ a koncovy´ rˇeteˇzec. Naprˇ. pro komenta´rˇ v uka´zce je startovnı´m

(36)

rˇeteˇzcem „/*“ a koncovy´m „*/“. Abych vymezil klı´cˇova´ slova, pouzˇiji pro neˇ jako startovnı´

rˇeteˇzec ono klı´cˇove´ slovo a pra´zdny´ rˇeteˇzec jako koncovy´. Symboly za´vorek, otaznı´k, dvojtecˇka atd. se dajı´ cha´pat jako klı´cˇova´ slova de´lky jedna.

U startovnı´ch a koncovy´ch rˇeteˇzcu˚ je navı´c potrˇeba rozezna´vat, kdy se jedna´ o slovo a kdy o prosty´ rˇeteˇzec. Slovem je mysˇlen rˇeteˇzec oddeˇleny´ od zbytku textu bı´ly´mi znaky. Naprˇ. v prˇı´padeˇ, zˇe by se v uka´zkove´m zdrojove´m ko´du nacha´zelo returns namı´sto return (mohlo by jı´t o prˇeklep), nechci aby v neˇm bylo return zvy´razneˇno a je to trˇeba vymezit v definici pravidla.

Podle me´ho na´vrhu tedy rˇeteˇzec koncˇı´cı´ mezerou bude slovo nikoli prosty´ rˇeteˇzec.

3.4.2 Implementace zvy´raznˇ ovacˇe syntaxe

Mu˚j ZS pracuje tak, zˇe analyzuje dany´ text rˇa´dek po rˇa´dku a vy´sledek zapisuje na vy´stup.

Steˇzˇejnı´ je tedy metoda, ktera´ na za´kladeˇ vstupnı´ho rˇeteˇzce vra´tı´ rˇeteˇzec prˇedstavujı´cı´ HTML ko´d s prˇı´slusˇny´mi elementy span. Pokud ZS beˇhem analy´zy textu narazı´ na startovnı´ rˇeteˇzec neˇktere´ho pravidla z kolekce s vysˇsˇı´ prioritou, nezˇ je pravidlo pra´veˇ aktivnı´, prˇestane by´t toto pravidlo aktivnı´m namı´sto pravidla pra´veˇ nalezene´ho. ZS navı´c musı´ pocˇı´tat s vı´ce pravidly najednou, naprˇ. v uka´zce na obr. 17 je klı´cˇove´ slovo function, ktere´ je oznacˇeno a navı´c je function startovnı´m rˇeteˇzcem pro vyznacˇenı´ identifika´toru funkce min. Proto kazˇde´ dalsˇı´

aktivnı´ pravidlo ukla´da´m na vrchol FILO za´sobnı´ku (prvnı´ dovnitrˇ, poslednı´ ven), a po jeho skoncˇenı´ ho z neˇj opeˇt odeberu, takzˇe na jeho vrcholu zu˚stane pravidlo prˇedchozı´. Tento proces funguje bezproble´moveˇ a na za´kladeˇ ru˚zny´ch kolekcı´ pravidel ZS produkuje ru˚zne´ vy´sledky, prˇesneˇ podle ocˇeka´va´nı´.

Obra´zek 18: Mozˇnosti rˇa´dkova´nı´ v HTML

Kdyzˇ je vyrˇesˇen proble´m samotne´ho zvy´raznˇova´nı´ textu, nenı´ proble´m pouzˇı´t takovy´to ZS pro generova´nı´ staticke´ho obsahu. Zby´va´ prˇizpu˚sobit ZS tak, aby umozˇnˇoval i editacˇnı´ rezˇim. V tomto

References

Related documents

Tento budič je koncovým prvkem generátoru obdélníkového průběhu napětí a slouží k posílení výstupu a zároveň z výstupního signálu hradlového pole o

odevzdand pr5ce nese znilmky spdchu a nedbalosti, obsahuje iadu.typografickfch, stylistycklTch a gramaticklich nedostatkrj.. le stoJa, ze zde nebyto l6pe vyuzito

V této diplomové práci budu řešit návrh a tvorbu webové aplikace sloužící k vizualizaci průchodu paketu počítačovou sítí, kde je kladen důraz na zobrazení

Důležitým prvkem pro celou konstrukci je řídící jednotka, která se stará o stabilitu celého zařízení a použité regulátory, které pracují s řídícími

Alternativou, která však již nefunguje na bázi XML, a tím pádem vylučuje využití SOAP, může být i předání nestrukturovaných dat s primitivními datovými

Při návrhu je nutno dbát na omezující podmínku, že v daný okamžik lze provozovat pouze jednu úlohu (dle Na jedné stanici (server) bude možno v jeden okamžik

Mezi základní filtry patří například Servlet Config, který realizuje nastavení části kontextu akce na základě implementovaného rozhraní..

Tabulka SmpIdentifyDB obsahuje informace o názvu a typu přístroje v budově a svým primárním klíčem se relací odkazuje do tabulky SmpMeasNameDB, která obsahuje