Een MSML-gebaseerde scenario-editor voor ...lib.ugent.be/fulltxt/RUG01/001/312/493/RUG01...Een...

Pieterjan De Potter

bestandsgebaseerde fictieproductieEen MSML-gebaseerde scenario-editor voor

Academiejaar 2007-2008Faculteit IngenieurswetenschappenVoorzitter: prof. dr. ir. Jan Van CampenhoutVakgroep Elektronica en informatiesystemen

Burgerlijk ingenieur in de computerwetenschappenScriptie ingediend tot het behalen van de academische graad van

Begeleiders: Dieter Van Rijsselbergen, Barbara Van De KeerPromotor: prof. dr. ir. Rik Van de Walle

Voorwoord

Enkele jaren geleden heeft de informatietechnologie terug een grote stap voorwaarts gezet.Met Web 2.0 zijn er nieuwe mogelijkheden geopend voor het gebruik van het wereldwijdeweb. Nieuwe, interactieve webapplicaties zorgen ervoor dat het grootste netwerk ter we-reld, het internet, meer dan ooit tevoren kan worden gebruikt voor productieve, creatieve,sociale en ook nog andere doeleinden. Het is mijn interesse in deze nieuwe wending vanhet gebruik van netwerken die me heeft aangezet tot het kiezen van dit onderwerp.

Ik zou graag de mensen willen bedanken die de keuze van dit onderwerp mogelijkhebben gemaakt en mij hebben ondersteund waar nodig.

Vooraleerst zou ik mijn promotor Prof. Van de Walle willen bedanken voor het creerenvan de opportuniteit mij in te werken in deze materie. Zeker wens ik ook mijn begeleidersDieter Van Rijsselbergen en Barbara Van De Keer te bedanken voor de info, het gedulden de tips.

Wie zeker niet mogen ontbreken in deze dankbetuigingen zijn mijn ouders, die mij allesteun hebben geboden om mij te laten uitgroeien tot wie ik nu ben. Verder wil ik ook alleandere mensen uit mijn omgeving bedanken die mij gesteund hebben, niet alleen tijdensdit afstudeerwerk, maar ook tijdens het nemen van alle obstakels die ervoor kwamen.

Pieterjan De Potter, mei 2008

i

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delenvan de scriptie te kopieren voor persoonlijk gebruik.Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder metbetrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen vanresultaten uit deze scriptie.”

Pieterjan De Potter, mei 2008

ii

Een MSML-gebaseerde scenario-editor voorbestandsgebaseerde fictieproductie

doorPieterjan De Potter

Afstudeerwerk ingediend tot het behalen van de graad vanMaster in de ingenieurswetenschappen: computerwetenschappen

Academiejaar 2007-2008

Universiteit GentFaculteit IngenieurswetenschappenVakgroep Elektronica en informatiesystemenVoorzitter: prof. dr. ir. J. Van Campenhout

Promotor: prof. dr. ir. R. Van de WalleThesisbegeleiders: lic. Dieter Van Rijsselbergen, lic. Barbara Van De Keer

Samenvatting

In dit werk wordt een webgebaseerde scenario-editor ontwikkeld, gegeven de randvoor-waarden enerzijds opgelegd door een reeds aanwezig centraal beheersysteem en anderzijdsbepaald door de benodigde gebruiksvriendelijkheid. In eerste instantie wordt onderzochtmet behulp van welke technologie deze applicatie het best wordt geımplementeerd. Daar-na wordt de scenario-editor eerst ontwikkeld voor de Mozilla Firefox webbrowser, waarnaook de implementatie voor andere veelvoorkomende browsers wordt bekeken.

Trefwoorden: XHTML, JavaScript, AJAX, XSLT

iii

A MSML-based scenario editor for file basedproduction of fiction

Pieterjan De Potter

Supervisor(s): Rik Van de Walle, Dieter Van Rijsselbergen, Barbara Van De Keer

Abstract— This article describes the creation of a web-based editor forthe editing of scenarios and the data model designed to succeed in this pur-pose.

Keywords—XHTML, JavaScript, AJAX, XSLT

I. INTRODUCTION

IN the current digital era, a lot of broadcasters are switchingor have already switched to a file based production system.

With the use of a central management system (among others forthe storage of files), it is possible to enhance the cooperation be-tween the broadcasters of television and the different productionhouses. By providing a scenario editor in this system, one hopesto enhance the productivity in the production houses.

The creation of the editor starts with the study of the require-ments. In a next step, these demands are used to choose whichtechnology is going to be used for the implementation. Becausethe layout of the files that are stored in the centralised manage-ment system is not suited for the use in the editor, there is needfor a different representation of the content of these files. Dur-ing the implementation itself, there are some more problems tosolve.

II. STUDY OF THE REQUIREMENTS

The requirements can be split up into two groups: the non-technical (dictated by the end users) and the technical ones (nec-essary to fit the editor into the management system).

A. Non-technical requirements

For the study of the non-technical requirements, different ex-isting screenwriting suites (Final Draft, Movie Magic Screen-writer and Celtx) are compared. The existing screenwriter ap-plications are stand-alone applications, therefore they cannot fitin the central management system. Following requirements canbe deduced from the comparison:• Auto completion of frequently used items (like names of per-sonages).• Suggestion of the style the end user most likely is going to usewhen a new line is inserted.• A clear indication of which style is used on selected text.• A clear indication of the available keyboard shortcuts.• A spellchecker.

B. Technical requirements

Where the end user decides upon the functionality the editorhas to offer, the already existing central management system re-stricts the technology that can be used to implement the editorand the way in which the scenarios are saved:

• The editor has to use the web interfaces provided by the cen-tral management system to retrieve or save scenarios.• In the central management system, the scenarios are XML-formatted and comply to the MSML-specification1

• The central management system offers a web interface to theuser. If the editor is developed as a web based application, it canbe integrated in this system.

III. CHOICE OF TECHNOLOGY

Knowing the requirements for the editor, the first thing to donext is to choose which technology will be used to create thefunctionality the user expects, taking the technical requirementsinto account. There is more than one technology available thatcan be used to create a web-based editor. The most promisingones are: Java, Adobe Flash, Microsoft Silverlight, Google WebToolkit (GWT) and JavaScript.

Java (more specific Java applets), Adobe Flash and MicrosoftSilverlight need a plugin to be installed in the user’s webbrowser. This implies that an application developed with oneof these technologies will not be able to use all the functionalityoffered by the browser (which includes a spellchecker). GWTis not chosen because the scenario editor is a solution to a ratherspecific problem, so it is not worth doing the overhead to makea GWT widget for the editor [2]. JavaScript has its drawbackswhen it comes to cross-browser portability, but with the use ofJavaScript libraries, this problem can be reduced to a very mini-mum. In addition, there are JavaScript based text editors on themarket that can be used as a reference . These solutions them-selves cannot be used as scenario editors because there are nosyntactic checks or the syntactic checks are not sufficient. Be-cause JavaScript only has a minor drawback when it comes tocross-browser portability, JavaScript is chosen in this specificcase.

IV. DATAMODEL

The XML format used to store the scenarios in the centralmanagement system cannot be used to represent the scenario tothe end users in a way they expect the scenario to be represented[1]. Taking into account the use of JavaScript, a data model isdesigned to describe the various representations of the scenariothat are used in the system.

XHTML The format for the representation to be shown toand edited by the end user is XHTML. On the one hand usingXHTML makes it possible to add style which is very importantfor de user experience. On the other hand, a document in the

1The Movie Script Markup Language (MSML) contains a set of rules inventedfor the use in scenarios of fiction series.

XHTML format has to follow strict rules, which is why it ispossible to convert an XHTML document to an XML document(in this specific situation this means that an edited scenario canbe stored in the central management system).

XSLT Besides the XHTML format, there is also a need forthe conversion from an XML document to an XHTML doc-ument and vice versa. For this conversion, XSL transforma-tions are used because they are implemented in most of the webbrowsers and it is possible to initiate the transformation fromJavaScript. The slowness and the use of too much memory, thebig drawbacks of XSL transformations in comparison to othertechniques, are not really a problem here because the scenariofiles are small enough.

CSS To make the editor more flexible (by giving the differ-ent production houses the opportunity to easily use their properlayout on a scenario), the style information of the XHTML doc-ument is collected into a CSS file.

Overview An overview of the used conversion scheme isshown in figure 1.

Fig. 1. Conversion scheme

V. IMPLEMENTATION

After the choice of the used technology and the definition ofthe data model, the description of the implementation phase canbegin.

A. General concepts

First some general concepts, without which it would be im-possible to create a scenario editor in JavaScript, are considered.

DOM The Document Object Model (DOM) is used byJavaScript to represent HTML and XML documents in a stan-dard object model. This model makes it possible to navigate inan HTML or an XML file and to add eventListeners to HTMLelements.

AJAX Asynchronous JavaScript and XML is a group of tech-niques used for the creation of interactive web pages. Us-ing asynchronous communication, the JavaScript engine is notblocked during a request to the server. Using the XMLHttpRe-quest object, the information can be sent to or retrieved from theserver without reloading the page.

First browser Because JavaScript is interpreted differentlyby different browsers, it is important to decide for which webbrowser the editor will be implemented first. Mozilla Firefoxseems to be the best choice since it has extensions to facili-tate developing (including a JavaScript debugger), it is cross-platform, it has a built-in spellchecker and it tries to keep to the

W3C2 DOM recommendations.

B. Implementation aspects

Some of the implementation aspects require special attention.Generic To enable an easy adaptation of the editor when the

MSML-specification changes and to expand the area of its pos-sible use, all of the features of the editor related to style can beconfigured using a configuration file. In this way, it is for ex-ample possible to turn the scenario editor into an ordinary editorwith style options like bold, italic, . . .

Undo/redo Most web based text editors have an incompleteundo/redo-functionality: whether it is possible to undo changesto the layout of the text or whether it is possible to undo thetyping or removal of text. By using a state model of the ac-tions on the text (layout, typing, removal, inserting a new line,replacement of the cursor) it is possible to offer an undo/redo-functionality which is far more instinctive.

C. Support for other browsers

Regarding the market share of Mozilla Firefox, which is stillonly 17,76%[3], it is necessary to provide support for other webbrowsers too.

Microsoft Internet Explorer Besides some minor differ-ences between Microsoft Internet Explorer and Mozilla Firefoxthat can be easily fixed, there is a major problem concerning theselection of text in an HTML document. Microsoft Internet Ex-plorer uses a string-based Text Range model, which makes it ex-tremely hard to obtain the selected DOM node knowing a TextRange. Because of this problem, it is impossible to create aneditor for Microsoft Internet Explorer. Without knowing whichnode is selected, it is impossible to determine the formatting ofthe selected text.

Safari Safari does not generate a keyPressed event on all keysthat can be pressed. Due to this issue, not all keyboard shortcutscan be offered in the Safari web browser.

Opera In Opera the problems are of a different kind. It isimpossible to obtain the focus on the text field of the editor usingJavaScript and it is impossible to notify the user when he or sheis leaving the page.

VI. CONCLUSIONS

It is possible to create a scenario editor using JavaScript ful-filling all the needs, supporting Mozilla Firefox. The interpre-tation of JavaScript by the different browsers is so different thatit makes it impossible to support all browsers. On the brightside, Mozilla Firefox is a cross-platform browser so the editor isaccessible to all users who want to make a little effort.

REFERENCES

[1] Syd Field, Screenplay: the foundations of screenwriting, Bantam Dell,2005.

[2] Robert Hanson and Adam Tacy, GWT in Action: Easy Ajax with the GoogleWeb Toolkit, Manning Publications Co., 2007.

[3] Browser Market Share, http://marketshare.hitslink.com/report.aspx?qprid=0

2The World Wide Web Consortium (W3C) is an international consortium de-veloping standards for the world wide web.

Inhoudsopgave

1 Inleiding 1

1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Vereisten 3

2.1 Niet-technische vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Technische vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Technologiekeuzes 12

3.1 Technologieen die een plug-in vereisen . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Java-applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 Adobe Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3 Microsoft Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Technologieen die geen plug-in vereisen . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Google Web Toolkit (GWT) . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Keuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Datamodel en integratie 17

4.1 Scenario in XML-formaat . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Weergave aan de eindgebruiker . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 Scenario in XHTML-formaat . . . . . . . . . . . . . . . . . . . . . . 19

4.2.2 Transformatie tussen de formaten . . . . . . . . . . . . . . . . . . . 19

4.2.3 Opmaak met behulp van CSS . . . . . . . . . . . . . . . . . . . . . 21

4.3 Schematisch overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vi

5 Implementatie 25

5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.1 Het Document Object Model (DOM) . . . . . . . . . . . . . . . . . 25

5.1.2 Asynchroon JavaScript en XML (AJAX) . . . . . . . . . . . . . . . 26

5.1.3 Eerste webbrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Implementatieaspecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.1 Opmaakstijlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.2 Genericiteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.3 IFRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.4 Tekstselectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.5 Undo/redo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.6 Communicatie met de server . . . . . . . . . . . . . . . . . . . . . . 33

5.3 Opbouw van de editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Initialisatie van de applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.5 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.5.1 Koptekst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.5.2 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5.3 Opmaakbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5.4 Tekstveld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.5.5 Venster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.6 Ondersteuning voor andere browsers . . . . . . . . . . . . . . . . . . . . . 49

5.6.1 Microsoft Internet Explorer . . . . . . . . . . . . . . . . . . . . . . 49

5.6.2 Safari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.6.3 Opera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.6.4 Andere browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Resultaten en toekomstig werk 55

6.1 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2 Toekomstig werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

vii

A Model 57

A.1 De MSML-specificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A.2 De XSL-transformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A.2.1 XSL-transformatie (XML naar XHTML) . . . . . . . . . . . . . . . 60

A.2.2 Inverse XSL-transformatie (XHTML naar XML) . . . . . . . . . . . 61

B Configuratie 62

C Gebruikershandleiding 63

C.1 Opstarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

C.2 Koptekst aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

C.3 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

C.3.1 Opmaakbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

C.3.2 Tekstveld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

C.4 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

C.4.1 Bestand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

C.4.2 Bewerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

C.4.3 Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

D Cd-rom 72

Bibliografie 74

viii

Gebruikte afkortingen

AJAX Asynchronous Javascript And XML

CSS Cascading Style Sheets

DOM Document Object Model

FIPA File-based Integrated Production Architecture

HTML HyperText Markup Language

JVM Java Virtual Machine

MSML Movie Script Markup Language

VRT Vlaamse Radio- en Televisieomroep

W3C World Wide Web Consortium

XHTML eXtensible HyperText Markup Language

XML eXtensible Markup Language

XSLT eXtensible Stylesheet Language Transformations

URL Uniform Resource Locator

ix

Hoofdstuk 1

Inleiding

In dit eerste, inleidende hoofdstuk wordt in de probleemstelling het kader geschetst waar-

binnen deze verhandeling zich situeert. Na deze probleemstelling volgt een overzicht van

de inhoud van de volgende hoofdstukken.

1.1 Probleemstelling

Binnen diverse omroepen werd recent overgeschakeld op bestandsgebaseerde productie

van verschillende programma’s. Door het gebruik van digitale bestanden opgeslagen op

een centraal platform in plaats van het uitwisselen van videobanden, is het mogelijk de

productiviteit binnen de omroepen en binnen de productiehuizen te verhogen en de samen-

werking tussen de omroepen en verschillende productiehuizen vlotter te laten verlopen.

Meer specifiek situeert deze scriptie zich binnen de fictieproductie bij de openba-

re omroep VRT, waar de overschakeling naar bestandsgebaseerde productie in de na-

bije toekomst plaatsvindt. Binnen het FIPA-project1 dat loopt aan het IBBT2 is reeds

een centraal beheersysteem voor synopsissen, scenario’s en draaiboeken uitgedacht en

geımplementeerd. Er is echter nog nood aan een systeem waarmee scenario’s op een

eenvoudige manier kunnen worden aangemaakt en bewerkt. Het ontwikkelen van een der-

1Het File based Integrated Production Architecture (FIPA) project [5] heeft tot doel het ontwikkelenvan een IP-gebaseerde architectuur om opslag en rekenkracht te delen over een of meerdere sites. Eenvan de toepassingsgebieden is de productie van digitale media.

2Het Interdisciplinair Instituut voor BreedBandTechnologie [8] is een onafhankelijke onderzoeksinstel-ling die in opdracht van de Vlaamse overheid innovatie binnen ICT stimuleert.

1

gelijke editor, die moet voldoen aan vereisten die worden opgelegd door het beheersysteem

en door de eindgebruiker, is het doel van deze scriptie.

1.2 Overzicht

Bij het ontwikkelen van een applicatie is “doing the right thing” minstens even belangrijk

als “doing the thing right”. Daarom wordt in hoofdstuk 2 een opsomming gemaakt van

de vereisten waaraan door de editor moet worden voldaan. Ook komen in dat hoofd-

stuk verschillende softwareoplossingen aan bod die tegenwoordig worden gebruikt voor

gelijkaardige problemen en wordt nagegaan of door aanpassing niet aan de vereisten kan

worden voldaan.

Hoofdstuk 3 biedt een overzicht van de verschillende technologieen die voorhanden zijn

voor de implementatie van een webgebaseerde editor. Hier wordt de beslissing genomen

welke technologie uiteindelijk wordt gebruikt voor de implementatie.

De scenario’s kunnen in de vorm waarin ze opgeslagen zijn in het centraal beheersys-

teem niet ter bewerking aan de eindgebruiker worden weergegeven. In hoofdstuk 4 wordt

een conceptueel datamodel uitgewerkt dat de onderliggende basis voor de editor wordt. In

dit datamodel worden de verschillende vormen waarin een scenario in de editor aanwezig

is, samen met de transities ertussen, beschreven.

Enkele belangrijke beslissingen met betrekking tot de implementatie komen aan bod

in hoofdstuk 5.

Hoofdstuk 6 besluit deze scriptie met een overzicht van de realisaties en wat er in de

toekomst nog mogelijk is.

2

Hoofdstuk 2

Vereisten

De vereisten gesteld aan de scenario-editor kunnen worden verdeeld in twee groepen: niet-

technische en technische. De niet-technische vereisten omvatten de verwachtingen die de

eindgebruiker heeft van de applicatie. De technische vereisten beschrijven de omgeving

waarin de editor moet functioneren.

2.1 Niet-technische vereisten

In het kort kunnen de niet-technische vereisten als volgt worden opgelijst:

• De eindgebruiker wenst een gebruiksvriendelijke applicatie. De creativiteit van sce-

naristen mag zeker niet worden gehinderd door een applicatie die te moeilijk of niet

voldoende intuıtief is.

• Een productiehuis maakt gebruik van een eigen lay-out voor het schrijven van scena-

rio’s. Het is de bedoeling dat deze lay-out behouden kan blijven en indien nodig later

nog kan worden aangepast. Het moet dus voor een bepaald productiehuis mogelijk

zijn om een van de opmaakstijlen volledig weg te laten of een extra opmaakstijl toe

te voegen.

• De installatie en configuratie van de applicatie moeten eenvoudig zijn en vlekkeloos

verlopen, aangezien de applicatie door scenaristen liefst ook van thuis uit kan worden

gebruikt.

3

Vooral de vereiste met betrekking tot de gebruiksvriendelijkheid is niet eenvoudig te

omlijnen. Om te zien wat de eindgebruiker juist verwacht van een scenario-editor, worden

enkele bestaande oplossingen onder de loep genomen.

Final Draft (zie figuur 2.3) Final Draft is de industriestandaard op het gebied van

tekstverwerkers ontworpen voor het schrijven van scenario’s. Het is het enige softwarepak-

ket om scripts te schrijven dat een overeenkomst heeft met de “Writers Guild of America,

West” om scripts op een eenvoudige manier te kunnen registreren.

Enkele eigenschappen die interessant zijn qua gebruiksvriendelijkheid:

• ‘SmartType’: karakternamen en locaties worden onthouden en automatisch aange-

vuld waar in gelijkaardige situaties de eerste letters ervan worden getypt. Hierbij

lijkt vooral het automatisch aanvullen van karakternamen bijzonder interessant te

zijn, aangezien deze het meest frequent voorkomen.

• Wanneer een nieuwe regel wordt aangemaakt, wordt de opmaakstijl (dialoog, karak-

ter, actie) geselecteerd die het meest voorkomt na de opmaakstijl van de voorgaande

regel. Indien een andere opmaakstijl dient te worden geselecteerd, kan dit via een-

voudige toetsencombinaties.

• Een spellingscorrector zorgt ervoor dat typfouten snel kunnen worden opgespoord

en gecorrigeerd.

Movie Magic Screenwriter (zie figuur 2.4) Movie Magic Screenwriter is een recht-

streekse concurrent voor Final Draft en vertoont er vele gelijkenissen mee. Er zijn echter

ook enkele verschillen:

• Het grootste verschil qua gebruiksvriendelijkheid is dat voor elke verschillende op-

maakstijl een verschillende sneltoetsencombinatie dient te worden gebruikt. Het

door Final Draft gehanteerde systeem lijkt intuıtiever en gemakkelijker aan te leren

te zijn.

• Een tweede verschil is de voorwaartse spellingscorrectie: op het ogenblik dat een

woord wordt getypt dat niet in het woordenboek voorkomt, wordt dit woord vervan-

gen door het woord uit het woordenboek dat het dichtst in de buurt komt. Wanneer

het woord een tweede keer wordt getypt, wordt aan de eindgebruiker gevraagd om

4

dit woord aan het woordenboek toe te voegen, te negeren of aan te passen. Dit

blijkt echter (in het begin althans) niet zo heel erg handig te zijn.

Celtx (zie figuur 2.5) Celtx is een open source alternatief voor bovenvermelde pakket-

ten. Ook hier is een systeem voor automatische aanvulling van karakternamen en locaties

voorzien. Hierbij moet echter na het enter duwen om de tekst aan te vullen nog eens enter

geduwd worden om een nieuwe regel in te voegen. Er is ook een systeem voorzien om bij

het toevoegen van een nieuwe regel de juiste opmaakstijl te selecteren en gemakkelijk te

corrigeren indien nodig. De mogelijkheden waaruit kan worden gekozen om te corrigeren

zijn echter (te) beperkt. Verder beschikt Celtx nog over enkele andere interessante eigen-

schappen. Zo is het bijvoorbeeld voor verschillende scenaristen mogelijk om op eenzelfde

ogenblik samen te werken op hetzelfde document. Ook is het mogelijk gebruik te maken

van beveiligde webservices om scripts te back-uppen op een Celtx Server of om scripts

te publiceren op de Celtx Project Central. Aangezien het hele systeem open source is, is

het mogelijk ook zelf een server te configureren voor het back-uppen en publiceren van

scripts.

Conclusie Na het bekijken van verschillende scenario-editors zijn de belangrijkste ver-

wachtingen van een eindgebruiker de volgende:

• Autoaanvulling van items die veel voorkomen en waarbij de keuze beperkt is (bv.

karakternamen).

• Selectie van de opmaakstijl die met de grootste waarschijnlijkheid het door de eind-

gebruiker gewenste profiel is bij het invoegen van een nieuwe regel.

• Duidelijke aanduiding welke opmaakstijl geselecteerd is.

• Duidelijke aanduiding welke sneltoetsen kunnen worden gebruikt.

• Een vorm van spellingscontrole.

Afwijking van de standaard Aangezien de regels die binnen de Vlaamse fictieproduc-

tie worden gebruikt licht verschillen van de internationaal gangbare standaarden (zoals on-

der andere beschreven in [18] en waarmee rekening wordt gehouden bij de op de markt zijn-

de scenario-editors), zouden behoorlijk wat aanpassingen aan bestaande scenario-editors

5

moeten worden doorgevoerd. De grootste verschillen waarmee rekening moet worden

gehouden, zijn:

• Aanwijzingen voor de auteurs worden inline in de dialoog geplaatst, daar waar

ze in andere standaarden tussen haakjes onder de naam van het karakter worden

geplaatst.

• Enkele scenarioschrijvers prefereren zelf directievoorstellen (zoals Open on, Pan to,

Cut to, Dissolve to of Fade out) neer te schrijven bij het begin of het einde van een

scene. Bij de Vlaamse scenarioschrijvers hoeft hier geen rekening mee te worden

gehouden.

Om de verschillen tussen de internationale en de Vlaamse standaard te verduidelijken,

wordt een scenario met de lay-out volgens de internationale standaard weergegeven in

figuur 2.1 en wordt hetzelfde scenario met de lay-out volgens de Vlaamse standaard weer-

gegeven in figuur 2.2.

Het is uiteraard gewenst dat de editor niet enkel geschikt is voor de productie van

scenario’s volgens de Vlaamse standaarden, maar dat het ook mogelijk is te werken met

variaties daarop of met andere standaarden. Hiermee zal rekening moeten gehouden

worden bij het ontwerp van de editor.

2.2 Technische vereisten

Het raamwerk waarin de editor moet worden geıntegreerd legt eveneens een reeks vereisten

op:

• Bij centrale opslag van data worden vaak webservices aangeboden om de data op te

slaan of op te vragen. Ook bij de scenario-editor zal de opslag en het opvragen van

scenario’s via webservices gebeuren.

• Data worden opgeslagen in XML-formaat1 bij het systeem dat gebruikt wordt bij

het FIPA-project, en ook bij de meeste gelijkaardige systemen. De data worden

ook zo aangeboden door de webservices. De XML-documenten (in dit geval scena-

rio’s), moeten vaak voldoen aan een vooropgestelde structuur alvorens ze worden

opgeslagen.

1eXtensible Markup Language (XML) is een standaard die het mogelijk maakt gestructureerde gege-vens in de vorm van platte tekst voor te stellen

6

Een ontredderde FEMKE komt uit de tuin van de villa gelopen tot bij haar brommer. Op het ogenblik dat zij wil starten komt een bestelwagen tegen hoge snelheid de straat ingereden. Hij stopt ter hoogte van de villa.

FEMKE(Herkent de auto)

Renzo!(Laat haar brommer voor wat hij is en loopt naar de auto, waaruit RENZO is uitgestapt)

Gelukkig, ge zijt er!

RENZOFem! Wat is dat met Sofie?

FEMKEZe is dood Renzo. Ze hebben haar in de koffer gelegd en ze gingen haar dumpen bij X of zoiets

(Afhankelijk van de locatie, aarzelend, FEMKE heeft nog nooit van de locatie gehoord)

RENZOWeet ik zijn. Da’s een plaats waar nogal veel gedeald wordt.

(Stappen beide in)

FEMKEAllez, komaan, vertrek nu!

RENZOTony, verdommesse smeerlap...!

De auto scheurt weg.

Figuur 2.1: Voorbeeld van de lay-out volgens de internationale standaard

7

EEN ONTREDDERDE FEMKE KOMT UIT DE TUIN VAN DE VILLA GELOPEN TOTBIJ HAAR BROMMER. OP HET OGENBLIK DAT ZIJ WIL STARTEN KOMT EENBESTELWAGEN TEGEN HOGE SNELHEID DE STRAAT INGEREDEN. HIJ STOPTTER HOOGTE VAN DE VILLA.

FEMKEHERKENT DE AUTO Renzo! LAAT HAAR BROMMER VOOR WAT HIJ IS EN LOOPTNAAR DE AUTO, WAARUIT RENZO IS UITGESTAPT Gelukkig, ge zijt er!


FEMKEZe is dood Renzo. Ze hebben haar in de koffer gelegd en ze gingen haar dumpen bij X of zoiets. AFHANKELIJK VAN LOCATIE, AARZELEND, FEMKE HEEFT NOGNOOIT VAN DE LOCATIE GEHOORD

RENZOWeet ik zijn. Da's een plaats waar nogal veel gedeald wordt. STAPPEN BEIDE IN



DE AUTO SCHEURT WEG.

Figuur 2.2: Voorbeeld van de lay-out volgens de Vlaamse standaard

8

• Het bestaande beheersysteem bij het FIPA-project wordt als een webinterface aan

de eindgebruiker aangeboden. Door de editor als webapplicatie te ontwikkelen kan

deze hierin worden geıntegreerd.

Het is duidelijk dat de reeds bestaande scenario-editors uit sectie 2.1 niet voldoen aan

deze vereisten. Alle bestaande scenario-editors zijn immers stand-alone applicaties, waar-

door ze niet als webinterface kunnen worden aangeboden. Ze vereisen ook een installatie

op de computer van de eindgebruiker, die vermeden kan worden door de applicatie als een

webgebaseerde editor te ontwikkelen.

Er zijn enkele webgebaseerde editors op de markt die perfect kunnen worden geıntegreerd.

Deze zijn echter niet ontworpen voor het schrijven van scenario’s, waardoor ze niet vol-

doen aan de niet-technische vereisten. Het uitbreiden van een dergelijke editor zou een

oplossing kunnen vormen voor het probleem.

De meeste editors maken echter vooral gebruik van functies die standaard worden

ondersteund door de browser (zoals bijvoorbeeld geselecteerde tekst in het vet plaatsen).

De verzameling van deze functies is echter te beperkt om er een scenario-editor mee op te

bouwen. Andere editors, die uitgebreider zijn, bieden wel functionaliteit waarvan gebruikt

kan worden gemaakt. Om de functionaliteit specifiek voor de scenario-editor toe te voegen

zou deze bestaande functionaliteit (die niet volledig zou worden gebruikt in de scenario-

editor) volledig moeten worden aangepast. Het is dan ook beter vanaf nul te beginnen en

eventueel interessante eigenschappen over te nemen.

Voorbeelden van bestaande webgebaseerde editors zijn BXE (BitfluX Editor) [1], FCK-

Editor [4], Xinha [16] (afgesplitst van htmlArea [7]) en TinyMCE [13].

2.3 Conclusie

Bestaande scenario-editors voldoen niet aan de vereisten met betrekking tot de integreer-

baarheid in een webgebaseerd raamwerk. Bestaande webgebaseerde editors zijn moeilijk

uit te breiden tot een scenario-editor. Er dient dus een nieuwe applicatie te worden

ontwikkeld, die wel binnen een webgebaseerd raamwerk past. Eigenschappen uit bestaan-

de scenario-editors kunnen worden gebruikt om de gebruiksvriendelijkheid te verhogen.

Oplossingen gebruikt bij de webgebaseerde editors kunnen worden gebruikt om browser-

gerelateerde problemen op te lossen.

9

Figuur 2.3: Final Draft

Figuur 2.4: Movie Magic Screenwriter

10

Figuur 2.5: Celtx

11

Hoofdstuk 3

Technologiekeuzes

In hoofdstuk 2 werd besloten dat voor de integratie van de editor in het productiesysteem,

de editor wordt geımplementeerd als webgebaseerde editor. De technologieen waarmee het

mogelijk is om een dergelijke editor te implementeren kunnen worden opgesplitst in twee

categorieen:

• Een eerste categorie is die waarbij de technologie niet rechtstreeks gebruik maakt

van de functionaliteit van de webbrowser, maar gebruik maakt van een plug-in in de

webbrowser. Technologieen die tot deze categorie behoren zijn Java, Adobe Flash

en Microsoft Silverlight.

• De tweede categorie is die waarbij gebruik wordt gemaakt van functies die aange-

boden worden door de webbrowser. Het gebruik van deze technologieen is enkel

mogelijk omdat deze technologieen worden ondersteund door de meeste browseront-

wikkelaars. In deze categorie worden Google Web Toolkit (GWT) en JavaScript

bekeken als mogelijke opties.

3.1 Technologieen die een plug-in vereisen

Het gebruiken van een plug-in biedt voor- en nadelen. Het grootste gemeenschappelijke

voordeel is dat de applicatiecode slechts eenmaal moet worden geschreven voor de ver-

schillende soorten browsers die op de markt zijn. Wanneer een plug-in bestaat voor een

bepaalde browser, dan zal de applicatie kunnen worden uitgevoerd binnen deze browser.

Er zijn echter ook nadelen:

12

• De plug-in moet worden geınstalleerd op de clientcomputer. Niet voor alle plug-ins

en alle webbrowsers verloopt deze installatie even gemakkelijk.

• Aangezien de applicatie binnen de plug-in draait, is het onmogelijk gebruik te ma-

ken van functionaliteit die door de browser wordt voorzien (zoals spellingscontrole,

copy/cut/paste van tekst, . . . ), tenzij deze functionaliteit door de plug-in wordt

voorzien. Het ontbreken van een spellingscontrole die kan worden gebruikt, is een

groot gebrek bij het ontwikkelen van een scenario-editor.

3.1.1 Java-applets

Een Java-applet [12] is een applicatie, geschreven in Java, die kan worden ingepast in een

HTML-pagina. Wanneer de pagina wordt ingeladen in een browser die over een Java-

plug-in beschikt, wordt de code van de applet gedownload naar de clientcomputer en

uitgevoerd door de JVM1 van de browser. Hierdoor is het mogelijk de applet te gebruiken

op elk systeem waarop een JVM staat geınstalleerd.

Het grootste voordeel bij het gebruik van applets is dat de code volledig kan worden ge-

schreven in Java, een programmeertaal van de laatste generatie. Hierdoor kunnen stukken

code op een efficiente manier worden hergebruikt. Daarenboven zijn vele standaardcom-

ponenten voorhanden (zoals menu’s, buttons en dergelijke meer) in widget toolkits zoals

Java Swing.

Het grootste nadeel is dat naast een plug-in ook een virtuele machine moet worden

geınstalleerd. Daarenboven moet, telkens als een applicatie wordt gestart wanneer de JVM

nog niet is opgestart, eerst de JVM worden opgestart, wat een aanzienlijke vertraging met

zich meebrengt.

3.1.2 Adobe Flash

Adobe Flash [15] is een set van multimediatechnologieen die wordt gebruikt om animaties

en interactiviteit aan webpagina’s toe te voegen. Recentelijk wordt van deze technologie

ook gebruik gemaakt voor het ontwikkelen van RIA’s2. Net zoals bij Java-applets wordt

1de Java Virtual Machine (JVM) [15] is een platformonafhankelijke omgeving voor het uitvoeren vanJava-programma’s.

2Een Rich Internet Application [15] (RIA) is een webapplicatie die over gelijkaardige eigenschappenen functionaliteit beschikt als een traditionele desktopapplicatie

13

gebruik gemaakt van een plug-in in de webbrowser om de applicatie weer te geven en uit te

voeren. Daar waar de plug-in voor Java-applets slechts bij 84% van de internetgebruikers is

geınstalleerd, hebben 98,8% van de internetgebruikers de Flash-plug-in reeds geınstalleerd

staan in hun webbrowser [10].

Sinds het gebruik van Actionscript 3.0 als scriptingtaal voor het ontwikkelen van Flash-

applicaties, is het mogelijk om objectgeorienteerd te programmeren. In de laatste versies

van Flash kan ook gebruik worden gemaakt van de functionaliteit van de browser om

XML-documenten te verwerken. Hieruit is Asynchronous Flash and XML ontstaan, een

alternatief voor AJAX.

Aangezien Flash niet op een open standaard is gebaseerd, is er weinig motivatie om

niet-commerciele software te ontwikkelen die het formaat ondersteunt.

3.1.3 Microsoft Silverlight

Microsoft Silverlight [11] is een plug-in die het mogelijk maakt om webapplicaties uit

te voeren en animaties, afbeeldingen, audio en video weer te geven. Een rechtstreekse

concurrent voor Adobe Flash dus.

Vanaf versie 2.0 van Microsoft Silverlight kunnen applicaties worden geschreven in

een willekeurige .NET-programmeertaal, evenals in enkele dynamische programmeertalen

als Ruby en Python. Ook de vele mogelijkheden met betrekking tot XML bieden een

voordeel ten opzichte van Adobe Flash.

Microsoft Silverlight staat nog in de kinderschoenen. Het heeft nog af te rekenen

met enkele bugs en heeft slechts een marktpenetratie van ongeveer 10% [9]. Ook zijn er

nog niet veel applicaties ontworpen op basis van deze technologie, waardoor het nog niet

volledig is gedocumenteerd en waardoor waarschijnlijk nog bugs zullen worden gevonden.

3.2 Technologieen die geen plug-in vereisen

Bij technologieen die geen gebruik maken van een plug-in, wordt gebruik gemaakt van

functionaliteit die door de webbrowser wordt aangeboden. Het grootste nadeel hierbij is

dat niet alle webbrowsers eenzelfde technologie op eenzelfde manier hebben geımplementeerd.

Daarom moet bij het schrijven van de applicatiecode rekening gehouden worden met deze

verschillen.

14

Het grootste voordeel is dat functies als cut/paste, spellingscontrole, . . . heel gemak-

kelijk in de applicatie kunnen worden gebruikt wanneer ze door de browser worden on-

dersteund.

3.2.1 Google Web Toolkit (GWT)

Google Web Toolkit [6] is een open source Java raamwerk met als doel de ontwikkeling

van AJAX-toepassingen eenvoudiger te maken. GWT is ontwikkeld door Google en werd

vrijgegeven in mei 2006. Dankzij het gebruik van GWT zijn asynchrone remote procedure

calls, geschiedenismanagement van de browser, bladwijzerbeheer, cross-browser portabi-

liteit en interactie met Google API’s gemakkelijker te realiseren. De ontwikkelingen van

toepassingen gebeurt in Java, waarna de broncode wordt gecompileerd tot verschillende

JavaScripts, onder andere om de verschillen tussen de verschillende webbrowsers op te

vangen.

Er wordt gebruik gemaakt van widgets om het hergebruik van code gemakkelijk te

maken. Deze widgets kunnen triviale HTML elementen zijn (zoals buttons, textboxes,

textareas, . . . ), maar kunnen ook meer geavanceerde vormen aannemen (zoals menubars,

panels, richtextareas, . . . ). Ook kunnen widgets samengesteld worden tot nieuwe widgets

en kunnen volledig nieuwe widgets worden ontwikkeld.

3.2.2 JavaScript

JavaScript [15] is een scriptingtaal met object-georienteerde mogelijkheden die vooral

wordt gebruikt voor webontwikkeling aan de kant van de client. Het werd oorspronkelijk

ontwikkeld door medewerkers van Netscape en heeft samen met JScript van Microsoft

geleid tot het gestandaardiseerde ECMAScript. JavaScript is een scriptingtaal en hoeft

bijgevolg niet te worden gecompileerd alvorens uit te voeren. De object-georienteerdheid

van JavaScript is niet zoals bij de meeste object-georienteerde talen: er wordt gebruik

gemaakt van functies om het gebruik van klassen te kunnen nabootsen. Er wordt gebruik

gemaakt van het DOM3 voor het weergeven en aanpassen van XML- en HTML-code.

Er bestaan talloze bibliotheken om het implementatiewerk te vereenvoudigen. Voor-

beelden hiervan zijn DOJO, Yahoo, Prototype, JQuery, . . .

3DOM staat voor Document Object Model. Meer uitleg over het DOM is terug te vinden in sectie5.1.1.

15

Bij 94% van de vandaag gebruikte webbrowsers moet geen inspanning worden geleverd

om JavaScripts in te laden [2]. Niet alle browsers interpreteren echter JavaScriptcode op

dezelfde manier. Voor iedere browser die ondersteund dient te worden moet dus een

aparte versie voorzien worden. De ontwikkeling voor een enkele browser kan zo echter

sneller verlopen en door gebruik te maken van bibliotheken kan de te herschrijven code

tot een minimum worden beperkt.

3.3 Keuze

Aangezien spellingscontrole een groot pluspunt is voor een editor, wordt ervoor gekozen

geen gebruik te maken van een technologie die gebruik maakt van een plug-in. Voor de

eindgebruiker is deze oplossing ook het meest gebruiksvriendelijk: hij/zij moet geen extra

plug-ins downloaden, installeren en up-to-date houden en de kans is groot dat zelfs aan

de instellingen van de webbrowser niets moet worden aangepast.

Een eerste idee om de editor te ontwikkelen, met GWT in het achterhoofd, is het

aanpassen van de richtextarea widget, om zo tot een nieuwe widget te komen. De richt-

extarea widget maakt echter gebruik van een textarea als achterliggend HTML-element.

Aangezien het met een textarea onmogelijk is uitgebreide (HTML-)opmaak te gebruiken,

is het onmogelijk via deze methode een oplossing te bereiken die aan de randvoorwaarden

voldoet.

Een andere mogelijke oplossing is het aanmaken van een volledig nieuwe widget. Aan-

gezien voor het editorveld weinig andere widgets in aanmerking komen om op voort te

bouwen, zouden vele stukken code in JavaScript moeten worden geschreven, verschillend

voor de verschillende browsers. De overhead door de koppeling tussen de Javacode en de

JavaScriptcode is echter aanzienlijk en de winst door het aanmaken van een widget is mi-

nimaal (de widget zal waarschijnlijk slechts in een toepassing worden gebruikt). Hierdoor

lijkt het voordeliger de editor volledig in JavaScript te ontwikkelen. Hierbij valt echter

wel het voordeel weg van het gebruik van widgets voor de wel standaardcomponenten

(menubar, buttons en dergelijke meer), maar ook hier bieden verschillende JavaScript-

bibliotheken een oplossing voor.

Er wordt dus gekozen voor Javascript. Voor iedere browser die ondersteund dient te

worden moet wel een aparte versie worden voorzien, maar door het gebruik van JavaScript

libraries kan de herbruikbaarheid van de code worden gemaximaliseerd.

16

Hoofdstuk 4

Datamodel en integratie

In hoofdstuk 3 werd de beslissing genomen om de scenario’s aan te passen met een editor,

geschreven in JavaScript. Het scenario zelf is echter op de server opgeslagen in XML-

formaat, waardoor het niet rechtstreeks aan de eindgebruiker kan worden getoond. In dit

hoofdstuk wordt besproken hoe het scenario wordt omgevormd zodat een voorstelling aan

de eindgebruiker wel mogelijk wordt.

4.1 Scenario in XML-formaat

Om de scenario’s, die door de editor moeten worden aangemaakt en aangepast, gestructu-

reerd voor te kunnen stellen, werd de XML-gebaseerde specificatie MSML1 (Movie Script

Markup Language) ontwikkeld binnen het FIPA project. In XML-bestanden die voldoen

aan deze specificatie worden de scenario’s opgeslagen in een databank binnen het centraal

beheersysteem.

Een voorbeeld van het belangrijkste deel (het dialoogscript) uit een XML-document

dat voldoet aan de MSML-specificatie is weergegeven in figuur 4.1. Het dialoogscript is

het belangrijkste deel, omdat het op zijn geheel moet worden bewerkt door de editor.

Wanneer uit dit voorbeeld de lijn

<line character="Renzo"> Fem! Wat is dat met Sofie? </line>

1De MSML-specificatie is opgenomen in bijlage A.1.

17

#\QP�ZIVWMSR!��IRGSHMRK!�98*��#" HMEPSK"

WGIRI�HIWGVMTXMSR"�)IR�SRXVIHHIVHI� GLEVEGXIV�VIJ".ERMRI �GLEVEGXIV�VIJ"�OSQX�YMX�HI�XYMR�ZER�HI�ZMPPE�KIPSTIR�XSX�FMN�LEEV�FVSQQIV��3T�LIX�SKIRFPMO�HEX�^MN�[MP�WXEVXIR�OSQX�IIR�FIWXIP[EKIR�XIKIR�LSKI�WRIPLIMH�HI�WXVEEX�MRKIVIHIR��,MN�WXSTX�XIV�LSSKXI�ZER�HI�ZMPPE�� WGIRI�HIWGVMTXMSR"

PMRI�GLEVEGXIV!�.ERMRI�" WGIRI�HIWGVMTXMSR�MRPMRI",IVOIRX�HI�EYXS �WGIRI�HIWGVMTXMSR�MRPMRI"�*VERO� WGIRI�HIWGVMTXMSR�MRPMRI"0EEX�LEEV�FVSQQIV�ZSSV�[EX�LMN�MW�IR�PSSTX�REEV�HI�EYXS��[EEVYMX� GLEVEGXIV�VIJ"*VERO �GLEVEGXIV�VIJ"�MW�YMXKIWXETX� �WGIRI�HIWGVMTXMSR�MRPMRI"�+IPYOOMK��KI�^MNX�IV�� PMRI"

PMRI�GLEVEGXIV!�*VERO�"�*IQ��;EX�MW�HEX�QIX�7SJMI#� �PMRI" PMRI�GLEVEGXIV!�.ERMRI�"�>I�MW�HSSH�*VERO��>I�LIFFIR�LEEV�MR�HI�OSJJIV�KIPIKH�

IR�^I�KMRKIR�LEEV�HYQTIR�FMN�<�SJ�^SMIXW�� WGIRI�HIWGVMTXMSR�MRPMRI"%JLEROIPMNO�ZER�PSGEXMI��EEV^IPIRH�� GLEVEGXIV�VIJ".ERMRI �GLEVEGXIV�VIJ"�LIIJX�RSK�RSSMX�ZER�HI�PSGEXMI�KILSSVH� �WGIRI�HIWGVMTXMSR�MRPMRI" �PMRI"

PMRI�GLEVEGXIV!�*VERO�"�;IIX�MO�^MNR��(E�W�IIR�TPEEXW�[EEV�RSKEP�ZIIP�KIHIEPH�[SVHX�� WGIRI�HIWGVMTXMSR�MRPMRI"WXETTIRFIMHI�MR �WGIRI�HIWGVMTXMSR�MRPMRI" �PMRI"

PMRI�GLEVEGXIV!�.ERMRI�"�%PPI^��OSQEER��ZIVXVIO�RY�� PMRI" PMRI�GLEVEGXIV!�*VERO�"�8SR]��ZIVHSQQIWWI�WQIIVPET�� PMRI" WGIRI�HIWGVMTXMSR"�(I�EYXS�WGLIYVX�[IK�� WGIRI�HIWGVMTXMSR"

�HMEPSK"

Figuur 4.1: Voorbeeld van een XML-document dat aan de MSML-specificatie voldoet

beschouwd wordt, is snel duidelijk waarom dit formaat niet geschikt is om gebruikt te

worden voor weergave/bewerking. Het is immers de bedoeling dat de karakternaam “Ren-

zo” en de dialoog “Fem! wat is dat met Sofie?” door de gebruiker als twee aparte stukken

tekst worden gezien en bewerkt. Er zal dus met een ander formaat moeten worden gewerkt

in de editor. Belangrijk bij de keuze van dit formaat is dat het kan teruggetransformeerd

worden naar het XML-formaat. Daarenboven moet dit resulterende XML-bestand vol-

doen aan de MSML-specificatie, aangezien het anders niet kan worden opgeslagen in het

centrale beheersysteem.

4.2 Weergave aan de eindgebruiker

Het XML-formaat waarin de scenario’s worden opgeslagen is niet het ideale formaat om

scenario’s weer te geven en te bewerken, waardoor moet worden gekeken naar een ander

formaat dat hiervoor beter geschikt is en een manier om de scenario’s om te vormen van

het ene formaat naar het andere en omgekeerd. Er wordt ook meteen gekeken naar een

manier om tegemoet te komen aan de vereiste om verschillende lay-outs te voorzien voor

verschillende productiehuizen.

18

4.2.1 Scenario in XHTML-formaat

Een formaat dat zeer geschikt is voor het gebruik in de editor is het XHTML-formaat.

XHTML [15] staat voor eXtensible Hypertext Markup Language en is een taal die geba-

seerd is op twee andere talen:

• Enerzijds is het gebaseerd op HTML (HyperText Markup Language), een opmaak-

taal die voornamelijk wordt gebruikt voor het opmaken van webpagina’s. Hierbij

wordt de structuur van een document opgebouwd door gebruik te maken van elemen-

ten, die naast (tekst)-inhoud ook attributen kunnen bevatten. Van deze attributen

kan gebruik worden gemaakt voor het opmaken van het element. Interessant hierbij

is dat de opmaak kan worden opgesplitst in verschillende klassen en dat de bepaling

van de opmaak van een bepaalde klasse in een apart document (een CSS-bestand, zie

sectie 4.2.3) kan worden gedefinieerd. Aangezien XHTML gebaseerd is op HTML,

wordt het standaard door alle browsers ondersteund.

• Anderzijds is XHTML gebaseerd op XML (eXtensible Markup Language). Dit is een

standaard voor opmaaktalen waarbij gestructureerde documenten als platte tekst

kunnen voorgesteld worden. Om deze structuur voor te kunnen stellen moet een

XML-bestand voldoen aan syntactische regels. XML is uitbreidbaar, waardoor er

verschillende standaarden en specificaties op worden gebaseerd. De regels zorgen

ervoor dat documenten van een bepaalde standaard of specificatie kunnen worden

omgevormd tot een document dat voldoet aan een andere standaard of specificatie.

Een voorbeeld van een dergelijke transformatie is de XSLT (zie sectie 4.2.2).

Met behulp van een XHTML-document kan dus opmaak worden gebruikt voor het

weergeven aan de eindgebruiker en kan het in de databank opgeslagen XML-bestand

worden omgevormd tot een bewerkbaar bestand en omgekeerd. Een voorbeeld van een

dergelijk XHTML document, dat van opmaak kan worden voorzien en omvormbaar is tot

het XML-document uit figuur 4.1, is weergegeven in figuur 4.2.

4.2.2 Transformatie tussen de formaten

Het is de bedoeling dat ook de transformatie tussen het XML-document op de server

en het XHTML-document in de editor en omgekeerd in de editor op de clientcomputer

19

LXQP" FSH]"

HMZ�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSR�")IR�SRXVIHHIVHI� WTER�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI�"*IQOI �WTER"�OSQX�YMX�HI�XYMR�ZER�HI�ZMPPE�KIPSTIR�XSX�FMN�LEEV�FVSQQIV��3T�LIX�SKIRFPMO�HEX�^MN�[MP�WXEVXIR�OSQX�IIR�FIWXIP[EKIR�XIKIR�LSKI�WRIPLIMH�HI�WXVEEX�MRKIVIHIR��,MN�WXSTX�XIV�LSSKXI�ZER�HI�ZMPPE� �HMZ"

HMZ�GPEWW!�WGVMTXCHMEPSKYICGLEVEGXIVREQI�"*IQOI �HMZ" HMZ�GPEWW!�PMRI�" WTER�

GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI�",IVOIRX�HI�EYXS �WTER"�6IR^S� WTER�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI�"�0EEX�LEEV�FVSQQIV�ZSSV�[EX�LMN�MW�IR�PSSTX�REEV�HI�EYXS��[EEVYMX� WTER�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI�"6IR^S �WTER"�MW�YMXKIWXETX� �WTER"�+IPYOOMK��KI�^MNX�IV� �HMZ"

HMZ�GPEWW!�WGVMTXCHMEPSKYICGLEVEGXIVREQI�"6IR^S �HMZ" HMZ�GPEWW!�PMRI�"*IQ��;EX�MW�HEX�QIX�7SJMI# �HMZ" HMZ�GPEWW!�WGVMTXCHMEPSKYICGLEVEGXIVREQI�"*IQOI �HMZ" HMZ�GPEWW!�PMRI�">I�MW�HSSH�6IR^S��>I�LIFFIR�LEEV�MR�HI�OSJJIV�KIPIKH�

IR�^I�KMRKIR�LEEV�HYQTIR�FMN�<�SJ�^SMIXW�� WTER�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI�"%JLEROIPMNO�ZER�PSGEXMI��EEV^IPIRH�� WTER�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI�"*IQOI �WTER"�LIIJX�RSK�RSSMX�ZER�HI�PSGEXMI�KILSSVH� �WTER" �HMZ"

HMZ�GPEWW!�WGVMTXCHMEPSKYICGLEVEGXIVREQI�"6IR^S �HMZ" HMZ�GPEWW!�PMRI�";IIX�MO�^MNR��(E�W�IIR�TPEEXW�[EEV�RSKEP�ZIIP�KIHIEPH�

[SVHX�� WTER�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI�"7XETTIR�FIMHI�MR� �WTER" �HMZ" HMZ�GPEWW!�WGVMTXCHMEPSKYICGLEVEGXIVREQI�"*IQOI �HMZ" HMZ�GPEWW!�PMRI�"%PPI^��OSQEER��ZIVXVIO�RY� �HMZ" HMZ�GPEWW!�WGVMTXCHMEPSKYICGLEVEGXIVREQI�"6IR^S �HMZ" HMZ�GPEWW!�PMRI�"8SR]��ZIVHSQQIWWI�WQIIVPET�� HMZ" HMZ�GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSR�"�(I�EYXS�WGLIYVX�[IK� �HMZ"

�FSH]" �LXQP"

Figuur 4.2: Voorbeeld van een gegenereerd XHTML-document

20

plaatsvinden. Op die manier moet aan de serverzijde niets worden aangepast. Er zijn

transformatietalen beschikbaar om de transformatie uit te voeren:

• STX (Streaming Transformations for XML) [15] is een transformatietaal die is ge-

richt op het snel uitvoeren van transformaties, gebruik makend van zo weinig mo-

gelijk werkgeheugen. STX werd ontwikkeld voor het transformeren van gestreamde

XML-bestanden (bestanden die niet als geheel worden ingeladen). Er is echter geen

standaardimplementatie beschikbaar in JavaScript (enkel in Java en Perl), waardoor

het niet mogelijk is de transformatie op de clientcomputer uit te voeren.

• XSLT (eXtensible Stylesheet Language Transformations) [15] is een XML-gebaseerde

transformatietaal waarmee XML-documenten naar andere documenten (eventueel

ook XML-documenten) kunnen worden getransformeerd. Bij een XSL-transformatie

is het noodzakelijk dat het XML-document waarvan wordt vertrokken volledig in

het geheugen is ingeladen, wat tot een vertraging en een vergroot geheugengebruik

leidt. Aangezien het XML-document bij de editor sowieso voor andere toepassingen

ook volledig in het geheugen aanwezig moet zijn, vormt dit echter geen probleem.

XSLT wordt standaard door veel browsers ondersteund en bovendien is het mogelijk

vanuit JavaScript gebruik te maken van deze ondersteuning.

Voor de implementatie van de editor wordt voor het gebruik van de XSL-transformatie

gekozen. De gebruikte XSL-transformatie voor het omzetten van het in de databank op-

geslagen XML-document naar het XHTML-document en die voor de omgekeerde trans-

formatie zijn respectievelijk in bijlagen A.2.1 en A.2.2 terug te vinden.

4.2.3 Opmaak met behulp van CSS

Om de opmaak van het XHTML-document gemakkelijk aanpasbaar te maken, wordt voor

een bijkomend gebruik van CSS (Cascading Style Sheets) gekozen. Met behulp van CSS

kan de opmaak van een opmaaktaal (zoals HTML) worden beschreven in een afzonderlijk

bestand, waardoor inhoud en opmaak volledig worden gescheiden. Door het gebruik van

verschillende CSS-bestanden, kunnen verschillende lay-outs worden beschreven. Door het

gebruik van het gepaste CSS-bestand kan een document dan met de gewenste lay-out

worden weergegeven. Op deze manier kunnen verschillende productiehuizen elk gebruik

maken van hun eigen lay-out.

21

Figuur 4.3 toont hoe het XHTML-document uit figuur 4.2 er uitziet na de toevoeging

van opmaak en dus hoe een scenario er voor de eindgebruiker uit zou moeten zien.

EEN ONTREDDERDE FEMKE KOMT UIT DE TUIN VAN DE VILLA GELOPEN TOTBIJ HAAR BROMMER. OP HET OGENBLIK DAT ZIJ WIL STARTEN KOMT EENBESTELWAGEN TEGEN HOGE SNELHEID DE STRAAT INGEREDEN. HIJ STOPTTER HOOGTE VAN DE VILLA.

FEMKEHERKENT DE AUTO Renzo! LAAT HAAR BROMMER VOOR WAT HIJ IS EN LOOPTNAAR DE AUTO, WAARUIT RENZO IS UITGESTAPT Gelukkig, ge zijt er!


FEMKEZe is dood Renzo. Ze hebben haar in de koffer gelegd en ze gingen haar dumpen bij X of zoiets. AFHANKELIJK VAN LOCATIE, AARZELEND, FEMKE HEEFT NOGNOOIT VAN DE LOCATIE GEHOORD





Figuur 4.3: Weergave aan de eindgebruiker

4.3 Schematisch overzicht

Een overzicht van het gebruikte uitwisselingsschema is weergegeven in figuur 4.4. Het

XML-formaat dat wordt gebruikt in het centrale beheersysteem, de XSL-transformaties

en het XHTML-formaat zijn dezelfde voor alle productiehuizen, zolang de productiehuizen

geen eisen stellen die leiden tot conflicten met de MSML-specificatie.

Hoe de communicatie tussen de server en de clientcomputer juist verloopt, is weerge-

geven in figuur 4.5. Niet alleen voor het ophalen van de webpagina waarin de editor zich

bevindt, maar ook voor het ophalen en opslaan van de scenario’s wordt gebruik gemaakt

van het HTTP-protocol aangezien de webservices in het centrale beheersysteem hiervan

22

Figuur 4.4: Uitwisselingsschema

gebruik maken. Het HTTP-protocol [15] (HyperText Transfer Protocol) is een commu-

nicatieprotocol dat wordt gebruikt voor de transfer van informatie over een netwerk.

Oorspronkelijk werd het ontwikkeld voor de transfer van webpagina’s over het internet.

Een clientcomputer kan een aanvraag doen bij een server door gebruik te maken van een

van de verschillende HTTP-request methoden. De methoden die bij de scenario-editor

worden gebruikt zijn:

• GET Via deze methode kan een bestand dat zich op een server bevindt worden

opgevraagd. Op deze manier wordt door de clientcomputer onder andere ook de

pagina opgevraagd waarin de editor zich bevindt. Bij de webservices van het centrale

beheersysteem kan op deze manier een scenario worden opgevraagd.

• POST Bij deze methode worden data verstuurd naar een pagina op een server die

deze data verder verwerkt. Bij de webservices van het centrale beheersysteem kan op

deze manier een nieuw scenario worden aangemaakt, bijvoorbeeld om een scenario

op twee uiteenlopende manieren uit te werken.

• PUT Met behulp van deze methode kan een bestand worden verstuurd naar een

server. Bij de webservices van het centrale beheersysteem kan op deze manier een

bestaand scenario worden geupdatet.

In JavaScript kan het HTTP-protocol worden gebruikt zonder dat de pagina moet

worden herladen. In hoofdstuk 5 wordt beschreven hoe dat juist in zijn werk gaat.

23

Figuur 4.5: Communicatiemodel

24

Hoofdstuk 5

Implementatie

In hoofdstuk 3 werd geconcludeerd dat voor deze specifieke toepassing JavaScript de beste

keuze is en in hoofdstuk 4 werd een datamodel opgesteld om het scenario voor te stellen. In

dit hoofdstuk worden verschillende implementatiegerichte problemen aangehaald, alsook

de bijhorende oplossingen, rekening houdend met deze technologie en dit model.

5.1 Inleiding

Alvorens met de implementatieaspecten van start te gaan, worden eerst enkele relevante

concepten onder de loep genomen.

5.1.1 Het Document Object Model (DOM)

Het DOM [15] is een platform- en taalonafhankelijk standaard objectmodel voor het

voorstellen van onder andere XHTML- en XML-documenten. De DOM-specificatie is

ingedeeld in vier verschillende niveaus (van 0 tot en met 3), waarvan vooral het eerste en

het tweede niveau van belang zijn voor het ontwikkelen van een webgebaseerde editor.

DOM niveau 0 Dit niveau omvat modellen die werden gebruikt voor de standardisa-

tieprocedure en bevat dus geen formele specificaties.

25

DOM niveau 1 Het eerste niveau bevat beschrijvingen over het navigeren binnen een

DOM-document en het aanpassen van een DOM-document. Het navigeren binnen een

DOM-document gebeurt via een boomstructuur, waarbij het HTML- of XML-document

de voorvader is van alle knopen. Van een gegeven knoop kunnen de ouderknoop (pa-

rentNode), de linkerbuur (previousSibling), de rechterbuur (nextSibling) en de kindkno-

pen (childNodes) op een eenvoudige manier worden opgevraagd. Het aanpassen van een

DOM-document houdt in dat knopen kunnen worden verwijderd, toegevoegd of gewijzigd.

DOM niveau 2 Het tweede niveau biedt ondersteuning voor XML naamruimtes, gefil-

terde views en events. Vooral de DOM-events zijn hierbij van belang voor het ontwikkelen

van de editor, aangezien hiermee interactie met de eindgebruiker kan worden bekomen.

Met behulp van een DOM-event kan bijvoorbeeld een JavaScript-functie worden aange-

roepen op het ogenblik dat de gebruiker op een knop klikt in de editor. De klik zal

in dat geval een click-event genereren dat kan worden opgevangen met behulp van een

eventlistener die, op het ogenblik dat wordt geklikt, de functie zal oproepen.

DOM niveau 3 Een derde niveau is nog in volle ontwikkeling. Volgende uitbreidingen

zijn voorzien: laden & opslaan, XPath, views & formatering, vereisten en validatie.

5.1.2 Asynchroon JavaScript en XML (AJAX)

AJAX [15] bestaat uit een combinatie van verschillende technieken (XHTML, CSS, DOM,

XML, XSLT en JavaScript), die voor de term AJAX in gebruik genomen werd reeds

bestonden, en het XMLHttpRequest-object. XMLHttpRequest is een API die kan worden

gebruikt door verschillende scripttalen (waaronder JavaScript) om via het HTTP-protocol

data (meestal in XML-formaat) te versturen naar en op te vragen van een server. De

communicatie met de server kan zowel synchroon als asynchroon gebeuren.

Met behulp van AJAX is het dus mogelijk interactieve webpagina’s te maken, doordat

gegevens op een asynchrone manier kunnen worden gecommuniceerd van en naar een

server. Door het gebruik van asynchrone communicatie wordt de uitvoering van het

JavaScript niet geblokkeerd tijdens de communicatie. Bij de editor is dit vooral bij het

opslaan van scenario’s van belang.

26

5.1.3 Eerste webbrowser

Aangezien JavaScript door verschillende webbrowsers op een verschillende manier wordt

geınterpreteerd, is de keuze voor welke webbrowser de editor eerst wordt ontwikkeld niet

onbelangrijk. Er wordt gekozen voor de Mozilla Firefox webbrowser, omwille van volgende

redenen:

• Mozilla Firefox beschikt over een ‘Error console’, waarmee gemakkelijk de regel van

een fout in het JavaScript gevonden kan worden.

• Voor de meest gebruikte besturingssytemen is er een versie van deze webbrowser

beschikbaar. Indien de applicatie werkt onder Mozilla Firefox, is ze toegankelijk

voor alle Windows-, Macintosh- en Linux-gebruikers.

• Er bestaat een Mozilla Firefox plug-in ‘Firebug’ waarmee JavaScript kan gedebugged

worden.

• De browser is het best compatibel met het W3C1 DOM [14].

• Mozilla Firefox voorziet spellingscontrole (ook Nederlandstalige spellingscontrole,

mits het installeren van een taalpakket) voor ingevulde velden. Door hier gebruik

van te maken, moet verder geen rekening meer gehouden worden met de spellings-

controle.

Mozilla Firefox is niet de meest gebruikte webbrowser: de browser heeft een markt-

aandeel van slechts 17,76%, terwijl Microsoft Internet Explorer een marktaandeel bezit

van 74,83% [2]. Toch wordt voor deze browser gekozen omdat de hulpmiddelen voor het

ontwikkelen van JavaScript bij Microsoft Internet Explorer ontoereikend zijn.

5.2 Implementatieaspecten

In deze sectie worden enkele problemen besproken die specifiek zijn aan de scenario-

editor en de vereisten die eraan zijn opgelegd. Ook de daarbijhorende oplossing, rekening

houdend met de implementatietaal Javascript en het uitwisselingsschema, komen daarbij

aan bod.

1Het World Wide Web Concortium is de grootste internationale standardisatieorganisatie voor hetwww (World Wide Web).

27

5.2.1 Opmaakstijlen

Zoals reeds opgemerkt in sectie 2.1 wijken de regels die worden gebruikt binnen de Vlaam-

se fictieproductie lichtjes af van de internationaal gangbare regels. Het gebruik van inline

aanwijzingen voor de acteurs heeft zijn gevolgen bij de implementatie: er moet met ver-

schillende soorten opmaak worden gewerkt. Daarom wordt de opmaak opgesplitst in twee

categorien: de primaire opmaak en de secundaire opmaak:

• De primaire opmaak omvat de opmaakstijlen die niet inline kunnen voorkomen.

Voor deze opmaak wordt gebruik gemaakt van het HTML-element DIV, omdat

maximaal een stuk tekst met een primaire opmaakstijl op een regel wordt geplaatst.

• De secundaire opmaak omvat de opmaakstijlen die enkel inline kunnen voorkomen.

Hier wordt gebruik gemaakt van een SPAN -element, zodat het eenvoudig in een

ander SPAN -element of in een DIV -element kan worden ingevoegd.

In het DOM bevindt de tekst zich niet rechtstreeks in deze DIV - of SPAN -elementen.

De tekst wordt in een tekstknoop ondergebracht en deze tekstknoop wordt als kindknoop

aan het betreffende DIV - of SPAN -element gehecht.

De editor kan overigens ook worden gebruikt in een situatie waar wordt gebruik ge-

maakt van de internationaal gangbare regels. Daarbij zal soms gebruik worden gemaakt

van het vet of cursief plaatsen of onderlijnen van tekst, waarvoor de secundaire opmaak

van de editor kan worden gebruikt.

5.2.2 Genericiteit

Het is de bedoeling dat de applicatie op een eenvoudige manier kan worden uitgebreid

(bijvoorbeeld voor het toevoegen van nieuwe opmaakstijlen). Daarom wordt voor de

opbouw van de editor gebruik gemaakt van een configuratiebestand. Een voorbeeld van

dergelijk configuratiebestand is terug te vinden in appendix B.

Elke opmaakstijl in het configuratiebestand heeft een aantal kindknopen:

• name (verplicht): definieert de naam van de opmaakstijl binnen het configuratie-

bestand en tevens de CSS klasse die aan deze opmaakstijl is gekoppeld.

• text (verplicht): definieert de naam van de opmaakstijl die aan de eindgebruiker

wordt weergegeven.

28

• possibility (meerdere mogelijk): specificeert welke secundaire opmaakstijlen binnen

deze opmaak mogen worden gebruikt.

• suggest (enkel primaire opmaak, verplicht): bepaalt welke primaire opmaakstijl

standaard wordt geselecteerd bij het invoegen van een nieuwe regel.

• autocomplete: wordt ingevuld wanneer autocompletion gewenst is bij een bepaal-

de opmaakstijl. Helaas is de ontkoppeling van de implementatie in JavaScript hier

niet volledig mogelijk en moeten aanpassingen worden gedaan in het JavaScript om

autoaanvulling bij andere opmaakvelden mogelijk te maken.

Naast deze knopen voor opmaak bevat het configuratiebestand nog enkele knopen die

de namen van enkele bestanden bevatten:

• editorsource: deze knoop bevat de naam naar een dummy XHTML bestand dat

wordt gebruikt om initieel in het IFRAME in te laden. Wanneer een nieuw scenario

wordt aangemaakt, wordt vanuit dit document vertrokken. De inhoud van het

standaard gebruikte dummybestand is te zien in figuur 5.1.

• csssource: deze knoop bevat de naam van het CSS-bestand dat wordt gebruikt voor

de opmaak van het scenario. Achter de naam is een parameter version toegevoegd

waardoor, bij het incrementeren van de waarde ervan, de browser het bestand op-

nieuw zal ophalen zelfs als de naam niet is gewijzigd. Dit zorgt ervoor dat de browser

geen gebruik maakt van een CSS-bestand dat in zijn cache opgeslagen zit als er een

nieuw CSS-bestand beschikbaar is.

• transformXMLtoXHTMLsource: deze knoop bevat de naam van de XSL-style-

sheet die wordt gebruikt om het opgeslagen XML-bestand te transformeren tot het

bewerkbare XHTML-bestand bij het openen.

• transformXHTMLtoXMLsource: analoog als bij de transformXMLtoXHTML-

source, maar dan voor de inverse bewerking (bij opslag).

Dat dit systeem de editor heel flexibel maakt is gemakkelijk in te zien wanneer men

bijvoorbeeld directieaanwijzingen zou willen toelaten bij het aanmaken van scenario’s.

Daartoe kan bij de knoop “primary” de volgende knoop worden toegevoegd als kindknoop:

29

LXQP" LIEH" �LIEH" FSH]"

HMZ" �HMZ" �FSH]"

�LXQP"

Figuur 5.1: Het standaard gebruikte dummybestand

<profile>

<name>director_hint</name>

<text>Directieaanwijzing</tekst>

<suggest>script_dialoguedescription</suggest>

</profile>

Hierbij zal in het CSS-bestand dat de opmaak bevat wel een klasse “director hint” moeten

worden bijgemaakt. Ook is het eenvoudig om het benadrukken van tekst (bijvoorbeeld

door die in het vet te plaatsen) mogelijk te maken. Daarvoor moet bij de knoop “seconda-

ry” de volgende knoop worden toegevoegd:

<profile>

<name>emphasize</name>

<text>Benadruk</tekst>

</profile>

Daarnaast zal bij alle opmaakstijlen waar deze benadrukking mogelijk moet worden ge-

maakt (eventueel allemaal) het volgende element moeten worden toegevoegd:

<possibility>emphasize</possibility>

Daarenboven zal ook in het gebruikte CSS-bestand een klasse “emphasize” moeten worden

aangemaakt die ervoor zorgt dat dit profiel voor de juiste opmaak zorgt.

5.2.3 IFRAME

Er bestaan verschillende manieren om binnen een HTML-pagina een gebied te voorzien

waarin tekst kan worden opgemaakt. De meest gebruikte manier is het invoegen van een

TEXTAREA-element. Binnen een dergelijke textarea is het echter onmogelijk om tekst

30

op te maken met behulp van HTML-opmaak. Hierdoor is het onmogelijk dit element te

gebruiken in een applicatie die gebouwd is op een datamodel zoals in hoofdstuk 4.

Een alternatieve oplossing bestaat erin gebruik te maken van een IFRAME. Een IFRA-

ME is een HTML-element dat kan worden gebruikt om een HTML-document weer te

geven binnen een ander HTML-document. Enkele jaren geleden werden designMode en

contentEditable geıntroduceerd bij Mozilla Firefox, Opera en Microsoft Internet Explorer.

Door een IFRAME in deze mode te plaatsen, is het voor de eindgebruikers mogelijk om

de inhoud van het erin vervatte HTML-document aan te passen. Hierdoor is het mogelijk

om IFRAME s te gebruiken als tekstveld bij webgebaseerde editors.

Het HTML-document binnen het IFRAME kan door JavaScript worden benaderd

op eenzelfde manier als het hoofddocument. Hierdoor kunnen alle elementen binnen dit

document via het DOM worden benaderd en kunnen eventlisteners aan deze elementen

worden gehecht.

5.2.4 Tekstselectie

Belangrijk bij het werken met tekst is kunnen achterhalen waar de cursor zich bevindt en

welke tekst geselecteerd is. Om vlot met selecties om te kunnen gaan, wordt de klasse2

position aangemaakt, die over volgende variabelen beschikt:

• startNode: de textnode waarin de selectie begint.

• startOffset: de offset van het begin van de startNode tot het begin van de selectie.

• endNode: de textnode waarin de selectie eindigt.

• endOffset: de offset van het begin van de endNode tot het einde van de selectie.

Er worden twee andere functies voorzien bij deze klasse:

• getPosition(): deze functie geeft een nieuw position-object terug met de waarden

van de selectie op dat ogenblik.

• setPosition(startNode, startOffset, endNode, endOffset): deze functie wordt ge-

bruikt om een nieuwe selectie te maken binnen het IFRAME, overeenkomend met

de meegegeven waarden.

2Het gaat hier in feite over een functie zonder argumenten en zonder returnwaarde, maar deze kangebruikt worden voor doeleinden waarvoor in andere talen een klasse gebruikt wordt.

31

5.2.5 Undo/redo

Een gebrek bij vele webgebaseerde editors is de te beperkte undo/redo functionaliteit:

ofwel kan enkel het aanpassen van de opmaak ongedaan worden gemaakt, ofwel kan enkel

het typen of verwijderen van tekst ongedaan worden gemaakt. De eindgebruiker verwacht

echter een volledige undo/redo functionaliteit.

Toestanden

Om deze functionaliteit te kunnen verwezenlijken, moet eerst worden beslist op welke

ogenblikken een nieuw geschiedenispunt moet worden aangemaakt. Daartoe worden toe-

standen gedefinieerd waarin de applicatie zich kan bevinden:

0. Initiele toestand, waarnaar wordt teruggekeerd telkens de cursor wordt verplaatst.

1. Er wordt tekst bijgetypt.

2. Er wordt tekst verwijderd.

3. Er wordt een nieuwe regel ingevoegd.

4. Er wordt opmaak gewijzigd.

Telkens wanneer er wordt overgegaan van een toestand naar een andere toestand, waarbij

deze tweede verschilt van de initiele toestand, wordt een nieuw geschiedenispunt aange-

maakt.

Geschiedenispunt

Een geschiedenispunt bestaat uit het XHTML-document (omgevormd tot een String) en

de positie van de cursor. Wanneer na een undo-actie de cursor wordt verplaatst en er

op een andere plaats wordt bijgetypt, verwacht de eindgebruiker dat, wanneer terug een

undo-actie uitgevoerd wordt, de cursor op de plaats terechtkomt waar hij hem laatst had

geplaatst. Het is dus niet altijd nodig om het document opnieuw op te slaan, maar het

is soms wel nodig om de cursorpositie aan te passen. Daarom wordt bij het aanmaken

van een geschiedenispunt steeds gecontroleerd of het document verschilt van het in de

geschiedenis opgeslagen document en wordt eventueel enkel de cursorpositie geupdatet.

32

Bookmarks

Bij het opslaan van de positie van de cursor kan geen gebruik worden gemaakt van de

klasse position. Bij het terugkeren naar een geschiedenispunt worden bij het terugplaatsen

van het XHTML-document immers nieuwe DIV -, SPAN - en textnodes aangemaakt. Er

kan niet meer geselecteerd worden met behulp van een position-object, aangezien die

gebruik maakt van deze nodes. Daarom wordt een nieuwe klasse bookmark 3 gecreeerd,

die volgende variabelen bevat:

• startOffset: de offset van het begin van het document tot het begin van de selectie.

• endOffset: de offset van het begin van het document tot het einde van de selectie.

• startBegin: houdt bij of de selectie al dan niet op het begin van een nieuwe node

begint.

• endBegin: houdt bij of de selectie al dan niet op het begin van een nieuwe node

eindigt.

Binnen deze klasse worden twee functies voorzien:

• getBookmark(): geeft een nieuwe bookmark terug, rekening houdend met de se-

lectie op dat ogenblik.

• setBookmark(bookmark): deze functie krijgt een bookmark mee als argument en

maakt, hiermee rekening houdend, een nieuwe selectie in het IFRAME.

5.2.6 Communicatie met de server

Bij de communicatie met de server komen verschillende zaken kijken. Aangezien het

scenario op de server en in de editor een verschillende representatievorm heeft, is niet

alleen het transport van een scenario, maar ook de omzetting van het ene formaat naar

het andere en omgekeerd van belang.

3Deze benaming is gebaseerd op de in Microsoft Internet Explorer standaard aanwezige methodesTextRange.getBookmark() en TextRange.moveToBookmark(sBookmark)

33

Opvragen van bestanden op de server

Bij het opstarten van de editor moeten verschillende bestanden (configuratiebestand (zie

sectie 5.2.2), het scenariobestand en het bestand met de cast van een bepaalde serie) bij

de server worden opgevraagd. Hiervoor wordt gebruik gemaakt van AJAX (zie sectie

5.1.2). Er wordt een nieuw XMLHttpRequest-object aangemaakt en hiermee wordt een

HTTP-GET-request gedaan naar de server.

Aangezien het gewenst is dat steeds de laatste versie van de verschillende bestanden

beschikbaar is in de browser, wordt bij deze HTTP-GET-request in de header het “If-

Modified-Since”-veld op Sat, 1 Jan 2000 00:00:00 GMT geplaatst, waardoor de bestanden

altijd van de server en niet uit de cache van de browser zullen worden gehaald.

Opslaan van bestanden op de server

De webservices die op de server worden aangeboden voor het uitwisselen van scenario’s

voorzien twee manieren om een scenario op te slaan:

• Met behulp van een HTTP-POST-request kan een nieuw scenario worden aange-

maakt, bijvoorbeeld om een scenario op twee uiteenlopende manieren uit te werken.

Deze HTTP-POST-request wordt in JavaScript gedaan door een nieuw XMLHttpRequest-

object aan te maken, waarmee een HTTP-POST-request wordt gedaan. Uit de te-

ruggekregen statusinformatie kan worden bepaald of het aanmaken van een nieuw

scenario is gelukt of niet.

• Met behulp van een HTTP-PUT-request kan een bestaand scenario worden geupdatet.

Dit verloopt volledig analoog aan het doen van een HTTP-POST-request.

XSL-transformaties

Nadat een scenariobestand is opgehaald vanop de server en voordat een scenariobestand

kan worden opgeslagen op de server, moet het bestand eerst worden getransformeerd.

Browsers bieden al langer de mogelijkheid om XSL-transformaties uit te voeren. Bij

bijna alle hedendaagse browsers is het mogelijk met behulp van het XSLTProcessor-object

gebruik te maken van deze functionaliteit in JavaScript.

Om in JavaScript een XSL-transformatie te doen moet eerst een XSLTProcessor-

object worden aangemaakt. Nadat een XSLTProcessor-object is aangemaakt, kan de

34

XSL-stylesheet in het object worden geımporteerd. Daarna kan van het XSLTProcessor-

object gebruik worden gemaakt om een bestaande XML-knoop te transformeren naar

een nieuw XML-document. Vanuit dit nieuwe XML-document kunnen stukken XML

overgenomen worden om verder te gebruiken.

5.3 Opbouw van de editor

Om de benodigde functionaliteit te kunnen aanbieden, wordt de editor opgebouwd uit de

volgende componenten:

• De koptekst: in de koptekst wordt info over het scenario weergegeven, zoals de titel,

de auteur(s), een samenvatting, de locatie(s) en de personage(s). Deze info (behalve

de titel) kan hier ook worden aangepast.

• Het menu: via het menu kunnen algemene acties zoals opslaan, ongedaan maken en

dergelijke meer worden ondernomen.

• De opmaakbar: met behulp van de opmaakbar kan de opmaak van de tekst in

het tekstvlak worden opgemaakt. Hierin bevindt zich een dropdownbox voor de

weergave van de verschillende primaire opmaakstijlen en verschillende knoppen voor

de verschillende secundaire opmaakstijlen.

• Het tekstveld: in het tekstveld kan het dialoogscript van het scenario worden getypt.

• Het infoveld: hierin worden tips en info weergegeven aan de eindgebruiker.

• Het hulp-IFRAME : dit IFRAME wordt gebruikt voor het uitvoeren van de XSL-

transformaties. Dit onderdeel is onzichtbaar voor de eindgebruiker.

5.4 Initialisatie van de applicatie

Wegens de genericiteit (zie sectie 5.2.2), moeten de meeste componenten van de applicatie

(zoals de elementen om de opmaak aan te passen) tijdens de initialisatiefase na het inlezen

van het configuratiebestand worden aangemaakt. De componenten die hardgecodeerd in

het HTML-bestand (waarin de editor wordt ingeladen) vervat zitten, zijn:

35

• Het veld voorbehouden voor de titel.

• De koptekst, met de velden die steeds voorkomen (nog niet ingevuld):

– Auteur(s)

– Samenvatting

– Locatie(s)

– Personages

• Een knop om de koptekst aan te passen.

• Plaats voorbehouden voor het menu.

• Plaats voorbehouden voor de verschillende opmaakvelden.

Voor het uitvoeren van het initialisatiescript waarin deze velden een invulling krijgen en

bijkomende elementen worden aangemaakt, ziet de editor eruit als in figuur 5.2

Auteur(s):

Samenvatting:

Locatie(s):

Personage(s):Koptekst aanpassen

Figuur 5.2: De editor voor het uitvoeren van het initalisatiescript

De invulling van deze velden en het aanmaken van andere elementen gebeurt op het

ogenblik dat de editor in de webbrowser wordt ingeladen. De initialisatie van de editor,

die dan gebeurt door de uitvoering van het initialisatiescript, houdt de volgende stappen

in:

1. Inlezen van het configuratiebestand (zie sectie 5.2.2). De locatie van het configura-

tiebestand wordt met de URL4 van de editor meegegeven als parameter met naam

configfile. Indien er geen parameter met de naam configfile wordt teruggevonden,

wordt teruggevallen op de defaultfile “config.xml”.

4Een Uniform Resource Locator (URL) is een opeenvolging van letters, cijfers en/of symbolen waarde locatie van een bestand in een netwerk mee kan worden bepaald.

36

2. Een scenario inladen; de locatie van het scenariobestand wordt met de URL van de

editor meegegeven als verplichte parameter met naam scenefile. Indien een nieuw

scenario wordt aangemaakt, moet toch een scenariobestand beschikbaar zijn, met

de titel van het scenario.

3. De karakterlijst inladen; de locatie van de karakterlijst wordt met de URL van de

editor meegegeven als verplichte parameter met naam charfile.

4. Invullen van de velden titel, auteur(s), samenvatting, locatie(s). De personages

kunnen hier nog niet worden ingevuld, aangezien deze uit de CDATA-sectie5 van

het scenariobestand moeten worden gehaald, wat pas in stap 8 gebeurt.

5. Het aanmaken van de opmaakbar in de daarvoor voorziene ruimte. Hierbij worden

de verschillende toegelaten opmaakstijlen en de relaties ertussen gehaald uit het

configuratiebestand.

6. Het aanmaken van het IFRAME dat wordt gebruikt om het scenario in te bewerken,

een informatiebalk en een (onzichtbaar) hulp-IFRAME dat gebruikt wordt door de

XSL-transformaties.

7. Wachten tot het IFRAME en het hulp-FRAME zijn aangemaakt.

8. Het IFRAME bewerkbaar maken (zie sectie 5.2.3), het CSS bestand voor de opmaak

van het scenario inladen in het IFRAME en de inhoud van de CDATA-sectie van

het scenariobestand inladen in het hulp-IFRAME.

9. De personages in de koptekst invullen.

10. De XSL-transformatie van het dialoogscript uitvoeren.

11. Het getransformeerde dialoogscript in het IFRAME inladen.

12. Een eerste geschiedenispunt aanmaken voor de Undo/Redo functionaliteit (zie sectie

5.2.5).

13. Eventlisteners aanmaken om toetsaanslagen te kunnen opvangen, tijdig de juiste

opmaakstijl te kunnen selecteren afhankelijk van de cursorpositie, . . .

5Een CDATA sectie is een sectie gebruikt voor stukken tekst die niet voldoen aan het XML-formaat,en eventueel een XML-bestand zouden kunnen beschadigen (door het gebruik van tekens als <, >, . . . ).De sectie begint steeds met <![CDATA[ en eindigt op ]] >.

37

14. Het aanmaken van het menu.

15. De timer voor de automatische opslag starten.

Hierbij worden de verzameling van stappen 8,9,10,11,12 en de verzameling van stappen

13,14,15 parallel uitgevoerd.

Nadat de initialisatie volledig is afgerond, ziet de editor eruit als in figuur 5.3. Hierin

kunnen de verschillende componenten, zoals beschreven in sectie 5.3 beschreven terugge-

vonden worden (zie figuur 5.4).

Thuis: Scene 01.2001Auteur(s):

Auteur1, auteur2

Samenvatting:

Samenvatting van de scene.

Locatie(s):

EXT. Externe locatieINT. Interne locatie

Personage(s):

Personage1, personage2Koptekst aanpassen

Bestand Bewerken Help

DialoogDialoog In-line scenebeschrijving Karakterverwijzing

Figuur 5.3: De editor na het uitvoeren van het initalisatiescript

38


Auteur1, auteur2

Samenvatting:


Locatie(s):

EXT. Externe locatieINT. Interne locatie

Personage(s):

Personage1, personage2Koptekst aanpassen

(a) de koptekst


(b) het menu


(c) de opmaakbar

(d) het tekstveld

(e) het infoveld

Figuur 5.4: De verschillende onderdelen van de editor

39

5.5 Events

Na de initialisatiefase is de verdere uitvoering van het programma volledig afhankelijk

van de handelingen van de gebruiker. Er zijn 5 elementen waar de eindgebruiker mee kan

interageren. Deze handelingen leiden tot events die opgeroepen worden bij deze elementen.

Deze events kunnen door de applicatie opgevangen worden om taken uit te voeren die de

eindgebruiker verwacht. De 5 elementen waarmee de eindgebruiker kan interageren zijn:

• Knoppen en tekstvelden in de koptekst.

• Items in het menu.

• De dropdownbox en de knoppen in de opmaakbar.

• Het tekstveld.

• Het venster waarin de applicatie weergegeven wordt.

In deze sectie worden de verschillende mogelijke handelingen van de gebruiker op deze

elementen en de functies die daarbij worden opgeroepen besproken.

5.5.1 Koptekst

Een eerste element waarmee interactie mogelijk is, is de koptekst. Alvorens de koptekst

kan worden aangepast, moet de koptekst in de keuzeweergavetoestand (zie figuur 5.6(b))

worden gebracht. De gebruiker kan de koptekst in deze toestand brengen door op “Kop-

tekst aanpassen” te klikken. Daarna kan een van de velden (auteur(s), samenvatting,

locatie(s) of personage(s)) aangepast worden door bij dit veld op “Aanpassen” te klikken.

Een overzicht van welke acties van de eindgebruiker welke functies oproepen is terug te

vinden in figuur 5.5.

Hieronder volgt een korte beschrijving van wat deze functies juist doen:

• changeHeader() Deze functie zorgt ervoor dat de koptekst kan aangepast worden.

Indien de koptekst zich in de normale weergave bevindt (zie figuur 5.6(a)), wordt

deze aangepast zodat de eindgebruiker kan kiezen welk van de velden hij wenst aan

te passen (zie figuur 5.6(b)). Indien de koptekst zich in de keuzeweergave bevindt,

zal hij terug worden omgevormd tot de normale weergave.

40

Figuur 5.5: Overzicht van de mogelijke events binnen de koptekst

• changeField(event) Met behulp van deze functie wordt, indien de koptekst zich

in de keuzeweergave (zie figuur 5.6(b)) bevindt, een veld getranformeerd tot de

bewerkbare weergave (zie figuur 5.6(c)), terwijl de knoppen om de andere velden

aan te passen worden verwijderd. Indien de koptekst zich in de weergave bevindt

waarin een veld wordt aangepast, zullen de veranderingen die zijn gedaan in dit

veld worden doorgevoerd en zal worden teruggekeerd naar de keuzeweergave van de

koptekst.

• addField(event) Met behulp van deze functie wordt een extra inputmogelijkheid

gecreeerd binnen een veld. Op deze manier kan bijvoorbeeld een tweede auteur (en

een derde, . . . ) worden toegevoegd.

• resetField(event) Deze functie kan worden gebruikt om voor een veld de originele

waarden terug te zetten.

• cancelField(event) Bij de oproep van deze functie wordt teruggegaan naar de keu-

zeweergave van de koptekst, zonder dat de gedane aanpassingen van een veld wor-

den doorgevoerd. Hiertoe worden achtereenvolgens de functies resetField(event)

en changeField(event) opgeroepen.

41


Naam van de auteur

Samenvatting:


Locatie(s):

EXT. Chique VillaINT. Auto Renzo

Personage(s):

Femke, RenzoKoptekst aanpassen

(a) normale weergave


Naam van de auteurAanpassen

Samenvatting:

Samenvatting van de scene.Aanpassen

Locatie(s):

EXT. Chique VillaINT. Auto RenzoAanpassen

Personage(s):

Femke, RenzoAanpassen

Normale weergave

(b) keuzeweergave


Verwijderen

Pas aan | Toevoegen | Reset | Cancel

Samenvatting:

Samenvatting van de scene.Locatie(s):

EXT. Chique VillaINT. Auto RenzoPersonage(s):

Femke, RenzoNormale weergave

Naam van de auteur

(c) bewerkbare weergave

Figuur 5.6: De verschillende toestanden van de koptekst

42

5.5.2 Menu

In het menu kan via ieder menu-item een functie worden opgeroepen. Figuur 5.7 geeft in

een overzicht weer welke functie via welk menu-item wordt opgeroepen.

Figuur 5.7: Overzicht van de mogelijke functie-oproepen binnen het menu

De functies die via het menu kunnen worden opgeroepen, zijn:

• save() Bij het oproepen van deze functie wordt het bewerkte scenario (met de

koptekst) opgeslagen in het centrale beheersysteem. Bij het gewoon opslaan, zoals

hier het geval is, wordt telkens boven de vorige versie opgeslagen (zie sectie 5.2.6).

• saveNew() Ook hier wordt het scenario opgeslagen in het centrale beheersysteem,

maar dan als een nieuw scenario. Deze functionaliteit komt bijvoorbeeld van pas

om twee verschillende ideeen uit te werken (zie sectie 5.2.6).

• autosaveOn() Deze functie doet zoals haar naam zegt: de automatische opslag

wordt geactiveerd, waardoor om de minuut automatisch de save() functie wordt

aangeroepen.

• autosaveOff() Deze functie doet het omgekeerde van de vorige: de automatische

opslag wordt uitgeschakeld.

• undo() In deze functie wordt teruggekeerd naar het laatste geschiedenispunt (zie

sectie 5.2.5).

43

• redo() In deze functie wordt naar een geschiedenispunt gegaan dat werd aange-

maakt bij een eerdere undo()-functieoproep, als sinds deze undo()-functieoproep

geen aanpassingen aan het document zijn gebeurd (bijtypen, verwijderen of opmaak

van tekst).

• about() Deze functie zorgt ervoor dat een nieuw venster wordt aangemaakt waarin

informatie over de editor wordt getoond.

5.5.3 Opmaakbar

In figuur 5.8 wordt een overzicht gegeven welke functies een rol spelen bij de opmaak van

tekst uit het IFRAME met behulp van de opmaakbar.

In de opmaakbar kan de opmaak van de tekst in het IFRAME worden aangepast op

twee manieren. Door een opmaakstijl uit de dropdownbox te selecteren, wordt de opmaak

van het volledige blok tekst waarin de cursor zich bevindt aangepast. Door een van de

stijlknoppen in te drukken (dit is enkel mogelijk indien de opmaak van een geselecteerd

stuk tekst dit toelaat), wordt de opmaak van de geselecteerde tekst in het IFRAME

gewijzigd.

Figuur 5.8: Overzicht van de mogelijke functie-oproepen bij het gebruik van de opmaakbar

De functies die hierbij worden gebruikt:

• changeStyle(event) Deze functie past de opmaak aan van het volledige blok tekst

waarin de cursor (of een selectie) zich bevindt. Voor deze tekstopmaak wordt doorge-

voerd, wordt de functie makeHistoryPoint(true) aangeroepen om een geschiede-

44

nispunt (zie sectie 5.2.5) aan te maken. Ook na de tekstopmaak worden nog verschil-

lende functies opgeroepen. cleanstyle(DIV-node waarin de cursor zich bevindt)

wordt aangeroepen om inline opmaak die bij de vorige opmaakstijl van de DIV-node

wel was toegestaan, maar nu niet meer, te verwijderen. cleanup(BODY-element)

wordt aangeroepen om van aaneenliggende stukken tekst met dezelfde opmaak een

stuk tekst te maken. Uiteindelijk wordt ook changeMarkupLabel(event) aange-

roepen om de juiste opmaakstijl in de dropdownbox weer te geven en de stijlknoppen

aan te passen.

• beingClicked(event) Deze functie is er enkel voor de opmaak en zorgt ervoor dat

het lijkt alsof de opmaakknop echt ingedrukt wordt door tijdens de klik de opmaak

van de knop aan te passen.

• changeDetailStyle(event) Met behulp van deze functie kan tekst die is geselec-

teerd in het IFRAME inline worden opgemaakt. Ook hier wordt voor het opmaken

van de tekst de functie makeHistoryPoint(true) aangeroepen. Indien de geselec-

teerde tekst reeds beschikt over de aangeklikte opmaak, zal deze worden verwijderd

met behulp van de functie changeDetailStyleInSameStyle(opmaakstijl). Na de

opmaak worden de functies cleanup(DIV-node waarin de cursor zich bevindt) en

changeMarkupLabel(event) aangeroepen.

5.5.4 Tekstveld

Bij het tekstveld worden vooral events opgevangen die worden gegenereerd door toets-

aanslagen. Een overzicht van deze events en events veroorzaakt door input vanaf de

muis is weergegeven in figuur 5.9. Bepaalde functies worden met behulp van de functie

setTimeOut(“functie()”,0 ) opgeroepen, omdat eerst een standaardactie moet worden

ondernomen door de browser (knippen, plakken, . . . ), vooraleer deze functie mag worden

opgeroepen.

De verschillende functies die worden aangeroepen door interactie met het tekstveld:

• undo() Zie sectie 5.5.2.

• redo() Zie sectie 5.5.2.

• selectAll() Aangezien de selectie door de browser niet altijd correct verloopt, wordt

de selectie van de volledige tekst door de editor afgehandeld.

45

Figuur 5.9: Overzicht van de mogelijke functie-oproepen vanuit het tekstveld

46

• save() Zie sectie 5.5.2.

• makeHistoryPoint(true) Het aanmaken van een geschiedenispunt (zie sectie 5.2.5).

Door de waarde “true” mee te geven als argument, wordt aangeduid dat indien er

niets gewijzigd is qua tekst of qua opmaak, de cursorpositie toch moet worden aan-

gepast.

• paste() Deze functie zorgt ervoor dat indien tekst met inline opmaak wordt ge-

plakt in een stuk tekst waar deze opmaak niet is toegelaten, deze opmaak wordt

verwijderd. Daartoe wordt de functie cleanstyle(DIV-node waarin geplakt wordt)

opgeroepen. Daarna worden de functies cleanup(DIV-node waarin geplakt wordt)

en changeMarkupLabel() aangeroepen.

• cut() Deze functie zorgt ervoor dat indien er tekst wordt verwijderd de cursorpositie

op een juiste locatie komt te staan. Daarenboven wordt er door het aanroepen van

de functies cleanup(DIV-node waarin geplakt wordt) en changeMarkupLabel()

voor gezorgd dat stukken tekst met dezelfde opmaak worden samengevoegd en dat

de elementen in de opmaakbar worden geupdatet.

• changeStyle(event) Zie sectie 5.5.3.

• handleReturn(event) Deze functie zorgt ervoor dat er op een correcte manier

een nieuw DIV -element wordt aangemaakt, of een bestaand DIV -element wordt

gesplitst. Voor dit gebeurt wordt een geschiedenispunt (zie sectie 5.2.5) aange-

maakt door de functieoproep makeHistoryPoint(true). Voor het splitsen van

een element wordt eerst de tekstknoop waarin de cursor zich bevindt gesplitst. De

ouderknopen daarvan worden recursief gesplitst met behulp van de functie splitMo-

re(node,grensNode). Nadat alles correct is afgehandeld, wordt de functie change-

MarkupLabel(event) aangeroepen.

• handleDelete(event) Deze functie zorgt ervoor dat op een correcte manier tekst

of een regel wordt verwijderd en indien nodig een geschiedenispunt wordt aange-

maakt (met behulp van makeHistoryPoint(true)). Bij het verwijderen van regels

wordt gebruik gemaakt van cleanstyle(DIV-node waarin samengevoegd wordt) om

te zorgen dat de opmaak klopt, aangezien de opmaak van de tweede DIV -node, die

bij de eerste DIV -node wordt gevoegd, wordt aangepast. Verder wordt ook gebruik

gemaakt van de cut()-functie.

47

• handleBackspace(event) Analoog als bij de handleDelete(event)-functie, maar

er moet rekening mee worden gehouden dat in bepaalde situaties de autocomple-

te()-functie moet worden aangeroepen.

• handleDefaultKey(event) Dit is de functie die wordt opgeroepen wanneer tekst

wordt getypt. Indien nodig wordt een geschiedenispunt aangemaakt door make-

HistoryPoint(true) aan te roepen. Ook kan het, afhankelijk van de opmaakstijl

van de DIV -node, nodig zijn de autocomplete()-functie aan te roepen.

• changeMarkupLabel(event) Deze functie zorgt ervoor dat in de opmaakbar de

dropdownbox de juiste opmaak weergeeft en dat de stijlknoppen zo zijn opgemaakt

dat ze voor iedere inline stijl aanduiden of die kan worden gebruikt, niet kan worden

gebruikt of al is gebruikt.

• doubleClicked() Aangezien de browser bij een dubbelklik de selectie niet doet

zoals gewenst, wordt de selectie bij een dubbelklik door de editor afgehandeld.

5.5.5 Venster

Bij interacties met het venster worden er slechts twee events opgevangen. Deze events

worden samen met de functies die gebruikt worden om ze af te handelen weergegeven in

figuur 5.10.

Figuur 5.10: Overzicht van de mogelijke functie-oproepen door interactie met het venster waarinde applicatie geladen is

Een overzicht van wat deze functies juist doen:

• changedBrowserDimensions() Dit is de functie die ervoor zorgt dat de hoogte

van het IFRAME dynamisch wordt aangepast aan de browserhoogte en er waar-

schuwingen worden gegeven als er wegens een te klein browservenster mogelijks

informatie niet wordt weergegeven.

48

• ConfirmExit() Deze functie wordt aangesproken wanneer de editor wordt verlaten

(de browser wordt afgesloten, de pagina wordt vernieuwd, . . . ), vraagt bevestiging

aan de gebruiker om het venster te sluiten en geeft eventueel aan dat er aanpassingen

zijn die nog niet zijn opgeslagen.

5.6 Ondersteuning voor andere browsers

De implementatie die in vorige secties werd besproken, is de implementatie voor Mozilla

Firefox. Mozilla Firefox heeft echter slechts een beperkt deel van de markt in handen en

eindgebruikers hebben liefst niet meer dan een programma op hun computer geınstalleerd

staan om voor eenzelfde zaak te gebruiken. Daarom wordt nagegaan in welke mate de

editor ook via andere webbrowsers beschikbaar kan worden gemaakt.

5.6.1 Microsoft Internet Explorer

De eerste browser waarnaar wordt gekeken om naast Mozilla Firefox te ondersteunen is

Microsoft Internet Explorer, aangezien deze browser het grootste marktaandeel in handen

heeft. In deze sectie wordt besproken hoe de grootste verschillen tussen Microsoft Internet

Explorer en Mozilla Firefox kunnen worden weggewerkt.

AJAX

Daar waar asynchrone XML-aanvragen in Mozilla Firefox en andere browsers gebruik

maken van een XMLHttpRequest object, maakt Microsoft Internet Explorer gebruik van

een ActiveXObject. Dit verschil kan eenvoudig worden opgevangen door te controleren

welke methode lukt en deze toe te passen of door gebruik te maken van een JavaScript

bibliotheek (zoals bijvoorbeeld Prototype) die deze verschillen opvangt.

DOM

Wanneer een XML-document ingelezen wordt door een JavaScript, verschilt het DOM dat

ermee wordt opgebouwd lichtjes tussen Mozilla Firefox en andere webbrowsers. Bij Mozilla

Firefox wordt immers na iedere node een textNode met de instructie om een nieuwe regel

49

te nemen (“\n”) toegevoegd. Hiermee moet bij de implementatie voor Microsoft Internet

Explorer geen rekening worden gehouden.

Waar wel rekening mee moet worden gehouden is dat nodes die worden gecreeerd

ten opzichte van een bepaald document (bijvoorbeeld het hoofd HTML-document) niet

gebruikt kunnen worden binnen een ander document (bijvoorbeeld het contentDocument

binnen het IFRAME ). Om deze problemen weg te werken moet er steeds op worden gelet

ten opzichte van welk document een nieuwe node wordt gecreeerd.

XSLT

Ook voor het doorvoeren van de XSL-transformatie wordt door Microsoft Internet Explo-

rer gebruik gemaakt van een ActiveXObject. In dit ActiveXObject wordt het te transforme-

ren document ingeladen, waarna op het object de transformatiefunctie wordt opgeroepen

met het XSL-document als parameter.

Event listeners

Bij het toevoegen van een event listener aan een element verschilt Microsoft Internet

Explorer van andere webbrowsers: er dient gebruik te worden gemaakt van de attachEvent

functie, in plaats van de door andere browsers gebruikte addEventListener functie. Dit

kan worden opgevangen door te controleren welke methode werkt en deze op te roepen of

door gebruik te maken van een JavaScript bibliotheek die met deze verschillen rekening

houdt.

Tekstselectie

Het grootste struikelblok bij het ondersteunen van Microsoft Internet Explorer is het

verschil bij tekstselectie. Microsoft Internet Explorer gebruikt immers een volledig andere

set van functies om geselecteerde tekst terug te geven en om tekst te selecteren. Er bestaat

een bibliotheek die het selecteren van tekst in Microsoft Internet Explorer mogelijk maakt

op een manier zoals beschreven door het W3C. Nagaan op een W3C manier in welke nodes

tekst is geselecteerd, blijft echter onmogelijk.

Aangezien het kunnen bepalen welke tekst is geselecteerd uiterst belangrijk is voor een

editor (onder andere om te weten welke opmaak toegepast is op de geselecteerde tekst), is

50

het voorlopig onmogelijk met behulp van kleine wijzigingen ondersteuning te bieden voor

Microsoft Internet Explorer. Wel zou een volledig andere scenario-editor gebouwd kunnen

worden, gebaseerd op het door Microsoft aangereikte model. Aangezien de Mozilla Firefox

webbrowser op het Microsoft Windows platform kan worden gebruikt en het maken van

een volledig andere scenario-editor minstens enkele maanden in beslag neemt, werd ervoor

geopteerd geen versie te ontwikkelen die Microsoft Internet Explorer ondersteunt.

Een van de redenen voor de lange ontwikkeltijd die nodig zou zijn voor het maken van

een Microsoft Internet Explorer variant is het gebrek aan ontwikkeltools voor JavaScript.

Met Microsoft Internet Explorer 8 is hier verandering in gekomen, deze versie is echter

slechts vanaf 5 maart 2008 publiekelijk beschikbaar, waardoor het onmogelijk was van

deze ontwikkeltools gebruik te maken.

5.6.2 Safari

Safari is na Microsoft Internet Explorer en Mozilla Firefox de meest gebruikte webbrowser

met een marktaandeel van 5,81% [2]. De Safari webbrowser is voor het besturingssysteem

Mac OS X ontwikkeld door Apple. Safari wordt recent ook gebruikt als webbrowser in

de iPhone en de iPod touch en in maart 2008 kwam een versie uit voor verschillende

Microsoft Windows besturingssystemen.

DOM

De verschillen tussen Safari en Mozilla Firefox qua DOM zijn gelijkaardig aan de verschil-

len tussen Microsoft Internet Explorer en Mozilla Firefox (zie sectie 5.6.1).

XSL-transformatie

Sinds november 2007 is in de Safari browser support ingebouwd voor het uitvoeren van

XSL-transformaties in JavaScript. Bij deze transformatie worden echter de elementen

voor het nemen van een nieuwe regel ook getransformeerd. Tijdens de initialisatiefase

kunnen deze tekstknopen, die enkel een karakter dat een nieuwe lijn voorstelt bevatten,

eenvoudig worden weggefilterd.

51

Events veroorzaakt door toetsen

In de Safari webbrowser veroorzaken de backspacetoets, de deletetoets en alle toetsen die

ingeduwd worden terwijl de Ctrl- of Shift-toets ingedrukt is geen keyPressed-event. Door

een eventlistener toe te voegen aan het keyDown-event kan het gebruik van de backspace-

en deletetoets worden achterhaald. Bij een keyDown-event is het echter onmogelijk te

controleren of de Ctrl-toets is ingedrukt. Daardoor kunnen in Safari de sneltoetsencom-

binaties niet worden gebruikt en kan na het knippen of het plakken van een stuk tekst

een tijdelijke semantische fout in het scenariodocument aanwezig zijn. Wanneer door

een andere actie (bijvoorbeeld het verplaatsen van de cursor) de opkuisfuncties wordt

opgeroepen, wordt deze incorrectheid verholpen.

5.6.3 Opera

Opera is de vierde grootste browser met een marktaandeel van slechts 0,69% [2]. Opera

is net als Mozilla Firefox cross-platform. Aangezien bij Opera, net als bij Mozilla Firefox,

wordt geprobeerd de standaarden zo goed mogelijk te volgen, zou het werkend krijgen

van de editor binnen de Opera browser vlot moeten kunnen verlopen.

DOM

Bij Opera is de implementatie van het DOM gelijkaardig aan die van Microsoft Internet

Explorer en Safari (zie sectie 5.6.1).

Focus op het IFRAME

Wanneer ergens buiten het IFRAME wordt geklikt, is het onmogelijk met behulp van

JavaScript de focus terug binnen het IFRAME te brengen in de Opera browser. Dit

vormt niet alleen een probleem bij het opstarten, waar de cursor liefst in het tekstveld

wordt geplaatst, maar ook bij het aanpassen van de stijl. Door het selecteren van een

opmaakstijl uit de dropdownbox of het aanklikken van een opmaakknop wordt de focus

immers buiten het tekstveld geplaatst, waarna het in de Opera browser dus onmogelijk is

de cursor terug in het tekstveld te brengen of de geselecteerde tekst terug te selecteren.

52

Waarschuwing weergeven bij het afsluiten

Het is niet mogelijk de gebruiker te waarschuwen (bijvoorbeeld over niet opgeslagen aan-

passingen) wanneer deze de editorpagina verlaat. Dit komt doordat er geen event wordt

gegenereerd bij het afsluiten van een pagina, of dit event niet wordt opgevangen.

5.6.4 Andere browsers

Andere browsers hebben een nog kleiner aantal gebruikers dan de Opera browser en wor-

den daarom ook niet individueel bekeken. Er kan worden opgemerkt dat het merendeel

van deze browsers gebruik maakt van een “lay-out engine” die ook door een van de bo-

vengenoemde browsers wordt gebruikt. Een lay-out engine is het deel van een browser

die ervoor zorgt dat de content (HTML, XML, XHTML) van een pagina correct weerge-

geven wordt gebruik makend van de informatie voor de opmaak (CSS, XSLT). Browsers

die gebruik maken van eenzelfde lay-out engine, maken meestal ook gebruik van andere

gemeenschappelijke onderdelen, zoals de JavaScript interpreter. Door in rekening te ne-

men welke lay-out engine door welke browser wordt gebruikt, kan een schatting worden

gemaakt bij welke browsers de uitvoering van de editor moeilijk tot onmogelijk is.

Om te testen of deze vergelijking wel opgaat, worden enkele Gecko-gebaseerde browsers

(Galeon, K-Meleon en SeaMonkey) getest. Gecko is de lay-out engine ontwikkeld door de

Mozilla Foundation die wordt gebruikt door Mozilla Firefox. Uit deze testen blijkt dat

de editor zonder aanpassingen ook perfect functioneert in de andere Gecko-gebaseerde

browsers.

Uit de ervaringen met Microsoft Internet Explorer, Mozilla Firefox, Safari en Opera

kan dus de volgende schatting worden gemaakt:

• Met Trident-gebaseerde browsers zal de editor niet werken wegens het gebrek aan de

door het W3C aanbevolen selectiefuncties. Browsers die op de Trident lay-out engine

gebaseerd zijn, zijn o.a. Microsoft Internet Explorer, AOL Explorer en Yahoo!

Browser.

• In Gecko-gebaseerde browsers zal de editor volledig functioneel werken. Browsers

die op de Gecko lay-out engine gebaseerd zijn, zijn o.a. Mozilla Firefox, Geleon,

K-Meleon, Netscape en SeaMonkey.

53

• In Webkit-gebaseerde browsers zal de editor behalve de sneltoetsencombinaties vol-

ledig functioneel zijn. Browsers die op de Webkit lay-out engine gebaseerd zijn, zijn

o.a. Safari en Konqueror.

• Bij Presto-gebaseerde browser zal het mogelijk zijn met behulp van de editor een

scenario te schrijven, maar dit zal verre van gebruiksvriendelijk zijn aangezien de

gebruiker regelmatig manueel de cursor in het IFRAME zal moeten plaatsen. Brow-

sers die op de Presto lay-out engine gebaseerd zijn, zijn o.a. Opera, Internet Channel

en Nintendo DS Browser.

54

Hoofdstuk 6

Resultaten en toekomstig werk

In dit besluitende hoofdstuk worden de realisaties overlopen en wordt aangehaald wat in

de toekomst nog mogelijk is.

6.1 Resultaten

Een eerste resultaat van deze scriptie is het model, gebaseerd op XHTML en XSL-

transformaties, dat kan worden gebruikt om scenario’s weer te geven aan en te laten

bewerken door de eindgebruikers en de bijhorende transformaties.

Het tweede resultaat is een webgebaseerde scenario-editor, ontwikkeld in JavaScript,

die voldoende genericiteit bevat om door verschillende productiehuizen te worden ge-

bruikt. Om van de volledige functionaliteit te kunnen gebruik maken, moet gebruik

worden gemaakt van de Mozilla Firefox webbrowser, die op de meestgebruikte bestu-

ringssystemen kan worden gebruikt, of een andere Gecko-gebaseerde browser. De editor

kan mits enkele beperkingen ook worden gebruikt binnen de Safari webbrowser.

6.2 Toekomstig werk

De webgebaseerde scenario-editor kan worden uitgebouwd tot een commerciele editor,

mits de nodige aanpassingen aan specifieke gebruikersnoden (bekomen na het uitvoeren

van tests op gebruiksvriendelijkheid) en eventuele verdere codeoptimalisaties. Deze co-

deoptimalisaties kunnen bestaan uit:

55

• Het verbeteren van de reactiesnelheid door de gebruikersinvoer minder (maar nog

steeds voldoende) te controleren.

• Het inladen van de editor versnellen door de verschillende JavaScripts samen te voe-

gen tot een enkel JavaScript en dat JavaScript te comprimeren door de witruimten

weg te laten en de functienamen te verkorten.

Ook kan er nog een editor worden ontwikkeld die kan worden gebruikt binnen Microsoft

Internet Explorer, gebruik makend van een andere documentbenadering of een andere

technologie (waarbij dan wel andere voordelen zoals de spellingscontrole en de copy/paste

functionaliteit verloren gaan).

56

Bijlage A

Model

A.1 De MSML-specificatie

57

#\QP�ZIVWMSR!��#" \WH�WGLIQE�

\QPRW�\WH!�LXXT��[[[�[��SVK��<107GLIQE��XEVKIX2EQIWTEGI!�LXXT��JMTE�MFFX�FI�HMEPSKYIWGVMTX�\QPRW�QEQP!�LXXT��JMTE�MFFX�FI�HMEPSKYIWGVMTX�IPIQIRX*SVQ(IJEYPX!�UYEPMJMIH�" \WH�IPIQIRX�REQI!�HMEPSKYIWGVMTX�"

\WH�GSQTPI\8]TI" \WH�WIUYIRGI"

\WH�IPIQIRX�VIJ!�QEQP�ITMWSHI��QE\3GGYVW!�YRFSYRHIH��" �\WH�WIUYIRGI"

�\WH�GSQTPI\8]TI" �\WH�IPIQIRX" \WH�IPIQIRX�REQI!�ITMWSHI�"


\WH�IPIQIRX�REQI!�XMXPI��X]TI!�\WH�WXVMRK��QMR3GGYVW!��QE\3GGYVW!��"

\WH�IPIQIRX�REQI!�W]RSTWMW��X]TI!�\WH�WXVMRK��QMR3GGYVW!��QE\3GGYVW!��"

\WH�IPIQIRX�VIJ!�QEQP�WGIRI��QE\3GGYVW!�YRFSYRHIH��" �\WH�WIUYIRGI" \WH�EXXVMFYXI�REQI!�RS��X]TI!�\WH�MRXIKIV��"

�\WH�GSQTPI\8]TI" �\WH�IPIQIRX" \WH�IPIQIRX�REQI!�WGIRI�"


\WH�IPIQIRX�REQI!�REQI��QMR3GGYVW!��QE\3GGYVW!��" �\WH�IPIQIRX"

\WH�IPIQIRX�VIJ!�QEQP�PSGEXMSR��QE\3GGYVW!�YRFSYRHIH��" \WH�IPIQIRX�REQI!�XMQI��QMR3GGYVW!��QE\3GGYVW!��" \WH�IPIQIRX�REQI!�W]RSTWMW��X]TI!�\WH�WXVMRK��

QMR3GGYVW!��QE\3GGYVW!��" �\WH�IPIQIRX" \WH�IPIQIRX�VIJ!�QEQP�GLEVEGXIVW��QMR3GGYVW!��

QE\3GGYVW!��" \WH�IPIQIRX�VIJ!�QEQP�HMEPSKYI��QMR3GGYVW!��"

�\WH�WIUYIRGI" \WH�EXXVMFYXI�REQI!�RS��X]TI!�\WH�MRXIKIV��"

�\WH�GSQTPI\8]TI" �\WH�IPIQIRX" \WH�IPIQIRX�REQI!�PSGEXMSR�"


\WH�IPIQIRX�REQI!�HIWGVMTXMSR��X]TI!�\WH�WXVMRK��" �\WH�WIUYIRGI" \WH�EXXVMFYXI�REQI!�X]TI�"

\WH�WMQTPI8]TI" \WH�VIWXVMGXMSR�FEWI!�\WH�WXVMRK�"

\WH�IRYQIVEXMSR�ZEPYI!�-28��" \WH�IRYQIVEXMSR�ZEPYI!�)<8��"

�\WH�VIWXVMGXMSR" �\WH�WMQTPI8]TI"

�\WH�EXXVMFYXI" �\WH�GSQTPI\8]TI"

�\WH�IPIQIRX" \WH�IPIQIRX�REQI!�XMQI�"


\WH�IPIQIRX�REQI!�HIWGVMTXMSR��X]TI!�\WH�WXVMRK��QMR3GGYVW!��QE\3GGYVW!��"

�\WH�WIUYIRGI" \WH�EXXVMFYXI�REQI!�X]TI��X]TI!�\WH�WXVMRK��"

�\WH�GSQTPI\8]TI"

58

�\WH�IPIQIRX" \WH�IPIQIRX�REQI!�HMEPSKYI�"


\WH�GLSMGI�QMR3GGYVW!��QE\3GGYVW!�YRFSYRHIH�" \WH�IPIQIRX�VIJ!�QEQP�WGIRI�HIWGVMTXMSR��" \WH�IPIQIRX�VIJ!�QEQP�PMRI��"

�\WH�GLSMGI" �\WH�WIUYIRGI"

�\WH�GSQTPI\8]TI" �\WH�IPIQIRX" \WH�IPIQIRX�REQI!�WGIRI�HIWGVMTXMSR�"

\WH�GSQTPI\8]TI�QM\IH!�XVYI�" \WH�GLSMGI�QMR3GGYVW!��QE\3GGYVW!�YRFSYRHIH�"

\WH�IPIQIRX�VIJ!�QEQP�GLEVEGXIV�VIJ��" \WH�IPIQIRX�VIJ!�QEQP�TVSHYGXMSRVIQEVO��" \WH�IPIQIRX�VIJ!�QEQP�WXSV]VIQEVO��"

�\WH�GLSMGI" �\WH�GSQTPI\8]TI"

�\WH�IPIQIRX" \WH�IPIQIRX�REQI!�PMRI�"

\WH�GSQTPI\8]TI�QM\IH!�XVYI�" \WH�WIUYIRGI"

\WH�IPIQIRX�VIJ!�QEQP�GLEVEGXIVW��QMR3GGYVW!��QE\3GGYVW!��"

\WH�GLSMGI�QMR3GGYVW!��QE\3GGYVW!�YRFSYRHIH�" \WH�IPIQIRX�VIJ!�QEQP�WGIRI�HIWGVMTXMSR�

MRPMRI��" \WH�IPIQIRX�VIJ!�QEQP�TVSHYGXMSRVIQEVO��" \WH�IPIQIRX�VIJ!�QEQP�WXSV]VIQEVO��"

�\WH�GLSMGI" �\WH�WIUYIRGI" \WH�EXXVMFYXI�REQI!�GLEVEGXIV��X]TI!�\WH�WXVMRK��"

�\WH�GSQTPI\8]TI" �\WH�IPIQIRX" \WH�IPIQIRX�REQI!�WGIRI�HIWGVMTXMSR�MRPMRI�"

\WH�GSQTPI\8]TI�QM\IH!�XVYI�" \WH�WIUYIRGI"

\WH�IPIQIRX�VIJ!�QEQP�GLEVEGXIV�VIJ��QMR3GGYVW!��QE\3GGYVW!�YRFSYRHIH��"

�\WH�WIUYIRGI" �\WH�GSQTPI\8]TI"

�\WH�IPIQIRX" \WH�IPIQIRX�REQI!�GLEVEGXIVW�"


\WH�IPIQIRX�VIJ!�QEQP�GLEVEGXIV��QMR3GGYVW!��QE\3GGYVW!�YRFSYRHIH��"

�\WH�WIUYIRGI" �\WH�GSQTPI\8]TI"

�\WH�IPIQIRX" \WH�IPIQIRX�REQI!�GLEVEGXIV�"

\WH�GSQTPI\8]TI" \WH�EXXVMFYXI�REQI!�REQI��X]TI!�\WH�WXVMRK��"

�\WH�GSQTPI\8]TI" �\WH�IPIQIRX" \WH�IPIQIRX�REQI!�GLEVEGXIV�VIJ��X]TI!�\WH�WXVMRK��" \WH�IPIQIRX�REQI!�TVSHYGXMSRVIQEVO��X]TI!�\WH�WXVMRK��" \WH�IPIQIRX�REQI!�WXSV]VIQEVO��X]TI!�\WH�WXVMRK��"

�\WH�WGLIQE"

59

A.2 De XSL-transformatie

A.2.1 XSL-transformatie (XML naar XHTML)

#\QP�ZIVWMSR!��IRGSHMRK!�98*��#" \WP�WX]PIWLIIX�ZIVWMSR!��\QPRW�\WP!�LXXT��[[[�[��SVK��<70�8VERWJSVQ�"

\WP�XIQTPEXI�QEXGL!��" LXQP"

LIEH" PMRO�X]TI!�XI\X�GWW��VIP!�WX]PIWLIIX��

LVIJ!�IHMXSVJMIPH�GWW��" �LIEH" FSH]"

\WP�ETTP]�XIQTPEXIW��" �FSH]"

�LXQP" �\WP�XIQTPEXI" \WP�XIQTPEXI�QEXGL!�WGIRI�HIWGVMTXMSR�"

HMZ" \WP�EXXVMFYXI�REQI!�GPEWW�"WGVMTXCHMEPSKYIHIWGVMTXMSR �

\WP�EXXVMFYXI" \WP�ETTP]�XIQTPEXIW��"

�HMZ" �\WP�XIQTPEXI" \WP�XIQTPEXI�QEXGL!�PMRI�"

HMZ" \WP�EXXVMFYXI�REQI!�GPEWW�"WGVMTXCHMEPSKYICGLEVEGXIVREQI �

\WP�EXXVMFYXI" \WP�ZEPYI�SJ�WIPIGX!�$GLEVEGXIV��"

�HMZ" HMZ"

\WP�EXXVMFYXI�REQI!�GPEWW�"PMRI �\WP�EXXVMFYXI" \WP�ETTP]�XIQTPEXIW��"

�HMZ" �\WP�XIQTPEXI" \WP�XIQTPEXI�QEXGL!�WGIRI�HIWGVMTXMSR�MRPMRI�"

WTER" \WP�EXXVMFYXI�REQI!�GPEWW�"WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI �

\WP�EXXVMFYXI" \WP�ETTP]�XIQTPEXIW��"

�WTER" �\WP�XIQTPEXI" \WP�XIQTPEXI�QEXGL!�GLEVEGXIV�VIJ�"

WTER" \WP�EXXVMFYXI�

REQI!�GPEWW�"WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI �\WP�EXXVMFYXI" \WP�ETTP]�XIQTPEXIW��"

�WTER" �\WP�XIQTPEXI"

�\WP�WX]PIWLIIX"

60

A.2.2 Inverse XSL-transformatie (XHTML naar XML)

#\QP�ZIVWMSR!��IRGSHMRK!�98*��#" \WP�WX]PIWLIIX�ZIVWMSR!��\QPRW�\WP!�LXXT��[[[�[��SVK��<70�8VERWJSVQ�"

\WP�XIQTPEXI�QEXGL!��" LXQP"

FSH]" \WP�ETTP]�XIQTPEXIW��"

�FSH]" �LXQP"

�\WP�XIQTPEXI" \WP�XIQTPEXI�QEXGL!�HMZ�"

\WP�GLSSWI" \WP�[LIR�XIWX!�$GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSR��"

WGIRI�HIWGVMTXMSR" \WP�ETTP]�XIQTPEXIW��"

�WGIRI�HIWGVMTXMSR" �\WP�[LIR" \WP�[LIR�XIWX!�$GPEWW!�WGVMTXCHMEPSKYICGLEVEGXIVREQI��"

PMRI" \WP�EXXVMFYXI�REQI!�GLEVEGXIV�"

\WP�ZEPYI�SJ�WIPIGX!��" �\WP�EXXVMFYXI" \WP�ETTP]�XIQTPEXIW�WIPIGX!�JSPPS[MRK�

WMFPMRK��?�A��QSHI!�PMRI��" �PMRI"

�\WP�[LIR" \WP�SXLIV[MWI��"

�\WP�GLSSWI" �\WP�XIQTPEXI" \WP�XIQTPEXI�QEXGL!�HMZ��QSHI!�PMRI�"

\WP�ETTP]�XIQTPEXIW��" �\WP�XIQTPEXI" \WP�XIQTPEXI�QEXGL!�WTER�"

\WP�GLSSWI" \WP�[LIR�XIWX!�$GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI��"

WGIRI�HIWGVMTXMSR�MRPMRI" \WP�ETTP]�XIQTPEXIW��"

�WGIRI�HIWGVMTXMSR�MRPMRI" �\WP�[LIR" \WP�[LIR�

XIWX!�$GPEWW!�WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI��" GLEVEGXIV�VIJ"

\WP�ETTP]�XIQTPEXIW��" �GLEVEGXIV�VIJ"

�\WP�[LIR" \WP�SXLIV[MWI��"

�\WP�GLSSWI" �\WP�XIQTPEXI"

�\WP�WX]PIWLIIX"

61

Bijlage B

Configuratie

#\QP�ZIVWMSR!��#" GSRJMK"

IHMXSVWSYVGI"IHMXSV�LXQP �IHMXSVWSYVGI" GWWWSYVGI"IHMXSVJMIPH�GWW#ZIVWMSR!�� GWWWSYVGI" XVERWJSVQ<10XS<,810WSYVGI"XVERWJSVQ<10XS<,810�\WP �XVERWJSVQ<10XS<,810WSYVGI" XVERWJSVQ<,810XS<10WSYVGI"XVERWJSVQ<,810XS<10�\WP �XVERWJSVQ<,810XS<10WSYVGI" TVMQEV]"

TVSJMPI" REQI"PMRI �REQI" XI\X"(MEPSSK �XI\X" TSWWMFMPMX]"WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI �TSWWMFMPMX]" WYKKIWX"WGVMTXCHMEPSKYICGLEVEGXIVREQI �WYKKIWX"

�TVSJMPI" TVSJMPI"

REQI"WGVMTXCHMEPSKYIHIWGVMTXMSR �REQI" XI\X"(MEPSSKFIWGLVMNZMRK �XI\X" TSWWMFMPMX]"WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI �

TSWWMFMPMX]" WYKKIWX"WGVMTXCHMEPSKYICGLEVEGXIVREQI �WYKKIWX"

�TVSJMPI" TVSJMPI"

REQI"WGVMTXCHMEPSKYICGLEVEGXIVREQI �REQI" XI\X"/EVEOXIV �XI\X" WYKKIWX"PMRI �WYKKIWX" EYXSGSQTPIXI"GLEVEGXIVREQIW �EYXSGSQTPIXI"

�TVSJMPI" �TVMQEV]" WIGSRHEV]"

TVSJMPI" REQI"WGVMTXCHMEPSKYIHIWGVMTXMSRCMRPMRI �REQI" XI\X"-R�PMRI�WGIRIFIWGLVMNZMRK �XI\X" TSWWMFMPMX]"WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI �

TSWWMFMPMX]" �TVSJMPI" TVSJMPI"

REQI"WGVMTXCHMEPSKYIHIWGVMTXMSRCGLEVEGXIVREQI �REQI" XI\X"/EVEOXIVZIV[MN^MRK �XI\X"

�TVSJMPI" �WIGSRHEV]"

�GSRJMK"

62

Bijlage C

Gebruikershandleiding

C.1 Opstarten

De scenario-editor wordt opgestart vanuit het centrale beheersysteem. Alvorens de editor

wordt opgestart voor het aanmaken van een nieuwe scene, moeten van deze scene eerst

de naam en een samenvatting in het beheersysteem worden ingebracht. De editor ziet er

na het openen van een bestaande scene uit als in figuur C.1(a) en na het openen van een

nieuwe scene zoals in figuur C.1(b).

C.2 Koptekst aanpassen

Het is, zeker wanneer een nieuwe scene wordt beschreven, aan te raden eerst de koptekst

aan te passen. Zo is de kans minder groot dat belangrijke zaken (zoals de locatie) worden

vergeten en kan gebruik worden gemaakt van de autoaanvulling functionaliteit van de

editor. De koptekst aanpassen kan door op “Koptekst aanpassen” onderaan de koptekst

te klikken (zie figuur C.2). De koptekst wordt aangepast, zodat het eruit komt te zien als

in figuur C.3.

Wanneer een veld moet worden aangepast, kan dit eenvoudig door op de knop “Aan-

passen” onder het betreffende item te klikken (zie figuur C.4, waar de knop om het

auteursveld aan te passen aangeduid staat). Het resultaat van deze actie is te zien in

figuur C.5(a).

63


Naam van de auteur

Samenvatting:


Locatie(s):


Personage(s):




EEN ONTREDDERDE FEMKE KOMT UIT DE TUIN VAN DE VILLA GELOPEN TOT BIJ HAARBROMMER. OP HET OGENBLIK DAT ZIJ WIL STARTEN KOMT EEN BESTELWAGEN TEGENHOGE SNELHEID DE STRAAT INGEREDEN. HIJ STOPT TER HOOGTE VAN DE VILLA.

FEMKEHERKENT DE AUTO Renzo! LAAT HAAR BROMMER VOOR WAT HIJ IS EN LOOPT NAAR DEAUTO, WAARUIT RENZO IS UITGESTAPT Gelukkig, ge zijt er!


FEMKEZe is dood Renzo. Ze hebben haar in de koffer gelegd en ze gingen haar dumpen bij X of zoiets. AFHANKELIJK VAN LOCATIE, AARZELEND, FEMKE HEEFT NOG NOOIT VAN DELOCATIE GEHOORD





(a) bestaande scene


Naam van de auteur

Samenvatting:


Locatie(s):


Personage(s):




(b) nieuwe scene

Figuur C.1: De editor na het opstarten


Naam van de auteur

Samenvatting:


Locatie(s):


Personage(s):


Figuur C.2: Knop om de koptekst aan te passen



Samenvatting:


Locatie(s):


Personage(s):


Normale weergave

Figuur C.3: De aangepaste koptekst

64



Samenvatting:


Locatie(s):


Personage(s):


Normale weergave

Figuur C.4: Knop om het auteursveld aan te passen


Verwijderen


Samenvatting:




Naam van de auteur

(a) startsituatie


Verwijderen

Verwijderen


Samenvatting:




Eerste auteur

Tweede auteur

(b) meerdere auteurs

Figuur C.5: Het auteursveld aanpassen

65

In het tekstveld kan nu de naam van de auteur worden aangepast. Door op “Toevoe-

gen” (onderaan dit tekstveld) te klikken, kan een tweede auteur (en eventueel nog meer

auteurs) worden toegevoegd (zie figuur C.5(b)). Door op de knop “Verwijderen” naast

een auteur te klikken, wordt deze auteur uit de lijst verwijderd. De “Reset”-knop kan

worden gebruikt om terug de originele waarden in te vullen (toegevoegde auteurs zullen

hierbij verwijderd worden).

Via de “Pas aan”-knop kunnen gedane veranderingen worden doorgevoerd en wordt

teruggekeerd naar een situatie zoals in figuur C.3. Via de “Cancel”-knop wordt ook naar

deze situatie teruggekeerd, maar worden de gedane veranderingen genegeerd.

Op analoge manier kunnen ook de velden samenvatting, locatie(s) en personage(s)

worden aangepast. Er kan maximaal 1 samenvatting zijn, waardoor hier geen optie is

om velden toe te voegen (zie figuur C.6). Om een locatie in te vullen moet eerst worden

geselecteerd of de locatie zich binnen (INT.) of buiten (EXT.) bevindt (zie figuur C.7).

Daarna kan een meer exacte omschrijving van de locatie in het tekstveld worden ingevuld.

Voor het invullen van personages kan enkel worden gekozen uit een lijst met personages

die in het beheersysteem zijn opgenomen (zie figuur C.8).


Eerste auteur, Tweede auteurSamenvatting:

Pas aan | Reset | Cancel

Locatie(s):




Figuur C.6: De samenvatting aanpassen

Nadat alle gewenste aanpassingen zijn doorgevoerd, kan via de “Normale weergave”-

knop (zie figuur C.9) worden teruggegaan naar een situatie gelijkaardig aan de beginsitu-

atie.

C.3 Editor

De editor bestaat uit twee delen: de opmaakbar en het tekstveld (zie figuur C.10).

66




INTINT Verwijderen

INTINT Verwijderen


Personage(s):


Tweede auteur

Auto Renzo

Figuur C.7: De locaties aanpassen





FrankFrank Verwijderen

RenzoRenzo Verwijderen


Normale weergave

Figuur C.8: De personages aanpassen


Eerste auteur, Tweede auteurAanpassen

Samenvatting:


Locatie(s):


Personage(s):


Normale weergave

Figuur C.9: Knop om terug te keren naar de normale weergave

67


EEN ONTREDDERDE FEMKE KOMT UIT DE TUIN VAN DE VILLA GELOPEN TOT BIJ HAARBROMMER. OP HET OGENBLIK DAT ZIJ WIL STARTEN KOMT EEN BESTELWAGEN TEGENHOGE SNELHEID DE STRAAT INGEREDEN. HIJ STOPT TER HOOGTE VAN DE VILLA.

FEMKEHERKENT DE AUTO Renzo! LAAT HAAR BROMMER VOOR WAT HIJ IS EN LOOPT NAAR DEAUTO, WAARUIT RENZO IS UITGESTAPT Gelukkig, ge zijt er!


FEMKEZe is dood Renzo. Ze hebben haar in de koffer gelegd en ze gingen haar dumpen bij X of zoiets. AFHANKELIJK VAN LOCATIE, AARZELEND, FEMKE HEEFT NOG NOOIT VAN DELOCATIE GEHOORD





Figuur C.10: De editor: de opmaakbar en het tekstveld

68

C.3.1 Opmaakbar

De opmaakbar bestaat op zijn beurt uit twee delen.

Dropdownbox

Met behulp van de dropdownbox (zie figuur C.11) kan de stijl worden geselecteerd waar

het blok tekst waarin de cursor op dat ogenblik staat in het tekstveld mee moet worden

opgemaakt. Deze aanpassingen kunnen ook gebeuren met behulp van de sneltoetsencom-

binaties “Ctrl+pijl-omhoog” en “Ctrl+pijl-omlaag”.

DialoogDialoog

Figuur C.11: De dropdownbox voor hoofdopmaak

Inline stijlknopen

Met behulp van de inline stijlknoppen (zie figuur C.12) kan de stijl worden geselecteerd

waar een stuk tekst, dat op dat ogenblik is geselecteerd in het tekstveld, mee moet worden

opgemaakt. Deze knopen kunnen 3 verschillende vormen aannemen:

• Aanklikbaar (zie figuur C.13(a)): het is mogelijk de tekst die in het tekstveld gese-

lecteerd is met deze stijl op te maken.

• Niet aanklikbaar (zie figuur C.13(b)): het is niet mogelijk de tekst die in het tekst-

veld geselecteerd is met deze stijl op te maken.

• Reeds aangeklikt (zie figuur C.13(c)): de tekst die in het tekstveld geselecteerd is is

reeds met deze stijl opgemaakt.

In-line scenebeschrijving Karakterverwijzing

Figuur C.12: De knopen voor bijkomende opmaak

69

In-line scenebeschrijving

(a) Aanklikbaar


(b) Niet aanklikbaar


(c) Reeds aangeklikt

Figuur C.13: De verschillende vormen waarin een stijlknop kan voorkomen

C.3.2 Tekstveld

In het tekstveld kan de scene worden uitgetypt. Voor het invullen van personagenamen

kan gebruik worden gemaakt van de autoaanvulling: wanneer in een stuk tekst die als

“Karakter” is opgemaakt via de Dropdownbox de eerste letters van een naam worden

getypt, wordt deze naam automatisch aangevuld uit de lijst die ingegeven is in de koptekst.

Om de automatisch ingevulde naam te gebruiken kan op de“Enter”-toets worden geduwd.

Om een naam in te vullen die niet in de lijst voorkomt en die een deel is van een langere

naam die wel in de lijst voorkomt, kan de “Delete”-toets worden gebruikt.

C.4 Menu

Tussen de koptekst en de editor bevindt zich het menu (zie figuur C.14), dat als volgt is

opgebouwd:

• Bestand

– Opslaan

∗ Opslaan

∗ Opslaan als

– Automatisch opslaan

∗ Aan

∗ Uit

• Bewerken

– Ongedaan maken

– Opnieuw uitvoeren

• Help

70

– About


Figuur C.14: Het menu

In deze sectie worden deze menu-items in de hierboven opgelijste volgorde doorgeno-

men.

C.4.1 Bestand

Opslaan

Via dit menu-item kan de scene worden opgeslagen. Hiermee wordt ook de bijhorende

koptekst opgeslagen. Wanneer gewoon gekozen wordt voor opslaan, wordt telkens opge-

slagen naar hetzelfde bestand. Wanneer opgeslagen moet worden naar een ander bestand

(bijvoorbeeld om een compleet ander idee uit te werken), kan worden gekozen voor opslaan

als. Om gewoon op te slaan, kan ook de toetsencombinatie “Ctrl+S” worden gebruikt.

Automatisch opslaan

Via dit menu-item kan de automatische opslag van de scene worden aan- of uitgeschakeld.

Als de automatische opslag is aangeschakeld, worden de scene en de bijhorende koptekst

om de minuut opgeslagen indien ze zijn aangepast.

C.4.2 Bewerken

Via dit item kan het typen van tekst, het verwijderen van tekst en opmaak van tekst

ongedaan worden gemaakt of opnieuw worden gedaan indien het eerder ongedaan werd

gemaakt. Voor het ongedaan maken kan ook de toetsencombinatie “Ctr+Z” worden

gebruikt, voor het opnieuw uitvoeren kan de toetsencombinatie “Ctr+Y” worden gebruikt.

C.4.3 Help

Via het “About”-item kan meer informatie over de editor bekomen worden.

71

Bijlage D

Cd-rom

Op bijgevoegde cd-rom bevindt zich de JavaScriptcode van de editor met informatie over

het gebruik ervan. De exacte inhoud van de cd-rom is weergegeven in het readme-bestand

dat zich in de hoofdmap van de cd-rom bevindt.

72

Bibliografie

[1] BitfluX Editor. http://bitfluxeditor.org/.

[2] Browser Market Share. http://marketshare.hitslink.com/report.aspx?qprid=

0.

[3] DOM Menu. http://www.mojavelinux.com/projects/dommenu/.

[4] FCKEditor. http://www.fckeditor.net/.

[5] FIPA project. http://www.ibbt.be/nl/project/fipa-0.

[6] Google Web Toolkit. http://code.google.com/webtoolkit/.

[7] htmlArea. http://www.htmlarea.com/.

[8] IBBT. http://www.ibbt.be/nl/.

[9] Microsoft’s Silverlight Gaining Ground - and DRM. http://www.zoom-in.com/

microsofts_silverlight_gaining_ground_and_drm.

[10] Plugins penetration. http://www.adobe.com/products/player_census/

flashplayer/.

[11] Silverlight portal. http://silverlight.net/.

[12] Sun Java applets. http://java.sun.com/applets/.

[13] TinyMCE. http://tinymce.moxiecode.com/.

[14] W3C DOM Compatibility Tables. http://www.quirksmode.org/dom/

compatibility.html.

[15] Wikipeda, the free encyclopedia. http://en.wikipedia.org/.

73

http://bitfluxeditor.org/

http://marketshare.hitslink.com/report.aspx?qprid=0

http://marketshare.hitslink.com/report.aspx?qprid=0

http://www.mojavelinux.com/projects/dommenu/

http://www.fckeditor.net/

http://www.ibbt.be/nl/project/fipa-0

http://code.google.com/webtoolkit/

http://www.htmlarea.com/

http://www.ibbt.be/nl/

http://www.zoom-in.com/microsofts_silverlight_gaining_ground_and_drm

http://www.zoom-in.com/microsofts_silverlight_gaining_ground_and_drm

http://www.adobe.com/products/player_census/flashplayer/

http://www.adobe.com/products/player_census/flashplayer/

http://silverlight.net/

http://java.sun.com/applets/

http://tinymce.moxiecode.com/

http://www.quirksmode.org/dom/compatibility.html

http://www.quirksmode.org/dom/compatibility.html

http://en.wikipedia.org/

[16] Xinha. http://xinha.webfactional.com/.

[17] Eric Oosthoek en Ab Revoort. Basisboek televisie maken: handboek voor het regis-

seren en produceren van videoprogramma’s. Wolters-Noordhoff, Houten, Groningen,

NL, 2003.

[18] Syd Field. Screenplay: the foundations of screenwriting. New York, NY, USA, 2005.

[19] Robert Hanson and Adam Tacy. GWT in Action: Easy Ajax with the Google Web

Toolkit. Manning Publications Co., Greenwich, CT, USA, 2007.

74

http://xinha.webfactional.com/

Lijst van figuren

2.1 Voorbeeld van de lay-out volgens de internationale standaard . . . . . . . . 7

2.2 Voorbeeld van de lay-out volgens de Vlaamse standaard . . . . . . . . . . . 8

2.3 Final Draft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Movie Magic Screenwriter . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Celtx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1 Voorbeeld van een XML-document dat aan de MSML-specificatie voldoet . 18

4.2 Voorbeeld van een gegenereerd XHTML-document . . . . . . . . . . . . . . 20

4.3 Weergave aan de eindgebruiker . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4 Uitwisselingsschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.5 Communicatiemodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Het standaard gebruikte dummybestand . . . . . . . . . . . . . . . . . . . 30

5.2 De editor voor het uitvoeren van het initalisatiescript . . . . . . . . . . . . 36

5.3 De editor na het uitvoeren van het initalisatiescript . . . . . . . . . . . . . 38

5.4 De verschillende onderdelen van de editor . . . . . . . . . . . . . . . . . . . 39

5.5 Overzicht van de mogelijke events binnen de koptekst . . . . . . . . . . . . 41

5.6 De verschillende toestanden van de koptekst . . . . . . . . . . . . . . . . . 42

5.7 Overzicht van de mogelijke functie-oproepen binnen het menu . . . . . . . 43

5.8 Overzicht van de mogelijke functie-oproepen bij het gebruik van de op-

maakbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.9 Overzicht van de mogelijke functie-oproepen vanuit het tekstveld . . . . . . 46

75

5.10 Overzicht van de mogelijke functie-oproepen door interactie met het venster

waarin de applicatie geladen is . . . . . . . . . . . . . . . . . . . . . . . . . 48

C.1 De editor na het opstarten . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

C.2 Knop om de koptekst aan te passen . . . . . . . . . . . . . . . . . . . . . . 64

C.3 De aangepaste koptekst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

C.4 Knop om het auteursveld aan te passen . . . . . . . . . . . . . . . . . . . . 65

C.5 Het auteursveld aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

C.6 De samenvatting aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . 66

C.7 De locaties aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

C.8 De personages aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

C.9 Knop om terug te keren naar de normale weergave . . . . . . . . . . . . . . 67

C.10 De editor: de opmaakbar en het tekstveld . . . . . . . . . . . . . . . . . . 68

C.11 De dropdownbox voor hoofdopmaak . . . . . . . . . . . . . . . . . . . . . . 69

C.12 De knopen voor bijkomende opmaak . . . . . . . . . . . . . . . . . . . . . 69

C.13 De verschillende vormen waarin een stijlknop kan voorkomen . . . . . . . . 70

C.14 Het menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

76

Een MSML-gebaseerde scenario-editor voor ...lib.ugent.be/fulltxt/RUG01/001/312/493/RUG01...Een...

Documents

Transcript of Een MSML-gebaseerde scenario-editor voor ...lib.ugent.be/fulltxt/RUG01/001/312/493/RUG01...Een...