Dynamische website voor het beheren van experimentele...

Dynamische website voor het beheren van experimentele

multicameravideo

ing. Arvid Bouters, Joris D’hont

Promotor: prof. dr. ir. Wilfried Philips

Begeleiders: Dirk van Haerenborgh, dr. ir. Peter Van Hese, Sebastian Grünwedel

Masterproef ingediend tot het behalen van de academische graad van

Master in de toegepaste informatica

Vakgroep Telecommunicatie en Informatieverwerking

Voorzitter: prof. dr. ir. Herwig Bruneel

Faculteit Ingenieurswetenschappen en Architectuur

Academiejaar 2010-2011

I

De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van

de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen

van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te

vermelden bij het aanhalen van resultaten uit deze masterproef.

The authors give permission to make this master dissertation available for consultation and to copy

parts of this master dissertation for personal use. In the case of any other use, the limitations of the

copyright have to be respected, in particular with regard to the obligation to state expressly the

source when quoting results from this master dissertation.

6 juni 2011,

Arvid Bouters & Joris D’hont

II

Voorwoord

Deze masterproef wordt voorgedragen voor het behalen van het diploma Master in de Toegepaste

Informatica. Er wordt een website ontwikkeld die het beheer van experimentele multicameravideo

eenvoudiger maakt en de gebruikers zoekfunctionaliteiten aanbiedt. Het tot stand komen van deze

masterproef vereiste het gebruik van alle kennis die we dit jaar vergaard hebben en vergde veel

inspanningen om tot een goed einde gebracht te worden. Deze masterproef kon niet tot stand

komen zonder de hulp van enkele personen die we in dit voorwoord wensen te bedanken.

Vooreerst wensen we prof. dr. ir. Wilfried Philips bedanken voor het ter beschikking stellen van dit

onderwerp. We willen ook Sebastian Grünwedel, Dirk Van Haerenborgh en dr. ir. Peter Van Hese

bedanken voor de intensieve begeleiding en de vele uren die ze vrijgemaakt hebben om ons met

raad en daad bij te staan.

Tot slot wensen we onze ouders te bedanken voor de mogelijkheid om dit extra jaar te kunnen

studeren.

Arvid Bouters & Joris D’hont

III

Samenvatting

Onderzoekers binnen de groep Image Processing and Interpretation verwerken ruwe video-opnames

tot nieuwe bewerkte video’s. De video’s en bijhorende parameters worden tot op heden manueel

gedocumenteerd in XML-bestanden en kan geraadpleegd worden aan de hand van een eenvoudige

PHP-gegenereerde website. De onderzoekers hebben nood aan een website met meer

mogelijkheden. Deze masterproef heeft als opdracht een dynamische website te creëren om het

beheer van deze multicameravideo’s mogelijk te maken. Automatische detectie van nieuwe

toevoegingen en zoekfunctionaliteiten worden in deze masterproef ontwikkeld. Bovendien biedt de

ontwikkelde website een overzicht van de relatie tussen video’s aan de hand van flowcharts. Deze

masterproef kan nog verder uitgebreid worden door onder meer het toevoegen van meerdere

video’s tegelijk mogelijk te maken.

Trefwoorden: CakePHP, multicameravideo, website, detectie

IV

Inhoudsopgave Voorwoord ................................................................................................................................... II

Samenvatting .............................................................................................................................. III

Figurenlijst ................................................................................................................................. VII

Tabel van afkortingen ................................................................................................................ VIII

1. Inleiding ................................................................................................................................... 1

1.1. Concept ........................................................................................................................................ 1

1.2. Probleemstelling ........................................................................................................................... 1

1.3. Werkwijze ..................................................................................................................................... 2

2. Werkomgeving ......................................................................................................................... 4

2.1. PHP ............................................................................................................................................... 4

2.2. CakePHP ....................................................................................................................................... 4

2.2.1. Eigenschappen ....................................................................................................................... 5

2.2.2. Model-View-Controller architectuur ..................................................................................... 6

2.3. SQLite ........................................................................................................................................... 7

2.4. JavaScript / JQuery ....................................................................................................................... 8

3. Database .................................................................................................................................. 9

3.1. Abstrahering ................................................................................................................................. 9

3.2. Modellering .................................................................................................................................. 9

3.2.1. Entiteittypes .......................................................................................................................... 9

3.2.2. Relatietypes ......................................................................................................................... 12

3.3. Implementatie ............................................................................................................................ 13

3.4. Aanvullingen ............................................................................................................................... 14

3.4.1. Methoden ............................................................................................................................ 14

3.4.2. Authenticatie ....................................................................................................................... 16

4. Opbouw van de webpagina’s .................................................................................................. 18

4.1. Gebruikersprofielen ................................................................................................................... 19

4.1.1. Anonieme gebruiker ............................................................................................................ 19

4.1.2. Administrator ...................................................................................................................... 20

4.2. Algemene functionaliteiten ........................................................................................................ 20

V

4.2.1. Het ‘bake’-commando ......................................................................................................... 21

4.2.2. Standaard views .................................................................................................................. 22

4.2.3. Lay-out / CSS ........................................................................................................................ 25

4.3. Detectie van nieuwe mappen/bestanden .................................................................................. 26

4.3.1. Inleiding ............................................................................................................................... 26

4.3.2. Automatische detectie: algemeen ...................................................................................... 27

4.3.3. Toevoegen van recordings .................................................................................................. 28

4.3.4. Toevoegen van sequenties .................................................................................................. 29

4.3.5. Toevoegen van video’s ........................................................................................................ 30

4.4. Zoekfunctionaliteit ..................................................................................................................... 31

4.4.1. Inleiding ............................................................................................................................... 31

4.4.2. Zoeken naar strings ............................................................................................................. 32

4.4.3. Zoeken naar tags ................................................................................................................. 34

4.4.4. Exporteren van zoekresultaten ........................................................................................... 37

4.5. Flowcharts .................................................................................................................................. 38

4.5.1. Inleiding ............................................................................................................................... 38

4.5.2. Ingeven van flowchartdata .................................................................................................. 39

4.5.3. Visuele weergave van flowcharts ........................................................................................ 41

4.6. Methoden ................................................................................................................................... 42

4.6.1. Inleiding ............................................................................................................................... 42

4.6.2. Toevoegen van methoden ................................................................................................... 43

4.6.3. Validatie bij toevoegen flowcharts ...................................................................................... 43

4.7. Authenticatie .............................................................................................................................. 45

4.8. Moeilijkheden bij de ontwikkeling ............................................................................................. 46

5. Conclusie ................................................................................................................................ 48

6. Bijlagen .................................................................................................................................... V

6.1. Handleiding................................................................................................................................... V

6.2. Omzetting EER-diagram.............................................................................................................. VII

VI

6.3. Script SQLite .............................................................................................................................. VIII

6.4. Uitwerking ‘ISA’-relatie................................................................................................................. X

6.5. Structuur multicameradirectory .................................................................................................. XI

6.6. App Controller ............................................................................................................................ XII

6.7. Script permissies ........................................................................................................................ XIII

6.8. Proxy script ................................................................................................................................ XIV

Referenties ................................................................................................................................ XV

VII

Figurenlijst

FIGUUR 1: MVC ARCHITECTUUR [6]. .............................................................................................................................. 7

FIGUUR 2: EER-DIAGRAM VOOR DE OPBOUW VAN DE DATABASE.. ...................................................................................... 11

FIGUUR 3: VOORBEELD 'ISA'-RELATIE.. .......................................................................................................................... 15

FIGUUR 4: USE CASE DIAGRAM, OPGESTELD IN UML.. ...................................................................................................... 19

FIGUUR 5: DE CAKEPHP CONSOLE................................................................................................................................. 21

FIGUUR 6: (FICTIEF) VOORBEELD VAN EEN GRAFIEK, OPGESTELD MET TUFTEGRAPH [18]. ........................................................ 25

FIGUUR 7: (FICTIEF) VOORBEELD VOOR HET ZOEKEN OP BASIS VAN TAGS. .............................................................................. 34

FIGUUR 8: SCHEMA FLOWCHART.. ................................................................................................................................. 41

FIGUUR 9: VOORBEELD INGEVEN VAN EEN PARAMETER ...................................................................................................... 43

VIII

Tabel van afkortingen

ACID Atomair, Consistent, Isolatie, Duurzaam

ACL Access Control Lists

ACO Access Control Objects

API Application Programming Interface

ASP.NET Active Server Pages

CRUD Create, Read, Update, Delete

CSS Cascading Style Sheets

EER Enhanced Entity Relationship

HABTM HasAndBelongsToMany

HTML HyperText Markup Language

IDE Integrated Development Environment

IPI Image Processing and Interpretation

JSON JavaScript Object Notation

MIT Massachusetts Institute of Technology

MPPT Modified Preorder Tree Traversal

MVC Model-View-Controller(-architectuur)

PHP PHP: HyperText Processor

SQL Structured Query Language

UML Unified Modeling Language

XML Extensible Markup Language

Dynamische website voor het beheren van experimentele multicameravideo

Arvid Bouters, Joris D’hont 1

1. Inleiding

1.1. Concept

De onderzoeksgroep Image Processing and Interpretation (IPI) maakt bij onderzoek gebruik van

multicamera videobeelden. Deze beelden en outputvideo’s worden op een server binnen de

multicamera directory opgeslagen. Binnen deze map bevinden zich verschillende recordingmappen,

welke telkens een opname bevatten van een experiment of een gebeurtenis uit het dagelijkse leven

(bijvoorbeeld een sportwedstrijd). Deze opnames worden vervolgens opgesplitst in verschillende

sequenties binnen deze recordings. Elke sequentie bestaat uit meerdere video’s, één voor elk

camerastandpunt. Deze bronvideo’s vormen het vertrekpunt voor verdere bewerking per camera

door middel van een algoritme. In een laatste stap worden deze bewerkte video’s per camera

samengevoegd met opnieuw een algoritme om finaal tot bijvoorbeeld een occupancy map te komen

[1].

De gegevens van bovenstaande video’s werden tot nu toe manueel in Extensible Markup Language

(XML)-bestanden gedocumenteerd. Op basis van deze bestanden werd in het verleden een

eenvoudige PHP-gegenereerde website gemaakt. Deze geeft een eenvoudig overzicht van de inhoud

van de XML-bestanden, maar is verder weinig dynamisch. Zo zijn er geen zoekfunctionaliteiten

aanwezig en kunnen resultaten niet geëxporteerd worden. De huidige werkwijze heeft als gevolg dat

het documenteren veel werk vereist en men op verschillende plaatsen binnen de directorystructuur

XML-bestanden moet plaatsen. De kans op fouten bij het documenteren is hierdoor aanzienlijk.

1.2. Probleemstelling

Deze masterproef biedt een oplossing voor bovenstaande nadelen door een dynamische website te

ontwikkelen die het beheer van experimentele multicameravideo vereenvoudigt. Om bovenstaande

werkwijze te verbeteren wordt op meerdere vlakken vereisten gesteld.

1. Automatische detectie. Tot op heden werd alles manueel in XML-bestanden

gedocumenteerd. Hierdoor bestaat de kans dat een onderzoeker een bepaald onderdeel

vergeet te documenteren. Het werken met XML-bestanden houdt het gevaar in dat

onderzoekers bepaalde parameters vergeten te documenteren. XML-bestanden

ondersteunen ook geen validatie van input, waardoor de kans op fouten eveneens stijgt. In

deze masterproef vertrekken we van de bestaande structuur, met als voordeel dat

onderzoekers met een gekende structuur kunnen verder werken.

2. Zoekfunctionaliteiten. De bestaande XML-bestanden staan verspreid over de bestaande

directory en de huidige PHP-gegenereerde website heeft geen zoekfunctionaliteiten. Dit



heeft tot gevolg dat onderzoekers momenteel manueel de bestaande data moeten

doorzoeken. Om deze reden wordt gevraagd een aantal zoekfunctionaliteiten toe te voegen.

Er bestaat ook geen manier om op eenvoudige wijze data afkomstig uit meerdere XML-

bestanden samen te voegen of te downloaden.

3. Dynamisch overzicht. De huidige werkwijze heeft als nadeel dat het moeilijk is om een

overzicht te krijgen van de onderlinge relaties tussen video’s. Het is ook niet eenvoudig om in

een oogopslag te zien hoeveel video’s een bepaalde frequentie nu precies heeft.

4. Compatibiliteit met Linux, geen gebruik van SQL-server. Binnen de onderzoeksgroep maakt

men gebruik van Linux als besturingssysteem. Om de website compatibel te maken met dit

besturingssysteem wordt er gewerkt met PHP, meer specifiek het framework CakePHP.

Verder is er de vraag om geen gebruik te maken van een SQL-server, waardoor de keuze voor

SQLite als databasemanagementsysteem verantwoord kan worden.

1.3. Werkwijze

Binnen deze masterproef wordt een dynamische website ontwikkeld die toelaat experimentele

multicameravideo te beheren. Er wordt gestart met het opzetten van de database. We volgen hierbij

het handboek “Principes van databases” van prof. dr. Guy De Tré (2007) door in drie stappen te

werken: 1) informatie verzamelen, 2) een Enhanced Entity-Relationship-diagram (EER-diagram)

opstellen en 3) het databaseschema onder de vorm van een SQLite-script aanmaken.

Gedurende de verschillende samenkomsten met de begeleiders werd er informatie verzameld over

de gewenste functionaliteiten en ideeën uitgewisseld. De begeleiders gaven tijdens de ontwikkeling

op verschillende momenten feedback en suggesties om de bestaande webpagina’s te verbeteren.

Een website is geen statisch gegeven, maar een proces van herzieningen en aanpassingen om finaal

tot een bevredigend resultaat te komen. Hierdoor is een website nooit klaar en steeds vatbaar voor

verbeteringen. Desondanks hebben we getracht om zoveel mogelijk de ontvangen feedback en

suggesties te implementeren om zo aan de wensen van toekomstige gebruikers te kunnen voldoen.

Vooral op vlak van gebruiksvriendelijkheid heeft de website meerdere metamorfoses ondergaan. Het

resultaat kan online geraadpleegd worden op: http://telin.ugent.be/~dvhaeren/multicamera. In

bijlage 6.1. vindt u een korte handleiding.

Dit onderwerp werd gekozen omwille van zijn veelzijdige karakter. Om deze masterproef tot een

goed einde te kunnen brengen, moesten we onze kennis over databanken en het programmeren van

websites combineren. Dit leunt aan bij onze persoonlijke interesse, namelijk webontwikkeling. Dit

onderwerp leek ons de beste mogelijkheid om de aangeleerde kennis in de praktijk om te zetten en

tegelijkertijd onze eigen grenzen te verleggen.

http://telin.ugent.be/~dvhaeren/multicamera



Deze masterproef start met een bespreking van de werkomgeving waarbinnen deze website

ontwikkeld is. Er wordt een overzicht gegeven van de gebruikte programmeertalen en SQLite als

databasemanagementsysteem. Ten tweede wordt de gebruikte database besproken en de manier

waarop deze tot stand gekomen is. In het derde en grootste luik van deze masterproef wordt de

opbouw van de verschillende webpagina’s besproken. De gebruikte algoritmen worden logisch

uitgelegd zonder elke lijn code in detail te behandelen.



2. Werkomgeving

Dit hoofdstuk behandelt de gebruikte werkomgeving bij het tot stand komen van de website. Bij het

creëren van deze website diende rekening gehouden te worden met verschillende vereisten, welke

een motivatie vormden voor de keuze van programmeertalen, frameworks, databases,… Ten eerste

wordt onze keuze voor PHP als scripttaal verantwoord. Ten tweede wordt er gekozen voor CakePHP

als framework voor onze website. Als derde wordt de gekozen databanktechnologie uit de doeken

gedaan. Ten slotte zijn er JavaScript en JQuery om de interactiviteit van onze website aan client-side

te verwezenlijken. Lokaal werden alle webpagina’s ontwikkeld binnen XAMPP (1.7.4).

2.1. PHP

PHP staat voor ‘PHP: Hypertext Preprocessor’ en is een veel gebruikte open source scripttaal die

bedoeld is om webservers dynamische webpagina’s te laten creëren. Net als ASP.NET (Active Server

Pages) is het een server-side scripttaal, dit betekent dat de server de pagina eerst gaat bewerken of

genereren alvorens hem door te sturen naar de gebruiker. Het resultaat is een HTML-pagina die op

de gewone manier behandeld wordt door de browser. De client is er zich hierdoor niet van bewust

dat hij te maken heeft met een dynamische pagina. Het eerste voordeel hiervan is dat de scripts

verborgen blijven voor de gebruiker en dus niet kunnen gekopieerd worden [2]. Ten tweede kan er

hierdoor ook gemakkelijker een connectie plaatsvinden tussen de server en een database [3]. De taal

zelf is vergelijkbaar met andere talen zoals Perl of Python, maar lijkt qua syntaxis het meest op C [4].

Binnen deze masterproef wordt gewerkt met versie 5.3.5. van PHP. Deze versie werd op 6 januari

2011 uitgebracht [4]. Binnen de onderzoeksgroep wordt Linux als besturingssysteem gebruikt. Dit

vormt de voornaamste motivatie voor onze keuze voor PHP. ASP.NET, de scripttaal die in de lessen

Internettoepassingen onderwezen wordt, is aldus hier niet bruikbaar en PHP vormt een uitstekend

alternatief. Voor het programmeren werd geen gebruik gemaakt van een Integrated Development

Environment (IDE) zoals Netbeans, we kozen voor Notepad++.

2.2. CakePHP

CakePHP is een open source, rapid development framework voor PHP geïnspireerd door Ruby on

Rails [5]. Het framework geeft programmeurs de mogelijkheid om op een gestructureerde manier

webapplicaties te bouwen, zonder verlies van flexibiliteit. Het wordt verdeeld onder de gratis MIT

licentie, die ontstaan is op de Massachusetts Institute of Technology en als voorwaarde eist dat het

copyright statement in alle kopieën aanwezig is. CakePHP biedt ook een goede compatibiliteit met

verschillende databasen en vereenvoudigt aanzienlijk het raadplegen van de database. Vooral de

‘Bake’ console is hiervoor zeer handig. Het laat immers toe om heel snel models, views en controllers

(punt 2.2.2.) aan te maken voor een databasemodel door middel van een command-line-interface.



Dit versnelt de ontwikkeling van de website aanzienlijk. De webontwikkelaar kan zich hierdoor volop

focussen op de moeilijkere zaken terwijl de meest elementaire koppelingen met de database

automatisch gegenereerd worden. Bij het ontwikkelen van de website wordt gebruik gemaakt van de

meest recente versie, namelijk 1.3.8. CakePHP 2.0 is reeds in ontwikkeling, maar nog niet

uitgebracht.

De keuze voor CakePHP als framework kan als volgt gemotiveerd worden. Ten eerste is CakePHP een

veelgebruikt framework dat blijft groeien en wordt er actief verder gebouwd aan het framework. Ten

tweede is CakePHP uitgebreid gedocumenteerd dankzij een diepgaande tutorial en een duidelijke

Application Programming Interface (API). Ten derde heeft CakePHP ten gevolge van zijn uitgebreide

functionaliteit een grote gemeenschap van gebruikers die actief gebruik maken van verschillende

fora. Voor het merendeel aan problemen bij het ontwikkelen van de website kan op deze fora dan

ook snel een antwoord gevonden worden. De grote community was de voornaamste reden waarom

de begeleiders ons aanraadden om CakePHP als framework te nemen.

De keuze voor een framework bij het ontwikkelen van een website houdt tevens een aantal nadelen

in. Zo stuit de ontwikkelaar onvermijdelijk op de grenzen van het framework. Bij deze masterproef

kwamen de meeste problemen voor bij het ontwikkelen van een zoekfunctie op basis van tags. De

zoekfuncties van CakePHP met betrekking tot meerdere-op-meerdere relaties binnen een relationele

database is niet eenvoudig te ontwikkelen.

Onderstaande tekst geeft een overzicht van een aantal voorname functies van CakePHP. Vervolgens

wordt de Model-View-Controller (MVC) architectuur van CakePHP besproken.

2.2.1. Eigenschappen

Een eerste belangrijke eigenschap van CakePHP zijn de geïntegreerde CRUD-mogelijkheden (create,

read, update, delete) voor database interactie. Het is niet langer nodig om zelf in de code met de

database een connectie op te starten en vervolgens zelf een SQL query op te stellen. Door middel

van eenvoudig gestructureerde commando’s binnen CakePHP kan je bovenstaande acties met één

lijn code uitvoeren. Dit vereenvoudigt het ontwikkelen voor de programmeur en de code wordt

hierdoor beter leesbaar. Ter aanvulling biedt CakePHP de mogelijkheid om ingevoerde data te

valideren. Gezien de grote hoeveelheid data die door de te ontwikkelen website verwerkt moet

worden is deze eigenschap een motivatie om voor CakePHP te kiezen.

Een tweede eigenschap betreffen de ingebouwde helpers voor o.a. HyperText Markup Language

(HTML). Bij het ontwikkelen van de website werd dankbaar gebruik gemaakt van de HTML helper.

Door middel van korte commando’s kan een volledig formulier, inclusief validatie gegenereerd



worden. Ook header informatie zoals het inladen van bepaalde JavaScript- of CSS-bestanden

(Cascading Style Sheets) wordt aanzienlijk vereenvoudigd.

Een derde eigenschap van CakePHP is dat het eenvoudig te installeren is op een Apache webserver.

Aangezien de website op een Apache server zal draaien, werkt dit in ons voordeel. Als laatste

eigenschap wordt opnieuw verwezen naar de MVC-architectuur, welke hieronder besproken wordt.

2.2.2. Model-View-Controller architectuur

Zoals eerder vermeld werkt CakePHP met de MVC architectuur. Deze deelt de applicatie op in drie

domeinen:

Een model is een actieve representatie van een database tabel. Het kan een connectie

opstarten, SQL instructies uitvoeren en gegevens opslaan in de betrokken tabel.

Validatieregels die men wenst toe te passen dient men eveneens in het model op te slaan.

Een voorbeeld van een model binnen deze masterproef is het model ‘Recording’, welke alle

regels en relaties met betrekking tot de tabel recordings behandelt. Elk model is een php-

bestand.

Een view is een representatie van gegevens uit het model. Variabelen, rijen en objecten die

in een view worden gebruikt, worden via de controller geregistreerd. Meestal worden enkel

de eenvoudige instructies in view gestoken, die nodig zijn om een goede representatie te

kunnen geven. Het resultaat van een view is een HTML-pagina waar bijvoorbeeld

zoekresultaten getoond worden. Elke view is een ctp-bestand (CakePHP Template).

De controller bevat de logica van de applicatie en handelt de verzoeken af van de gebruikers.

Hij is ook verantwoordelijk voor het ophalen en aanpassen van de gegevens uit de database

tabellen die door het model worden aangesproken. De controller bevat meerdere zelf

gedefinieerde functies zoals bijvoorbeeld de searchTags()-functie. Deze functie heeft

bepaalde variabelen als input (zoals zoekwaarden), verwerkt deze en geeft vervolgens een

nieuwe waarde door als resultaat. Elke controller is een php-bestand.

De scheiding in logische, modulaire secties zorgt ervoor dat een site beter handelbaar,

overzichtelijker en ook lichter wordt [6]. Hierdoor kan er aan elke sectie apart gewerkt worden en

kunnen ontwikkelaars en ontwerpers dus tegelijkertijd de site aanpassen zonder invloed te hebben

op elkaar. Bij het oplossen van fouten hoeft men de volledige code niet te kennen en enkel maar de

betrokken delen te onderzoeken. Het is ook eenvoudiger om nieuwe views of functies toe te voegen

zonder daarvoor eerst het model aan te passen.



Figuur 1: MVC Architectuur [6].

2.3. SQLite

Naast het selecteren van een geschikte programmeertaal en het bijhorend framework is de keuze

van een databasemanagementsysteem belangrijk. Om de servers van de onderzoeksgroep zo min

mogelijk te belasten wordt er geopteerd voor SQLite (versie 3.7.6). In tegenstelling tot MySQL of

Oracle gebruikt SQLite geen aparte server waarop de database werkt. Een SQLite database is een

klein bestand (< 1 MB) en heeft geen configuratie nodig. Het aanmaken van een SQLite database

gebeurt door het ingeven van de CREATE TABLE SQL commando’s in de SQLite command shell. SQLite

gebruikt een licht aangepaste vorm van de SQL syntax bij ingave van queries. Een belangrijk verschil

met de gestandaardiseerde SQL-taal is dat je geen kolommen binnen een tabel kan aanpassen of

verwijderen [7]. Verder voldoet SQLite ook aan de ACID-eigenschappen [7] voor transacties. ACID

staat voor ‘Atomair, Consistent, Isolatie en Duurzaam’ [8 p. 297]:

Atomair: alle transacties moeten atomair zijn.

Consistent: een transactie zet een database om van de ene consistente toestand naar de

andere.

Isolatie: transacties worden geïsoleerd van elkaar uitgevoerd.

Duurzaam: na het succesvol uitvoeren van een transactie wordt het resultaat ervan

permanent opgeslagen.

SQLite heeft naast bovenstaande voordelen echter ook nadelen. De derde versie van SQLite wordt

niet standaard ondersteund door CakePHP. Men biedt enkel ondersteuning voor versie 2. De officiële

websites van CakePHP en SQLite bieden geen oplossing voor het probleem en afgaande op het grote

aantal vragen met betrekking tot dit probleem is er ook geen vanzelfsprekende oplossing. De

CakePHP gemeenschap bood uiteindelijk de oplossing nadat een gebruiker een eigen DataSource-



bestand maakte voor SQLite3 [9]. Een DataSource binnen CakePHP zorgt voor de wisselwerking

tussen enerzijds het model binnen CakePHP en de onderliggende database. Een tweede nadeel is dat

SQLite geen integriteit betreffende het domein van een attribuut kan afdwingen [10]. Dit wordt

opgeloste door de validatiemogelijkheden van CakePHP, die deze taken overneemt.

2.4. JavaScript / JQuery

Voor scripting aan de client-side maken we gebruik van JavaScript en JQuery. JavaScript is een

programmeertaal waarmee men (delen van) websites interactief kan maken. In tegenstelling tot een

scripttaal als PHP wordt de website hier niet binnen de server gegenereerd, maar verandert de

website dynamisch binnen de browser van de gebruiker. Qua syntax lijkt JavaScript sterk op Java.

Gezien onze kennis van Java en beperkte kennis van JavaScript is dit het middel bij uitstek om

webpagina’s dynamisch te maken. In het kader van deze masterproef werd JavaScript voornamelijk

gebruikt bij het dynamisch maken van de flowcharts. Door gebruik te maken van geserialiseerde

JSON-strings (JavaScript Object Notation) kan men geen gebruik maken van de automatische

validatie door CakePHP. Om dit euvel te verhelpen, gebruiken we JavaScript om de ingegeven data te

valideren (punt 4.6.2.). Het navigatiemenu werd eveneens in JavaScript opgesteld.

Aanvullend wordt JQuery (versie 1.5.2) gebruikt, een JavaScript bibliotheek om dynamische websites

te creëren. Deze vereenvoudigt aanzienlijk het programmeerwerk voor de ontwikkelaar en maakt

rapid development mogelijk. De leuze van JQuery heet dan ook “Write less, do more” [11]. Andere

eigenschappen zijn de beperkte grootte van deze bibliotheek (31 KB) en de ondersteuning voor

verschillende browsers. In het kader van deze masterproef zorgt JQuery (meer specifiek jsPlumb)

voor het automatisch opstellen en tonen van flowcharts op elke individuele videopagina.



3. Database

De data rond het videomateriaal voor onderzoek naar het gebruik van cameranetwerken werd tot op

heden opgeslagen in XML-bestanden. Bij het toevoegen van nieuw videomateriaal moesten deze

bestanden telkens manueel aangepast worden. Teneinde dit proces te vereenvoudigen, maken we

de keuze om deze informatie op te slaan in een relationele database, meer specifiek een SQLite-

database. Bij het opstellen van onze database gingen we in drie stappen te werk: abstrahering,

modellering en implementatie [8 p. 59]. In dit hoofdstuk worden eerst deze drie stappen doorlopen

om tot een relationele database te komen. Vervolgens wordt er dieper ingegaan op de werkwijze

met betrekking tot het toevoegen van nieuwe methoden. Ten slotte bespreken we de extra tabellen,

toegevoegd om gebruik te maken van het CakePHP authenticatiesysteem.

3.1. Abstrahering

Het abstraheringproces heeft als doel de belangrijke zaken te onderscheiden van de minder

belangrijke met betrekking tot de te modelleren data. Deze stap dient volledigheid na te streven

zodat men geen informatie verliest bij het opstellen van de database. Hierbij wordt gekeken welke

informatie men wenst op te nemen in het conceptueel model en op welk niveau men de data wenst

te modelleren. Als basis van het abstraheringproces maken we gebruik van de bestaande XML-

bestanden en de multicamera directorystructuur. Hieruit kan men afleiden welke concepten

belangrijk zijn en tegelijkertijd de bijhorende eigenschappen in kaart brengen. Deze stap is cruciaal

als voorbereiding op het feitelijke modelleren. Indien men in deze stap belangrijke informatie over

het hoofd ziet, zal de database als resultaat gebreken hebben. Een tweede bron van informatie

waren onze begeleiders. Hierbij werd voornamelijk gecontroleerd op volledigheid van de

geïdentificeerde data en naar het belang ervan.

3.2. Modellering

Om de verkregen informatie uit het abstraheringproces conceptueel voor te stellen, maken we

gebruik van een diagram volgens de regels van het Enhanced Entity-Relationship-model (EER-model).

Dit EER-diagram zal in de implementatiefase op zijn beurt gebruikt worden om een SQLite-script af te

leiden (bijlage 6.2.). Het diagram wordt in het Engels opgesteld, omwille van de strenge conventies

van CakePHP betreffende bijvoorbeeld namen van tabellen en primaire sleutels [12].

3.2.1. Entiteittypes

Om de informatie uit de eerste stap om te zetten naar ons model gaan we van start met het

identificeren van entiteittypes. “Een entiteit is een ‘ding’ dat een zelfstandig bestaan leidt in de reële

wereld” [8 p. 62] en een entiteittype representeert een verzameling van deze entiteiten met

bijhorende attributen [8 p. 62]. Figuur 2 geeft de ontdekte entiteittypes weer met hun attributen. De



standaardnotatie voor een entiteittype is een rechthoek. De datatypes van attributen worden pas in

de laatste stap vastgelegd. Voor de datatypes kiezen we er dan voor om onmiddellijk te werken

volgens de SQLite-terminologie [7]. Deze verschilt miniem met de syntax van Structured Query

Language (SQL).

In figuur 2 zien we de geïdentificeerde entiteittypes: recording, sequence, video, calibration, tag en

method. De meerderheid van deze entiteittypes en hun attributen konden afgeleid worden uit de

verschillende XML-bestanden binnen de multicamera directory. Wat volgt zijn een aantal

opmerkingen met betrekking tot deze entiteittypes.

Elk van deze entiteittypes heeft een id als sleutelattribuut. Qua leesbaarheid van het database

schema dat we in de volgende stap ontwikkelen is dit niet optimaal. De naam recordingId zou

bijvoorbeeld duidelijker zijn, omdat het onmiddellijk aangeeft dat dit attribuut een primaire sleutel is

van recording. CakePHP vereist dat een primaire sleutel de naam id meekrijgt [12] en om optimaal

gebruik te maken van de functionaliteiten van CakePHP volgen we deze conventie. Verder werd aan

elk van deze entiteittypes het attribuut deleted met als datatype boolean toegevoegd. Deze werd

ingevoerd als extra beveiliging tegen het al dan niet met opzet verwijderen van data. Indien dit

attribuut true als waarde krijgt door de deleteknop te gebruiken binnen de website, zal het daartoe

horend gegeven niet meer zichtbaar zijn voor de gebruiker. Het verwijderde item zal echter in de

database blijven, zodat men foutieve verwijderingen nog steeds ongedaan kan maken.

Het entiteittype calibration verschilt met de overige entiteittypes doordat het maar in twee

bestaande recordings voorkwam. We nemen deze voor de volledigheid toch op in ons model. We

beschouwen dit als een apart entiteittype en niet als attributen onder recording om te vermijden dat

deze tabel veel null-waarden zou bevatten. Bij ingave van een nieuwe recording heeft men de keuze

om de informatie over de calibratie al dan niet in te vullen.

Het entiteittype tag kwam tot nu toe niet voor in de multicamera directory structuur en de XML-

bestanden. Eén van de doelstellingen van deze masterproef is het implementeren van een aantal

zoekfaciliteiten. Als onderdeel van deze faciliteiten wordt het zoeken op onderwerpen mogelijk

gemaakt. Hierbij had men de keuze om een extra attribuut ‘tags’ te voorzien bij bovenstaande

entiteittypes, maar dit verhoogt de kans op fouten bij ingave. Typefouten zouden ertoe leiden dat

bepaalde items niet in de zoekresultaten verschijnen en de gebruiker zou consistent moeten zijn in

het ingeven van tags (bijvoorbeeld elke keer ‘vergadering’ ingeven in plaats van ‘vergaderen’). Om

deze potentiële fouten te elimineren wensen we de verschillende onderwerpen op te nemen als

onderdeel van onze te ontwikkelen database [13 pp. 48-49]. Op basis van deze tabel wordt een

zoekpagina gegenereerd waarbij de gebruiker op onderwerpen kan filteren. Ten slotte beschouwen



Figuur 2: EER-diagram voor de opbouw van de database. Rechthoeken stellen entiteittypes voor, ruiten relatietypes en ovalen attributen. {1,N,M} is de kardinaliteit van de relatie, namelijk het aantal elementen dat maximum in een relatie kan participeren. Dit diagram vormt de basis voor het algoritme waarmee het databaseschema afgeleid kan worden. Een dubbele lijn wijst op totale participatie. EER-diagram aangemaakt in SmartDraw [15].



we kort het entiteittype method. Vertrekkende van bronvideo’s worden nieuwe video’s gegenereerd

door middel van een bepaald algoritme. Om deze methode op te nemen in onze database kan men

een attribuut toevoegen aan een relatie of de methode als entiteittype opnemen. De tweede optie

laat de gebruiker toe om op een flexibele manier nieuwe methoden toe te voegen (punt 4.6.2).

3.2.2. Relatietypes

Na het vastleggen van de entiteittypes worden de onderlinge relaties bepaald. De Tré [8 p. 63]

definieert een relatietype als “een verwantschap tussen twee of meer al dan niet verschillende

entiteittypes”. Deze worden symbolisch weergegeven als een ruit. Naast het vastleggen welke

entiteittypes gerelateerd zijn, is het ook belangrijk de kardinaliteitsrestrictie correct te kiezen. De

kardinaliteitsrestrictie begrenst het aantal entiteiten van een entiteittype binnen een relatie. Hierbij

zijn er meerdere opties mogelijk: één op één (1 – 1), één op meerdere (1 – N) en meerdere op

meerdere (M – N). Let wel dat een kardinaliteitsrestrictie steeds een maximum opgeeft. Het getal

één staat aldus voor één of geen entiteiten. Figuur 2 toont de relaties tussen de entiteittypes uit punt

3.2.1.

Tussen recording en sequence heerst een één-op-meerdere relatie. Elke recording bestaat uit één of

meerdere sequenties. Omgekeerd behoort elke sequentie tot één recording. Er is hier sprake van

totale participatie, omdat een sequentie tot een recording moet behoren. Een sequentie zonder

bijhorende recording moet onmogelijk zijn in de te ontwikkelen database. Elke recording heeft ook

een relatie tot de gebruikte calibratietechniek. Er is hier sprake van een één-op-één relatie, omdat

elke recording hoogstens een calibratie omvat. Sequence en video zijn eveneens gelinkt door middel

van een één-op-meerdere relatie. De interpretatie van deze relatie is analoog. Een sequentie omvat

meerdere video’s, terwijl een video altijd tot een sequentie moet behoren. De hierboven besproken

relaties krijgen de naam ‘contains’, omwille van het omvattende karakter tussen beide.

Vervolgens wordt de relatie tussen tag en respectievelijk sequence en video besproken. Het

oorspronkelijke plan was om het mogelijk te maken om op basis van de tags de recordings,

sequenties en video’s te laten doorzoeken. Na feedback van de begeleiders kozen we er echter voor

om geen tags aan recordings te linken. Recordings groeperen onderliggende sequenties, waardoor

het ‘taggen’ van recordings dubbel werk zou zijn voor de gebruiker. Beide relaties zijn van het type

meerdere-op-meerdere. Aan een bepaald onderwerp moet men meerder sequenties of video’s

kunnen linken. Omgekeerd kan een sequentie ook betrekking hebben op meerdere kernbegrippen.

Een dergelijke relatie wordt een ‘hasAndBelongsToMany’-relatie (HABTM) genoemd in CakePHP [14].

Deze relatie zorgt in bepaalde gevallen voor problemen binnen CakePHP met betrekking tot het



uitvoeren van bepaalde zoekopdrachten (punt 4.4.3.). Anderzijds is deze manier van het

implementeren van tags de enige correcte, waardoor er geen andere optie is.

De ternaire relatie tussen tweemaal video en method is een kunstmatige relatie, opgezet om het

genereren van flowcharts mogelijk te maken. Tijdens de ontwikkeling van deze website werd de

vraag gesteld of het mogelijk zou zijn de video’s onderling te linken. Tot nu toe was het onmogelijk

om visueel de onderlinge relaties bloot te leggen. Teneinde het hele proces met bijhorende

omzettingsalgoritmen visueel voor te stellen, wordt deze relatie in het leven geroepen. Deze relatie

koppelt een inputvideo met een outputvideo en legt de gekozen methode vast. Merk op dat zowel

de relatie flowchart als het entiteittype method beide het attribuut parameters hebben. Het verschil

tussen beide is dat de eerste de feitelijke data van een flowchart bevat, terwijl de tweede louter de

gebruikte parameters en hun datatypes (voor validatie) van een methode bevat.

3.3. Implementatie

Een laatste stap in het creëren van de database voor de website is de implementatie. Aan de hand

van een omzettingsalgoritme bestaande uit negen stappen kan een EER-model omgezet worden naar

een databaseschema (De Tré, 2007, hoofdstuk 5). Bij deze masterproef zijn niet alle

omzettingsstappen noodzakelijk. Volgende specifieke omzettingsstappen worden toegepast:

Omzetting van reguliere entiteittypes (calibration, method, recording, sequence, video, tag).

Omzetting van binaire één-op-één relatietypes (recording calibration).

Omzetting van binaire één-op-meerdere relatietypes (recording sequence, sequence

video).

Omzetting van binaire meerdere-op-meerdere relatietypes (tag sequence, video).

Omzetting van ternaire relatietypes (flowchart).

De omzetting van het EER-diagram kan u in bijlage 6.2. vinden. Na het uitvoeren van het

omzettingsalgoritme bekomen we het script uit bijlage 6.3., klaar om uitgevoerd te worden door

SQLite.

Teneinde deze database optimaal bruikbaar te maken voor het CakePHP framework, hebben er een

aantal wijzigingen plaatsgevonden aan de benaming van tabellen en sommige attributen om te

voldoen aan de conventies van het CakePHP framework. Een eerste conventie betreft de benaming

van tabellen binnen een database. Voor een goede werking van CakePHP moeten de namen van

tabellen steeds in het (Engelstalige) meervoud staan door een ‘s’ toe te voegen. Zo moet de tabel die

sequenties zal bevatten sequences heten in plaats van sequence. Een tweede conventie werd eerder

vermeld, namelijk dat de primaire sleutel van een tabel de naam id moet meekrijgen. Een laatste en



zeker niet onbelangrijke conventie is deze voor de benaming van vreemde sleutels [12]. CakePHP

automatiseert grotendeels de werking tussen gerelateerde sleutels. De enige voorwaarde om te

zorgen dat dit eenvoudig verloopt, is dat een vreemde sleutel een vooraf gedefinieerde benaming

aanneemt. Als voorbeeld kan men de relatie tussen de tabellen recordings en sequences nemen. De

tabel sequences bevat een vreemde sleutel die verwijst naar de tabel recordings, aldus moet deze de

benaming recording_id hebben. Men neemt dus de naam van de tabel waarnaar men verwijst (in het

enkelvoud) en voegt ‘_id’ eraan toe. Op deze manier herkent CakePHP automatisch het verband

tussen beide tabellen. Een laatste conventie die we overnemen is deze voor het attribuut dat het

aantal gerelateerde elementen bijhoudt. Om bijvoorbeeld het aantal video’s per sequentie bij te

houden, plaatsen we het attribuut video_count in de tabel sequences. Door de counterCache

functionaliteit van CakePHP te gebruiken is het niet meer nodig om zelf de aantallen te genereren bij

elke verandering.

3.4. Aanvullingen

Het SQLite-script in bijlage 6.3. is nog niet volledig. Er moet nog een aanpassing gebeuren voor het

authenticatie systeem die men niet kon opnemen in bovenstaande ontwikkeling van het

databaseschema. Eerst wordt de designkeuze betreffende het gebruik van methoden binnen de

database gemotiveerd. Vervolgens wordt een aanpassing besproken die het gevolg is van de

implementatie van een authenticatie systeem. Hiertoe dienen een aantal extra tabellen aangemaakt

te worden.

3.4.1. Methoden

Elke flowchart, die de omzetting van de ene video naar een andere beschrijft, heeft een eigen

methode. Men kan dit voorstellen als een ‘ISA’-relatie waarin flowchart het supertype is en elke

methode een subtype van flowchart vertegenwoordigt, maar er werd gekozen voor een ternaire

relatie. Om deze keuze te motiveren wordt hier de piste van de ‘ISA’-relatie verder uitgediept. Deze

toont aan dat het dynamisch toevoegen van nieuwe methoden niet mogelijk is als men deze

structuur toepast. Er is sprake van totale participatie, elke flowchart moet minstens een entiteit zijn

van een subtype [8 p. 75]. Bij het ontwikkelen van onze website werd gevraagd om het mogelijk te

maken om nieuwe methoden toe te kunnen voegen. Binnen het EER-model bekomt men

onderstaande figuur:



Figuur 3: Voorbeeld 'ISA'-relatie. Deze afbeelding toont het supertype Flowchart met twee subtypes Method X en Method Y. Een subtype erft de attributen van zijn supertype en voegt zelf een aantal attributen eraan toe (op de tekening zijn dit ovalen). Elke methode is met andere woorden een flowchart met een aantal specifieke attributen. Figuur aangemaakt in SmartDraw [15].

Deze figuur kan men volgens het omzettingsalgoritme op vier manieren [8 pp. 146-148] omzetten

naar een databaseschema. Hieronder wordt elke wijze geëvalueerd. Bijlage 6.4. vat deze methoden

samen.

1. Verschillende basisrelaties, voor het supertype en de subtypes. De ‘ISA’-relatie komt tot

uiting door de primaire sleutel van flowcharts op te nemen als primaire sleutel voor elke

methode (d.m.v. een vreemde sleutel). Dit houdt echter in dat er voor elke methode een

nieuwe tabel toegevoegd moet worden, wat bovenstaande vereiste inzake toevoegen van

nieuwe methoden onmogelijk maakt.

2. Verschillende basisrelaties, enkel voor de subtypes. Hier worden enkel voor de

verschillende methoden een tabel gecreëerd. Alle attributen van het supertype worden

doorgegeven aan het subtype (inclusief de primaire sleutel). Ook hier stelt zich het probleem

dat een nieuwe methode inhoudt dat er een tabel aangemaakt moet worden.

3. Eén basisrelatie met één typeattribuut. In dit geval worden alle attributen van alle subtypes

toegevoegd aan het supertype flowcharts. Daarnaast voegt men ook een typeattribuut toe

om aan te duiden om welke methode men gebruikt heeft. Deze werkwijze heeft als nadeel

dat bij het toevoegen van een nieuwe methode de bestaande tabel uitgebreid moet worden.

Verder zal een dergelijke tabel veel null-waarden bevatten, iets wat te vermijden is.



4. Eén basisrelatie met meerdere typeattributen. Deze laatste werkwijze is gelijkaardig aan

bovenstaande wijze. Het enige verschil is dat men niet werkt met één typeattribuut, maar

voor elke methode een attribuut met als datatype boolean aanmaakt. Dit houdt eveneens in

dat er veel null-waarden zullen bestaan en dat men bij elke nieuwe methode de tabel moet

aanpassen.

Teneinde de ‘ISA’-relatie toch te kunnen implementeren binnen de website, hebben we een

alternatieve manier uitgewerkt waarin we de relatie simuleren. Aan de tabel flowcharts worden de

attributen method_id en parameters toegevoegd. Deze zullen respectievelijk de gekozen methode en

bijhorende parameters bevatten. Door middel van een geserialiseerde JavaScript Object Notation

(JSON) string wordt de informatie opgeslagen binnen de output. Het datatype van deze velden is

respectievelijk ‘integer’ en ‘varchar’, waardoor de kans op fouten bij de invoer aanzienlijk is. Om dit

probleem op te lossen werd de tabel methods aan ons databaseschema toegevoegd. Deze tabel

bevat alle methoden, diens parameters en bijhorende datatypes (voor de parameters). De informatie

uit deze tabel kan gebruikt worden om de invoer in de tabel flowcharts met betrekking tot de

gekozen methode te automatiseren. Invoer gebeurt aan de hand van een automatisch gegenereerd

formulier. Dit formulier maakt gebruik van de tabel methods om de methoden en bijhorende

parameters in te laden. Het gebruik van JSON om de informatie op te slaan houdt in dat we zelf de

ingevoerde gegevens moeten valideren, men kan namelijk niet rekenen op de validatiefuncties

ingebouwd in CakePHP. Deze validatie gebeurt door middel van JavaScript (punt 4.6.3.) aan de hand

van de opgeslagen datatypes.

3.4.2. Authenticatie

Om de toegang tot de multicamera video’s enigszins af te schermen, maken we gebruik van de

authenticitatiemogelijkheden binnen CakePHP. Om gebruik te kunnen maken van authenticatie

binnen een CakePHP website dient men een aantal nieuwe tabellen aan te maken. De tabel users

bevat de informatie van alle gebruikers, waaronder de gebruikersnaam, wachtwoord (SHA1-

encryptie) en een vreemde sleutel die verwijst naar de tabel groups. Deze tabel bevat louter de

naam, het tijdstip van creatie en de laatste wijziging. Het toekennen van permissies op basis van

twee groepen, administrators en anonieme gebruikers, gebeurt later door middel van een PHP-

script. Naast deze worden bij het opstellen van het authenticatiesysteem drie extra tabellen

toegevoegd. In tegenstelling tot de overige tabellen gebeurt dit niet via een SQLite-script, maar via

een commando uit de CakePHP console (punt 4.7.). De tabellen worden echter in dit hoofdstuk reeds

besproken. Het is belangrijk op te merken dat CakePHP het grootste deel van de

authenticatiefunctionaliteit op zich neemt in plaats van het over te laten aan de ontwikkelaar. Om

deze redenen worden deze tabellen beperkt behandeld in onderstaande paragraaf door enkel de



logische voorstelling te bespreken. CakePHP maakt hierbij gebruik van het Modified Preorder Tree

Traversal-algoritme (MPTT).

De drie nieuwe tabellen heten respectievelijk aros, acos en aros_acos. De tabel aros bevat de

verschillende groepen en gebruikers. In het geval van deze masterproef is dat één gebruikersgroep,

administrator. De tabel acos bevat alle Access Control Objects, namelijk alle controllers en

bijhorende functies en/of webpagina’s. De tabel aros_acos combineert beide door gebruikers of

groepen te linken aan bepaalde acties. Op die manier wordt bepaald welke gebruiker of groep

toegang heeft tot een bepaalde functie. Indien een combinatie tussen een gebruiker en een bepaalde

webpagina niet gedefinieerd is binnen deze tabel, wordt hem de toegang ontzegd.



4. Opbouw van de webpagina’s

Het ontwikkelen van een geschikte database is de eerste stap bij het tot stand komen van een

website. Deze stap is cruciaal in het ontwikkelingsproces, omdat fouten in de database ongetwijfeld

doorschemeren in de daarop gebaseerde website. Tijdens het abstraheringproces binnen de

databaseontwikkeling verzamelden we, naast informatie over de feitelijke data, reeds informatie

over de gevraagde functionaliteiten. In de volgende stap wordt deze informatie gebruikt om de

website te ontwikkelen welke het beheer van experimentele multicameravideo zou moeten

vereenvoudigen. Dit hoofdstuk start met een overzicht van de algemene flow van de webpagina’s

aan de hand van twee gebruikersprofielen. Op deze manier krijgt men een duidelijk beeld van de

website in zijn geheel vooraleer er dieper ingegaan wordt op individuele webpagina’s. Er wordt ook

een beeld geschetst van de functionaliteit van het ‘bake’-commando uit de CakePHP console. Dit

commando maakt het mogelijk om automatisch een algemene structuur te genereren waarvan de

ontwikkelaar kan vertrekken. Vervolgens worden opeenvolgend de belangrijkste functies

uiteengezet.

Een eerste functie is de automatische detectie van toevoegingen binnen de multicamera directory.

Deze functie vereenvoudigt aanzienlijk het werk van de onderzoekers die tot nu toe gebruik maakten

van de XML-bestanden om hun werk te documenteren. Een tweede vereiste voor deze masterproef

is het voorzien van een aantal zoekmogelijkheden. Gezien de veelheid aan verschillende XML-

bestanden verspreid over de multicamera directory was het onmogelijk om te zoeken op basis van

bepaalde criteria. Deze masterproef vult deze leemte op door het mogelijk maken van het zoeken op

basis van strings en tags. De zoekresultaten kunnen op hun beurt geëxporteerd worden naar een .txt-

bestand. Op deze manier kunnen resultaten geïmporteerd worden in Excel, iets wat eveneens

omwille van bovenstaande reden nagenoeg onmogelijk was. Zoals eerder aangehaald maakt deze

website gebruik van twee gebruikersprofielen. Om dit tot stand te brengen werd gebruik gemaakt

van de authenticatiemogelijkheden van CakePHP. Als voorlaatste punt wordt de algemene lay-out

van de website besproken. Dit hoofdstuk sluit af met het bespreken van een aantal moeilijkheden bij

het ontwikkelen van deze website.

In wat volgt wordt per onderdeel ingegaan op de voornaamste designkeuzes, problemen en

belangrijkste functies binnen de CakePHP controller. Deze worden ondersteund door extracten uit de

code of afbeeldingen afkomstig van de website (tijdelijk) te vinden op

http://telin.ugent.be/~dvhaeren/multicamera.

http://telin.ugent.be/~dvhaeren/multicamera



4.1. Gebruikersprofielen

In dit onderdeel wordt de algemene flow van de website besproken uit het standpunt van twee

gebruikersprofielen, namelijk een anonieme gebruiker en een administrator. Deze opsplitsing wordt

gemaakt om de onderliggende database enigszins te beveiligen, terwijl het mogelijk blijft de data te

raadplegen. Onderstaand use case diagram geeft een overzicht van beide profielen.

Figuur 4: Use case diagram, opgesteld in UML. Dit schema toont twee gebruikersprofielen, een anonieme gebruiker en de administrator. De anonieme gebruiker kan de data raadplegen, bevragen en downloaden. De administrator kan bovenop deze functies ook data toevoegen, aanpassen, verwijderen. Verder kan hij tags, gebruikers en methoden beheren. Figuur aangemaakt in SmartDraw [15].

4.1.1. Anonieme gebruiker

Een eerste profiel binnen de website is deze van de anonieme gebruiker. Deze gebruiker kan het

merendeel van de data raadplegen zonder in te loggen. Deze persoon kan het algemeen overzicht

van de recordings, sequenties en video’s bekijken, net als de individuele pagina van een dergelijk

item. Het belangrijkste gevolg hiervan is dat hij toegang heeft tot alle informatie, waaronder de

flowcharts die aantonen op welke manier video’s onderling gerelateerd zijn. Naast het raadplegen

van de data met betrekking tot recordings, sequenties en video’s kan dit profiel gebruik maken van

de zoekfunctionaliteiten. Een eerste vorm betreft het zoeken op strings. Deze gebruiker kan

bijvoorbeeld zoeken naar alle video’s van een bepaalde auteur of op basis van de omschrijving. Een

tweede vorm is het zoeken op basis van kernwoorden (tags). De gebruiker krijgt in dit geval een

automatisch gegenereerde lijst met onderwerpen op basis waarvan men de data kan filteren. De

verkregen resultaten bij beide zoekvormen kunnen vervolgens gedownload worden als .txt-bestand

om verder te verwerken binnen Excel.



4.1.2. Administrator

Als tweede profiel is er de administrator die alle functies van de anonieme gebruiker overerft. De

groep van gebruikers met volledige rechten richt zich hoofdzakelijk op de onderzoekers die op

regelmatige basis gebruik zullen maken van deze website. Naast het raadplegen van de data zal één

van de voornaamste gebruikswijzen het toevoegen van nieuwe data zijn. De onderzoeker kan nieuwe

omzettingsmethoden toevoegen aan de database om later te gebruiken bij het aanmaken van

flowcharts. Na het creëren van nieuwe recordingmappen, sequentiemappen of het toevoegen van

video’s aan de bestaande directory kan een administrator vanuit de hoofdpagina kiezen om te

zoeken naar updates binnen de multicameramap. Deze pagina genereert een overzicht van

toegevoegde recordings, sequenties en video’s, waarna de administrator naar keuze nieuwe data kan

toevoegen. Hierbij is de administrator niet verplicht alle data in één beurt toe te voegen. Deze

mogelijkheid om data toe te voegen is een eerste functie waarvan de administrator geniet.

Een tweede belangrijke functie voor de administrator is het beheer van de verschillende

gebruikersaccounts. Door middel van een eenvoudige interface kan een administrator nieuwe

gebruikers toevoegen. Logischerwijze is deze functie afgescheiden van de anonieme gebruikers.

Naast de mogelijkheid om nieuwe gebruikers aan te maken, kan er ook een overzicht van alle

gebruikers opgevraagd worden en indien nodig aanpassingen of verwijderingen plaatsvinden.

Een derde en laatste functie, bovenop de functionaliteiten van een niet-ingelogde gebruiker, betreft

de manipulatie van bestaande data. Na het toevoegen van nieuwe data bestaat immers de kans dat

er fouten optreden bij de ingave ervan. De administrator kan dus bestaande informatie aanpassen

door middel van een editfunctie. Dit gebruikersprofiel kan ook bestaande informatie verwijderen.

Hieromtrent werd een extra beveiliging ingebouwd om het per ongeluk verwijderen van data tegen

te gaan. Indien bijvoorbeeld een video verwijderd wordt, zal een Boole aanse vlag op 1 gezet

worden. Hierdoor verschijnt deze video niet meer in overzichten of zoekresultaten, maar is deze nog

steeds aanwezig binnen de database. De administrator kan deze verwijderde data herstellen door

middel van een aparte herstelpagina.

4.2. Algemene functionaliteiten

Na dit overzicht van beide gebruikersprofielen worden eerst de algemene functionaliteiten

besproken. Een aantal functionaliteiten binnen de website zijn gelijklopend voor zowel recordings,

sequenties als video’s. Deze worden hier gegroepeerd behandeld, omdat deze op dezelfde wijze tot

stand gekomen zijn, namelijk door gebruik te maken van het ‘bake’-commando binnen CakePHP.



4.2.1. Het ‘bake’-commando

Een van de voordelen van CakePHP is de ‘bake’-functionaliteit. Bij de installatie van CakePHP binnen

een webserver wordt eveneens een klein programma meegeleverd om snel code te kunnen

genereren. De configuratie van dit programma is eenvoudig, men dient voor Windows in het

Configuratiescherm/Systeem/Geavanceerde instellingen/Omgevingsvariabelen te verwijzen naar de

PHP-map binnen de webserver en de console van CakePHP. Na installatie van de CakePHP console is

het belangrijk de strikte naamconventies van CakePHP met betrekking tot de database te volgen.

Hierdoor herkent CakePHP de algemene structuur van de database en kan er automatische code

gegenereerd worden voor CRUD-functies. Onderstaande afbeelding toont de algemene interface van

de Interactive Bake Shell van CakePHP. Deze kan opgeroepen worden binnen cmd.exe door te

navigeren naar de app-map binnen de webserver. Vervolgens plaatst men de database op dezelfde

locatie en typt men ‘cake bake’ binnen de opdrachtprompt. Na het intikken van dit commando

bekomt men de onderstaande interface:

Figuur 5: de CakePHP console.

Binnen deze console is het mogelijk om automatisch de juiste models, controllers en views te

creëren, met de mogelijkheid om tal van opties te implementeren. In wat volgt wordt per onderdeel

van de MVC architectuur besproken hoe men dit kan doen en in welke mate hiervan gebruik

gemaakt werd:

1. Model. Na in het hoofdmenu voor model te kiezen, kan men een keuze maken uit alle

tabellen die in de geselecteerde database aanwezig zijn. Eens het model gekozen, kan de

ontwikkelaar validatiecriteria vastleggen. We kozen ervoor om criteria voor de validatie van

de data zelf te coderen, omdat dit sneller gaat in bijvoorbeeld Notepad++. De CakePHP

console laat namelijk niet toe om criteria voor meerdere attributen tegelijk in te voeren. Een

tweede hulp die wel gebruikt werd is het automatisch herkennen van relaties tussen

tabellen. De strikte opvolging van de CakePHP naamconventies zorgt ervoor dat de console



automatisch herkent welke tabellen men met elkaar moet verbinden. Uiteraard dient de

ontwikkelaar aandachtig na te kijken of de suggesties correct zijn. Voor de meeste tabellen

kon er dan ook gebruik gemaakt worden van deze functie. Enkel bij flowcharts bleek dit niet

correct te werken, waardoor we manueel de verbinding moesten vastleggen. De oorzaak

hiervan ligt bij de tweevoudige verwijzing naar de videos tabel met niet-conventionele

namen voor de vreemde sleutels (sink_id en source_id). Om deze reden legden we manueel

een alias vast voor elke verbinding en definieerden we de benaming voor de vreemde

sleutels.

2. Controller. Deze tweede optie maakt het mogelijk om de code voor de meest generieke

CRUD-functies automatisch te genereren. Deze functies binnen de controller voeren de

queries uit om de gevraagde informatie door te geven aan een view of de ontvangen

informatie te verwerken. Wij maakten gebruik van de automatische code voor CRUD-

functies. Aangezien deze generiek waren en in het kader van deze masterproef eerder

specifieke queries nodig zijn, konden er geen rechtstreeks gebruikt worden. De code was

desondanks uitermate geschikt om de manier van programmeren binnen CakePHP onder de

knie te krijgen en vormde een uitstekende basis om op te bouwen. Zo stelt de console reeds

een aantal automatische controles in (zoals het willen aanpassen van een onbestaande

video). Het leerde ons ook hoe je data kan voorbereiden vooraleer het naar een view door te

sturen en hoe men het vervolgens binnen dezelfde actie kan verwerken om het in de

database op te slaan.

3. View. Een derde en belangrijke mogelijkheid binnen deze console is het automatisch

genereren van views. Deze views zijn de eigenlijke webpagina’s die de gebruiker te zien krijgt

bij het surfen naar de website. Net zoals het bij de controller het geval was, werd hiervan

voornamelijk gebruik gemaakt om te leren hoe men de informatie uit de controller op een

compacte manier kan weergeven binnen een webpagina. Deze views vormen een combinatie

van PHP en HTML, welke de manier van werken binnen de masterproef sterk beïnvloedt

heeft. De automatisch gegenereerde views maakten het ook gemakkelijk om testdata in te

geven. Op deze manier konden we reeds data toevoegen aan de database, zonder dat de

moeilijk te programmeren onderdelen reeds afgewerkt moesten zijn.

4.2.2. Standaard views

Een aantal views of webpagina’s hebben gelijkaardige kenmerken voor verschillende tabellen binnen

onze database. Zo verschillen de indexpagina’s van sequenties of video’s weinig, uitgezonderd het

verschil in gebruikte attributen. Om deze reden bespreken we deze gegroepeerd door een inzicht te



bieden in de algemene queries gebruikt binnen de controller. Op deze manier krijgt de lezer inzicht in

de website en meer specifiek de werking van CakePHP.

Een eerste webpagina die meerdere keren voorkomt is de indexpagina. Deze geeft een overzicht van

alle data binnen een tabel. Momenteel is de hoeveelheid weer te geven informatie vrij beperkt, maar

naar de toekomst toe zal dit ongetwijfeld veranderen. Om deze reden wordt geopteerd om de

Pagination functionaliteit te gebruiken [14]. Onderstaand voorbeeld geeft aan hoe men dit kan

oproepen:

$this->Video->recursive = 0;

$this->set(‘videos’, $this->paginate());

Dit voorbeeld toont onmiddellijk de kracht van de Pagination functionaliteit van CakePHP. Door

Pagination toe te passen, laadt CakePHP niet alle opgevraagde data in op de webpagina. De

ontwikkelaar kan binnen de controller instellen hoeveel items ingeladen mogen worden per pagina.

De data, opgeroepen door de paginate()-functie, kan gesorteerd worden door op de kolomhoofding

te klikken. Dit maakt de website gebruiksvriendelijker. Dit houdt in dat de hoeveelheid data per

webpagina aanzienlijk vermindert, wat de performantie van de website gunstig beïnvloedt. Indien

gewenst kan de gebruiker het aantal items per pagina aanpassen, als deze te ruim of te beperkt

gekozen is.

Naast het gebruik van de paginate()-functie wordt op een tweede manier de performantie van de

indexpagina bevorderd. Door recursive op nul te zetten, verhinder je dat CakePHP meer data inlaadt

dan nodig. Indien men de standaard instellingen van CakePHP gebruikt zou een indexpagina van

video’s niet enkel de opgevraagde video’s inladen, maar ook de gerelateerde sequenties, recordings,

tags en flowcharts. Dit zal in de toekomst verhinderen dat de website plots zou vertragen.

De viewpagina komt eveneens meerdere keren voor. Op deze webpagina kunnen individuele data uit

de database bekeken worden. Alle attributen worden aan de gebruiker gepresenteerd en

gerelateerde data worden weergegeven. Om het geheel overzichtelijk te houden, worden enkel

gerelateerde data getoond die zich één niveau dieper binnen de database bevinden. In het geval van

de sequenties wordt een lijst gegenereerd van alle video’s die zich binnen deze sequentie bevinden.

Om de gebruiksvriendelijkheid en flexibiliteit van dit overzicht te verhogen gebruikt men opnieuw

Pagination, zodat men ook binnen de gerelateerde data kan sorteren.

$this->set(‘recording’, $this->Recording->read(null, $id));

Om een individuele pagina op te zetten, maakt men gebruik van de read()-functie. Deze geeft alle

informatie betreffende één item uit de database terug. Teneinde de bijhorende data sorteerbaar te



maken, wordt er in combinatie ook de paginate()-functie gebruikt. Deze pagina bevat een aantal

detecties zoals kijken of de current_calibration-map aanwezig is voor een recording. Bij de

sequenties wordt gekeken of er xgtf-bestanden aanwezig zijn voor de verschillende camera’s.

De editpagina van verschillende soorten data kent eveneens een aantal gelijkaardige queries.

Voordat enige query uitgevoerd wordt door de controller wordt er, net zoals bij de viewpagina,

gekeken of de doorgegeven primaire sleutel bestaat. Indien het een bestaande primaire sleutel

betreft, laadt de controller door middel van de hierboven besproken read()-functie de bestaande

data in waarna de editwebpagina de bestaande data in het formulier invult. De gebruiker kan nu

aanpassingen uitvoeren en het model valideert deze informatie. Indien de informatie ongeldig is,

krijgt de gebruiker opnieuw de editwebpagina te zien. Doorstaat de ingevulde informatie de test, dan

verwerkt de controller de informatie (bijvoorbeeld door omzetting naar het correcte formaat) en

slaat deze informatie op in de database. Sommige editpagina’s hebben extra functionaliteiten zoals

het toevoegen van nieuwe tags of validatie van parameters door middel van JavaScript. Deze worden

verder besproken (punt 4.3.4. en 4.6.3.).

Bij het ontwikkelen van de website is het van belang dat de data enigszins beschermd is. Om deze

reden werd er een eigen delete- en herstelfunctie ontwikkeld. Elke tabel, uitgezonderd de tabel met

de gebruikers, heeft een extra attribuut deleted. Dit is een Booleaanse variabele die standaard op

false staat. Dit vormt een extra veiligheid tegen het bewust of onbewust verwijderen van data. Elke

administrator kan op deze manier de verwijderde data herstellen. Indien een gebruiker ervoor kiest

om een item te verwijderen, krijgt deze eerste een pop-up venster te zien. Dit vormt een eerste

beveiliging tegen het per ongeluk klikken op de verwijderknop. Indien men inderdaad bijvoorbeeld

een recording wenst te verwijderen, wordt de recording en al zijn gerelateerde sequenties, video’s

en flowcharts verwijderd. Dit vereenvoudigt het verwijderen aanzienlijk voor de gebruiker. Verder

kunnen gebruikers geen methoden verwijderen die in gebruik zijn door een gegeven uit de

flowcharts tabel. Anders zouden er problemen kunnen optreden bij het genereren van flowcharts.

Administrators hebben toegang tot een herstelpagina waar men een overzicht krijgt van alle

verwijderde data. Indien de gebruiker een element herstelt, worden alle gerelateerde elementen

eveneens hersteld. Men krijgt op deze pagina ook de keuze om elementen definitief uit de database

te verwijderen.

Om het navigeren doorheen de website gebruiksvriendelijk te maken, wordt er gebruik gemaakt van

een horizontaal menu in de hoofding van de webpagina. Initieel wensten we zelf een horizontaal

menu te creëren in JavaScript, maar bij de zoektocht naar duidelijke voorbeelden kwamen we op een

menu met een heldere structuur en eenvoudige code om te implementeren in onze website [16].



Hierdoor heeft de website een horizontaal menu in combinatie met een drop-down list. De enige

vereiste is dat er op de website vermelding wordt gemaakt van de bron, waaraan we voldoen door

rechtsonder in de webpagina een link te plaatsen onder de vorm van een kleine afbeelding.

4.2.3. Lay-out / CSS

CakePHP heeft een eigen standaardlay-out, opgemaakt door cake.generic.css (binnen webroot/css).

Deze vormt een stevige basis waarvan men kan vertrekken. Ondanks een gebrek aan ervaring met

CSS was het hierdoor toch mogelijk om een visueel aantrekkelijke website af te leveren, in plaats van

een standaard HTML-website. Desondanks hebben we zelf cake.generic.css aangevuld om de website

een eigen toets te geven. CSS werd ook gebruikt om bepaalde hyperlinks als knoppen voor te stellen.

Elke downloadknop en de klikbare tags binnen het zoeken op basis van tags werden zijn eigenlijk

hyperlinks die bepaalde parameters doorgeven. Door deze als een knop voor te stellen worden deze

voor de gebruiker visueel aantrekkelijk. Hierbij werd vertrokken van een online voorbeeld [17].

Verder hadden we ook aandacht voor de natuurlijke flow binnen de website. De homepage bevat

alle mogelijkheden waarvan de gebruiker kan genieten. De acties waarvoor permissie nodig is,

worden gegroepeerd als ‘Admin tools’. Het toevoegen van een horizontaal menu maakt dat de

navigatie sterk verbeterd wordt vanuit het standpunt van de gebruiker. Het gebruik van flowcharts

maakt ook dat de data visueel voorgesteld wordt, zodat de gebruiker onmiddellijk de nodige

informatie kan afleiden. Verder werden er grafieken gebruikt bij het overzicht van de recordings.

Deze toont het aantal sequenties per recording. Op de individuele pagina van een sequentie geeft

een grafiek het aantal video’s per sequentie weer. Deze grafieken werden opgesteld met behulp van

TufteGraph [18].

Figuur 6: (Fictief) voorbeeld van een grafiek, opgesteld met TufteGraph [18].



4.3. Detectie van nieuwe mappen/bestanden

Een belangrijk vereiste van de website die in deze masterproef ontwikkeld wordt is dat het mogelijk

moet zijn om nieuwe toevoegingen automatisch te detecteren. De werkwijze om dit te

implementeren is als volgt. In een eerste stap wordt de directorystructuur van de multicameramap

onderzocht om de verschillende scenario’s vast te kunnen leggen. Vervolgens gaat men dieper in op

het detecteren van de aan de directory toegevoegde elementen. Ten slotte wordt er in detail

gekeken hoe recordings, sequenties en video’s na detectie toegevoegd kunnen worden.

4.3.1. Inleiding

Tot nu toe werkte de onderzoeksgroep met XML-bestanden die op verschillende locaties binnen de

multicameramap geplaatst werden. Nadat de onderzoeker nieuwe video’s binnen de multicamera

directory plaatste, werden deze op verschillende locaties in XML-bestanden gedocumenteerd. Dit

heeft tot gevolg dat de kans dat de documentatie onvolledig of niet aanwezig is aanzienlijk stijgt. De

gewenste situatie bij de onderzoeksgroep is het zoveel mogelijk automatisch detecteren van nieuwe

data. Omdat deze directory reeds vele video’s bevat, dient de detectiecode specifiek toegespitst zijn

op de bestaande structuur. De totale hoeveelheid aan data zou te groot zijn om bijvoorbeeld te

herstructureren. In wat volgt wordt eerst de bestaande directory structuur besproken om meer

inzicht te bieden voordat de feitelijke detectie besproken wordt. Bijlage 6.5. toont de bestaande

directorystructuur [19].

Op het hoogste niveau binnen de multicameradirectory bevinden zich de verschillende recordings.

Een recording bevat een opname van een gebeurtenis en bestaat uit meerdere sequenties. Binnen

een recording kan men drie mappen vinden. De map recorded bevat de ruwe video data, zoals deze

oorspronkelijk opgenomen is. De map calibration bevat projectiematrices voor deze recording. De

derde en voor deze masterproef belangrijkste submap heet sync. Deze map bevat de sequenties

zoals deze door onze website herkend en toegevoegd zullen worden. Een sequentie is op zijn beurt

een verzameling van onderliggende video’s.

Video’s komen in verschillende formaten en op verschillende niveaus binnen de

multicameradirectory voor. Voor deze masterproef is het van belang dit onderscheid te

verduidelijken. Elke videosoort volgt een eigen weg door de MVC architectuur van de website. Een

eerste videosoort betreft de bronvideo’s. Deze video’s in .avi-formaat bevinden zich rechtstreeks

binnen de sequentiemap en vormen het vertrekpunt voor andere video’s. Een sequentie met

bijvoorbeeld 4 camera’s zal 4 bronvideo’s tellen, genaamd cam*.avi (met * een natuurlijk getal

groter dan nul). Bij het verwerken van de opgenomen video’s wordt per camera een bepaald

algoritme gebruikt om deze om te zetten tot een nieuwe video. Deze bewerkte beelden worden per



camera in een submap geplaatst binnen de sequentie, onder de naam cam*.out. Deze map bevat op

zijn beurt verschillende mappen per gebruikt algoritme. Zo staat in bijlage 6.5. de map

fgFramesMog47 voor een output volgens een bepaald algoritme. Deze video’s komen in drie vormen

voor. Een eerste vorm is opnieuw een .avi-formaat zoals de bronbestanden. Een alternatief is het

opslaan van een video in frames door middel van .png-bestanden. Een output kan men ook opslaan

als een .txt bestand. Deze vormen moeten dus opgenomen worden bij de detectie. Ten slotte kan

men nog een derde videosoort identificeren. Nadat de individuele bronvideo’s per camera omgezet

zijn, kunnen deze door opnieuw een algoritme toe te passen om ze samen te voegen een

sequentievideo als resultaat geven. Het onderscheid tussen deze drie videosoorten maakt dat we

voor elk een apart pad doorheen de MVC architectuur van de website moeten creëren. Een

bronvideo hoeft na toevoeging geen bronvideo en methode op te geven, terwijl dit bij de overige wel

het geval is. Een sequentievideo moet daarbovenop nog meerdere video’s als bron kunnen ingeven.

De moeilijkheid van de automatische detectie ligt in het automatisch detecteren van de videosoort

en het formaat van deze video’s.

4.3.2. Automatische detectie: algemeen

Na het onderzoeken van de bestaande directory structuur wordt er gestart met het opstellen van

een algemeen algoritme voor het detecteren van nieuwe bestanden/mappen. Elke categorie

(recording, sequentie of video) gebruikt intrinsiek dezelfde werkwijze. Men start met een lijst te

genereren van alle namen die zich in de database bevinden op een bepaald niveau binnen de

directorystructuur (bijvoorbeeld recording). Vervolgens scant men op hetzelfde niveau binnen de

multicameramap en plaatst men alle bestanden en/of submappen op dit niveau in een lijst. In het

geval van het scannen naar recordings zal de map //glfs/ipi/multiCamera doorzocht worden. De

array_diff($scanlijst, $dblijst) functie op basis van beide lijsten bezorgt een nieuwe lijst met

ontbrekende items die men vervolgens kan toevoegen aan de database. Aan de hand van deze lijst

wordt er op de updatepagina een overzicht geplaatst met de nieuwe items en een link om deze aan

de database toe te voegen. Indien mogelijk geeft deze link parameters door om het toevoegformulier

deels aan te vullen. Omdat SQLite geen domein integriteit garandeert (punt 2.3.), voegen we

validatieregels toe aan elk model. Onderstaande code geeft een voorbeeld van een dergelijk

validatieregel, waar voor de recordings gedefinieerd wordt dat men verplicht is het veld description

in te vullen.

var $validate=array('description' => array( 'rule' => 'notEmpty',

'message' => 'This field cannot be left blank'));

Het oorspronkelijke plan was om deze updates op te nemen als onderdeel van de homepage. Bij elk

bezoek zou de gebruiker een lijst gepresenteerd krijgen met de toe te voegen zaken. Deze aanpak



heeft zowel voor- als nadelen. Een voordeel is dat de gebruiker onmiddellijk te zien krijgt dat hij

nieuwe zaken kan toevoegen. Men zou dit mooi kunnen integreren in een verwelkomingpagina. Deze

aanpak heeft echter het nadeel dat men bij elk bezoek naar deze homepage de volledige zoekfunctie

doorloopt. Dit is in het nadeel van de performantie van de website. Momenteel is de database

relatief beperkt en zorgt dit voor weinig overhead, maar naar de toekomst toe zou dit voor

problemen kunnen zorgen. Teneinde dit probleem te kunnen vermijden hebben we de keuze

gemaakt om de update functie te scheiden van de homepage. Op deze manier kan de gebruiker het

scannen van de multicameradirectory uitvoeren op een moment naar keuze en is het probleem van

een traag ladende homepage zo vermeden. Om het overzicht te bewaren werd met JQuery voorzien

dat de gebruiker recordings en sequenties kan verbergen of tonen door erop te klikken.

4.3.3. Toevoegen van recordings

De ontwikkelde website scant na het drukken van een knop de multicamera directory door middel

van de scandir()-functie van PHP. Indien er binnen deze map op het hoogste niveau nieuwe mappen

ontdekt worden, verschijnt er op de updatepagina een melding dat er een nieuwe recording

gevonden is. Indien de gebruiker op de bijhorende link klikt, krijgt deze een formulier om de

recording toe te voegen. We kozen ervoor om de gebruiker de vrijheid te laten om onmiddellijk de

nieuwe recording te documenteren of dit later te doen. De gebruiker heeft niet altijd onmiddellijk de

tijd (of de zin) om een recording te documenteren, vandaar de keuze om dit over te laten aan de

gebruiker. Beslist de gebruiker om de ontdekte recording toe te voegen, dan krijgt deze een

formulier met de naam en de datum onmiddellijk ingevuld. Het is belangrijk dat de naam van de

recording identiek is aan de bijhorende submap van de multicamera directory. Om deze reden kan de

gebruiker de naam van de recording binnen dit formulier niet aanpassen. Wenst men dit wel nog te

doen, dan past men best eerst de naam aan van de map binnen de multicamera directory om

vervolgens de website een nieuwe scan te laten uitvoeren.

Het formulier binnen de pagina adjust_recording bevat tevens drie velden met betrekking tot de

calibratie. Bij het doornemen van de bestaande XML-bestanden voor recordings, kwamen we

specifieke data over de calibratie slechts eenmaal tegen. Om deze reden hebben we volgende

designkeuze gemaakt. De calibratie directory wordt automatisch ingevuld (ongeacht of deze effectief

bestaat). Deze bevindt zich altijd in binnen de recordingmap in een eigen calibratiemap met de naam

calibration. Omdat deze informatie tot nu toe amper gedocumenteerd werd, geven we de gebruiker

twee mogelijkheden. De eerste mogelijkheid is dat de gebruiker geen informatie over de calibratie

wenst te documenteren. In dit geval laat de gebruiker de velden Calibration Method en Calibration

Notes leeg. Door middel van een eenvoudige if-functie wordt er geen nieuwe calibratie toegevoegd

binnen de tabel calibrations indien beide velden leeg zijn. Wenst de gebruiker wel bijkomende



informatie te documenteren, dan kan hij één veld of beide velden wel invullen. Op deze manier

wordt opnieuw de keuze bij de onderzoeker gelegd en trachten we zo weinig mogelijk beperkingen

op te leggen. Indien de onderzoeker na het toevoegen beseft dat het toch nodig is om de

calibratiegegevens te documenteren, kan hij dit nog steeds aanpassen door middel van de

editpagina. Hier wordt echter de directory niet meer automatisch ingevuld en zal de gebruiker dit zelf

moeten doen. De editpagina laadt namelijk de bestaande informatie in en als er geen gerelateerde

calibratie bestaat, zullen de velden logischerwijze leeg zijn.

4.3.4. Toevoegen van sequenties

Het toevoegen van nieuwe sequenties verloopt analoog aan de werkwijze voor sequenties. Om die

reden worden hier enkel de verschillen besproken. Een eerste verschil met bovenstaande werkwijze

is dat niet elke nieuwe sequentie onmiddellijk aan de gebruiker getoond wordt. De sequenties

bevinden zich dieper binnen de mappenstructuur, waardoor we voor elke recording een apart path

moeten opstellen volgens de vorm multiCamera/[Recording_naam]/sync. Eerst laadt men de namen

van alle recordings in om vervolgens in een lus per recording het path samen te stellen en op deze

locatie te scannen naar sequenties. Binnen deze lus worden de twee lijsten gegenereerd. Een lijst

met gescande sequenties binnen de respectievelijke recordingmap en een lijst met sequenties voor

deze recording uit de database. Door de array_diff()-functie van PHP toe te passen bekomen we de

namen van de sequenties die zich nog niet in de database bevinden. Opnieuw krijgt de gebruiker een

melding dat er een nieuwe sequentie gevonden is voor een bepaalde recording.

Het voordeel van deze werkwijze is dat de gebruiker verplicht wordt om een correcte en logische

volgorde van data toevoegen te volgen. Zolang een recording niet in de database aanwezig is, zal

bovenstaand algoritme voor deze recording geen path aanmaken en deze locatie niet scannen.

Aangezien de tabel sequences door middel van de vreemde sleutel recording_id naar de tabel

recordings verwijst, is het van belang dat de desbetreffende recording eerst toegevoegd wordt. Een

tweede voordeel is dat de gebruiker beter het overzicht kan bewaren.

Het toevoegen van de sequentie via een formulier verloopt gelijkaardig met de werkwijze bij een

recording. De naam van de sequentie, directory en een suggestie voor het aantal camera’s worden

automatisch ingevuld in het formulier en de gebruiker kan de eerste twee niet wijzigen. Dit is

opnieuw een beveiliging om te garanderen dat er geen inconsistenties optreden tussen de

multicameramap en de database. Op de achtergrond wordt automatisch de link gelegd met de

bijhorende recording, zodat er geen fouten gemaakt kunnen worden bij het invullen van de vreemde

sleutel. Sequenties en video’s kunnen getagd worden, waardoor het zoeken op kernwoorden

mogelijk is. Teneinde de gebruiker het minimum aan formulieren voor te schotelen is het toevoegen



van tags geïntegreerd in het formulier. De gebruiker krijgt bij aanvang een keuzelijst met reeds

bestaande tags waarbinnen hij één of meerdere tags kan selecteren (met behulp van de CTRL-toets).

De gebruiker kan rechtstreeks één of meerdere nieuwe tags toevoegen door deze in te vullen in het

daartoe bestemde veld. In het geval van meerdere nieuwe tags moet hij deze splitsen door middel

van het teken ‘;’. Na het drukken van de submitknop zal de controller de nodige bewerkingen

uitvoeren om nieuwe tags te creëren en vervolgens deze aan de nieuwe sequentie te linken.

4.3.5. Toevoegen van video’s

Zoals eerder vermeld in punt 4.3.1. identificeren we drie videosoorten. Globaal gezien volgen de drie

soorten hetzelfde schema als hierboven. Er treden echter enkele nuances op die het onderling

verschil maken.

Een eerste videosoort betreft de bronvideo’s. Deze bevinden zich binnen de sequentiemap en

hebben het .avi-formaat. Opnieuw wordt hier een path samengesteld waarbinnen men zal scannen.

De moeilijkheid hierin is dat het aantal for-lussen toeneemt naarmate men dieper de structuur

binnendringt. Dit maakt de code moeilijk leesbaar. Om dit probleem op te lossen, hebben we

commentaren geplaatst ter verduidelijking. Binnen de lussen wordt een pathnaam opgesteld van de

vorm multiCamera/[Recording_naam]/sync/[Sequentie_naam]/. Beide namen tussen vierkante

haakjes worden door de for-lussen ingevuld. Er wordt opnieuw gebruik gemaakt van de PHP-functie

array_diff() en de gebruiker krijgt per sequentie een lijst van ontdekte bronvideo’s. Na het klikken op

de hyperlink om een bronvideo toe te voegen, wordt automatisch het path en de gerelateerde

sequentie ingevuld. Deze zijn opnieuw niet wijzigbaar door de gebruiker.

Vertrekkende van de verschillende bronvideo’s per camera gebruiken onderzoekers een algoritme

om deze bronvideo’s om te zetten tot nieuwe video’s. Deze tussenresultaten noemen we in deze

scriptie bewerkte video’s. Deze bewerkte video’s komen in drie vormen voor, namelijk in het .avi-

formaat, onder de vorm van een map met .png-afbeeldingen of als een map met een .txt- bestand.

Om de website zo dynamisch mogelijk te maken wordt binnen de home controller een lijst geplaatst

waarbinnen men ook andere extensies kan plaatsen. In de toekomst kan het namelijk zijn dat een

nieuwe extensie als video gebruikt wordt. Deze video’s bevinden zich steeds binnen een map met als

path multiCamera/[Recording_naam]/sync/[Sequentie_naam]/cam*.out/. Op basis van het aantal

bronvideo’s kennen we de benamingen van de verschillende cam*.out mappen. Uit de pathnaam

volgt dat de website nog een niveau dieper moet scannen om de onderliggende mappen te

detecteren. Elke methode krijgt een eigen map binnen bovenstaand path. Deze worden allemaal

gescand en er wordt gekeken of de onderliggende bestanden van het .avi-formaat zijn of een

verzameling van .png-afbeeldingen. De gebruiker krijgt opnieuw een link om de ontdekte video’s toe



te voegen. Na toevoeging van een video moet de onderzoeker ook de afkomst van de video

documenteren om later een flowchart te kunnen genereren. Deze stap wordt besproken in punt

4.5.2.

Een laatste videosoort zijn de [Sequentie_naam].out-video’s. Nadat de bronvideo’s per camera

bewerkt zijn met een bepaald algoritme, worden deze bewerkte video’s samengevoegd tot een

[Sequentie_naam].out-video. Deze worden op een gelijkaardige manier gedetecteerd als de

bewerkte video’s uit bovenstaande paragraaf. Deze kunnen eveneens bestaan uit .avi-formaat of een

map met .png-afbeeldingen. Het grote verschil is dat na toevoeging van deze video aan de database

er meerdere flowcharts gegenereerd moeten worden voor dezelfde video. Een dergelijke video is

afkomstig van meerdere bewerkte video’s die op hun beurt met een algoritme samengevoegd

worden. De wijze van documenteren om vervolgens een flowchart te kunnen genereren wordt in

punt 4.5.2. verder uitgediept.

4.4. Zoekfunctionaliteit

4.4.1. Inleiding

Een tweede vereiste voor deze website is het implementeren van een aantal zoekmogelijkheden. Tot

op heden werkten de onderzoekers met XML-bestanden, verspreid over de multicameramap. Er

waren nog geen zoekmogelijkheden voorzien en zelfs het manueel zoeken naar een bepaalde video

kon veel tijd in beslag nemen en zou op termijn nagenoeg onmogelijk worden. Bij de overschakeling

naar een website met een onderliggende database wenst men dat we een aantal zoekmogelijkheden

implementeren. Bovendien moet het mogelijk zijn om de resultaten (en de data in het algemeen) te

exporteren naar bijvoorbeeld een .txt-bestand voor verdere verwerking in Excel. Aan deze wensen

tracht deze masterproef te voldoen door twee zoekvormen te implementeren.

Een eerste vorm is het zoeken naar strings binnen recordings, sequenties en video’s. Afhankelijk van

de gekozen tabel kan men op bepaalde velden zoeken naar één of meerdere strings. Daarboven kan

men, door aanhalingstekens te gebruiken, op een vaste combinatie van strings zoeken zoals het

onder meer op Google.com mogelijk is. Een tweede vorm maakt het zoeken op kernwoorden (of

tags) mogelijk. Deze veelgebruikte vorm op het internet zorgt ervoor dat aan elke sequentie of video

een aantal kernwoorden gelinkt kan worden. Er werd bewust gekozen om geen tags te voorzien voor

recordings. Een recording is immers een verzameling van sequenties. Deze redenering zou ook

kunnen opgaan voor de verschillende sequenties die een groep video’s omvatten, maar in

tegenstelling tot bij sequenties zal de hoeveelheid tags beperkt kunnen blijven. Bij recordings

daarentegen die telkens een grote verzameling sequenties en video’s omvatten zou het

onoverzichtelijk kunnen worden.



Op de volgende pagina’s zullen achtereenvolgens het zoeken op strings en het zoeken op tags

uiteengezet worden. Net als bij de automatische detectie wordt er niet in detail getreden, maar

wordt de algemene flow voor de gebruiker uiteengezet en de werkwijze verklaard. In deze

masterproef start men met het uitdiepen van het zoeken naar strings. Vervolgens wordt het zoeken

naar tags uit de doeken gedaan met aandacht voor de moeilijkheden en minpunten van CakePHP

met betrekking tot het zoeken op basis van tags. Ten slotte wordt het exporteren van de resultaten

naar een .txt-bestand besproken, met onder meer de werkwijze en de motivering van de keuze voor

het .txt-formaat.

4.4.2. Zoeken naar strings

Als eerste zoekfunctionaliteit wordt het zoeken naar strings mogelijk gemaakt. De gebruiker kan uit

het menu kiezen om naar de zoekpagina te gaan voor respectievelijk recordings, sequenties of

video’s. Afhankelijk van zijn keuze zal de gebruiker kunnen kiezen uit meerdere velden waarbinnen

men kan zoeken. De gebruiker heeft de keuze uit volgende velden:

Recording: naam, omschrijving, auteur, opmerkingen

Sequentie: naam, omschrijving

Video: auteur, omschrijving

Tijdens het overlopen van de vereisten met de thesisbegeleiders kwam de vraag of het mogelijk is

om het zoeken op strings uit te breiden naar het zoeken op basis van een combinatie van strings

tussen aanhalingstekens. De meest bekende toepassing van deze manier van zoeken is de

zoekmachine van Google.com. Er werd tevens aangeraden om, indien mogelijk, gebruik te maken van

zoekplugins voor CakePHP. Na het zoeken van plug-ins voor CakePHP bleek echter dat er geen plug-

ins voorhanden waren die in het kader van deze masterproef nuttig zouden zijn. Zo waren sommige

plug-ins niet van toepassing op onze databasestructuur. Aangezien de zoekfunctionaliteit in een laat

stadium van deze masterproef tot stand kwam, bestond de mogelijkheid niet om de bestaande

structuur sterk aan te passen. Deze aanpassingen zouden gevolgen hebben voor alle functies binnen

de controllers en alle reeds aangemaakte webpagina’s.

Om deze reden werd geopteerd om zelf een zoekfunctie te coderen. Ondanks de moeilijkheid om

een goede zoekfunctie zelf te coderen, biedt het ook een opportuniteit om te leren uit de

ontwikkeling ervan. Als eerste stap bij het ontwikkelen van deze zoekfunctionaliteit werd een

algoritme opgesteld om het zoeken naar strings uit te werken. Het zoeken naar strings kan

opgedeeld worden in twee onderdelen. Het eerste behandelt het interpreteren van de input en het

omzetten naar een bruikbare vorm voor de feitelijke zoekquery. Men stelt met andere woorden de



voorwaarden op die aan de paginate()-functie doorgegeven zal worden. Deze zal op zijn beurt alle

data zoeken die voldoen aan deze voorwaarden.

De input, ingegeven door de gebruiker, wordt na het klikken op submit binnen de controller

verwerkt. Een eerste stap in dit proces is het vermijden van dubbele spaties en nutteloze spaties aan

het begin of het einde van de input. Onderstaande code demonstreert dit:

$input = trim(ereg_replace("[ \t]+", " ", $this->data['Recording']['lookFor']));

De PHP-functie ereg_replace() vervangt alle dubbele spaties en tabulaties door een enkele spatie. De

trim()-functie op zijn beurt verwijdert alle onnodige spaties aan het begin en na het einde van de

input. Voorafgaande deze stappen werd reeds gecontroleerd of het aantal aanhalingstekens even is,

met andere woorden of alle geopende aanhalingstekens opnieuw gesloten zijn. Deze controles

houden al een aantal mogelijke fouten tegen. Na deze foutencontrole wordt de ingegeven string

opgesplitst en in een lijst geplaatst met de explode()-functie:

$inputSpace = explode(' ', $input);

Deze functie splitst de ingegeven zoektermen op basis van het spatieteken. Hierdoor krijgen we

reeds een eerste verdeling per zoekterm. Sommige zoektermen moeten echter een vaste combinatie

vormen doordat deze tussen aanhalingstekens geplaatst zijn. De elementen binnen de verkregen lijst

worden in een for-lus geplaatst om combinaties op te sporen. Indien er fragmenten van een vaste

combinatie gevonden worden, worden deze in één element van een nieuwe lijst geplaatst. Een vaste

combinatie start met een aanhalingsteken en eindigt opnieuw met een aanhalingsteken. Deze

redenering werd in een algoritme geplaatst en geeft een nieuwe lijst met alle zoektermen terug.

Deze worden in een laatste stap in de vereiste vorm gegoten om door te kunnen geven aan CakePHP:

$conditions['OR'] = array();

for($i = 0; $i < count($inputCorrect); $i++)

{

$conditions['OR'][$i]['Recording.'.$location.' LIKE'] = '%' . trim($inputCorrect[$i]) . '%';

}

Door het gebruik van ‘LIKE’ in de conditie wordt de query hoofdletterongevoelig. De gebruiker kan

dus zowel met hoofdletters werken als deze volledig negeren. Het tweede deel van de zoekfunctie

volgt de standaardwijze waarop je via CakePHP een database kan bevragen.

$this->paginate['Recording'] = array('conditions' => $conditions, 'recursive' => 0, 'limit' => 100);

$this->set('results', $this->paginate('Recording'));

Er wordt hier opnieuw gebruik gemaakt van de Pagination-functionaliteit van CakePHP. Hierdoor

wordt slechts een fractie van de opgevraagde data ingeladen. De server wordt hierdoor minder

belast en dit bevordert de performantie van de website. Een tweede voordeel is het visuele aspect.



De zoekresultaten blijven overzichtelijk voor de gebruiker en hij kan sorteren per kolom, net zoals in

Excel. Het gevolg van het zelf ontwikkelen van een zoekfunctie is tweezijdig. Enerzijds was het

interessant en uitdagend om dergelijke zoekfunctie te ontwikkelen, anderzijds zal het

hoogstwaarschijnlijk onderdoen voor alternatieven geprogrammeerd door ervaren ontwikkelaars.

Deze zoekfunctionaliteit werkt naar behoren voor de gewenste functionaliteit en behoedt de

gebruikers reeds voor een aantal vaak voorkomende fouten zoals dubbele spaties of het niet

afsluiten van aanhalingstekens.

4.4.3. Zoeken naar tags

Het gebruik van tags is de laatste jaren op het internet sterk ingeburgerd. Men kan items uit een

database zoals sequenties of video’s voorzien van bijhorende tags. Deze kernwoorden laten

vervolgens toe om door middel van bijvoorbeeld een tag cloud of een filterfunctie binnen de

database te zoeken. De begeleiders haalden het voorbeeld aan van StackOverflow.com. Deze

website laat toe om door tags aan te klikken een AND-filter toe te passen. Op hun frontpage staan de

meest recente tags verzameld en op een aparte pagina staan alle tags gesorteerd volgens hun

belang: het aantal keren dat deze tag gebruikt is. Binnen deze masterproef wordt een gelijkaardige

zoekfunctie geïmplementeerd. Een designkeuze waarop wij van mening verschillen met de eerder

aangehaalde website is dat wij de tags liever alfabetisch rangschikken. Dit bevordert de snelheid

waarmee een gebruiker een tag kan lokaliseren, zeker in het geval van een groot aantal tags. Het

rangschikken volgens gebruik van een tag kent ook zijn voordelen, maar indien men een weinig

voorkomende tag zoekt, moet men langer zoeken dan nodig. Figuur 7 toont het verkregen resultaat:

Figuur 7: (Fictief) voorbeeld voor het zoeken op basis van tags.



Eerder werd reeds aangehaald dat de relatie tussen de tabellen tags en sequences/videos een

meerdere-op-meerdere relatie is of een HABTM-relatie in CakePHP-termen. Om bovenstaande filter

mogelijk te maken, moeten we kunnen zoeken aan de hand van een AND-functie. CakePHP heeft een

uitstekende tutorial om complexe zoekvoorwaarden op te stellen, maar de HABTM-relaties krijgen

hierbij weinig aandacht. Er is geen voorbeeld voorhanden voor een HABTM-relatie en de

gedemonstreerde AND-voorwaarde draait uit op een onbruikbare query gegenereerd door CakePHP:

Select * From X WHERE Tag.id = 1 AND Tag.id = 2

CakePHP zoekt binnen de tabel tags naar een tag met primaire sleutel 1 en primaire sleutel 2. Een

primaire sleutel is altijd uniek, waardoor deze query uiteraard geen resultaat oplevert. Teneinde dit

probleem op te lossen werd er gezocht naar een plug-in om dit probleem op te lossen. Dit bleek

echter niet eenvoudig te zijn. Er werd slechts één bruikbare plug-in gevonden [20], maar deze werkte

niet naar behoren. Deze plug-in gaf niet de correcte resultaten en had problemen met het updaten

van zijn resultaten na een bewerking op de database. Er waren verder geen andere plug-ins te

vinden, omdat zoeken op basis van een AND-functie met tags niet frequent voorkomt. Een groot deel

van de ontwikkelaars opteert voor een tag cloud, omwille van de eenvoudige implementatie en het

visuele aspect. CakePHP blijkt problemen te hebben met het correct uitvoeren van een join bij

HABTM-relaties en zelfs op het niveau van de database is dit een moeilijke query om uit te voeren

[20].

Uit bovenstaande argumentatie kan men concluderen dat er geen ideale oplossing bestaat om een

zoekfunctie op basis van tags te implementeren. Om deze reden werd er besloten om ook hier een

eigen zoekfunctie te schrijven, geïnspireerd door bovenstaand voorbeeld. Het zoeken op tags zal

meer queries nodig hebben dan het zoeken op strings. Hierdoor is het van belang om de uitgevoerde

queries zo efficiënt mogelijk te maken door middel van twee functionaliteiten van CakePHP. De

eerste is het gebruik van Pagination wat eerder beschreven werd. Aanvullend maken we opnieuw

gebruik van het instellen van de recursiviteit van het zoeken, zodat er zo weinig mogelijk informatie

ingeladen wordt.

Op de zoekpagina waarop de gebruiker kan filteren, staan rechts op het scherm de verschillende

tags. Deze worden met drie per lijn gegroepeerd zodat de gebruiker niet horizontaal moet scrollen

indien er zich veel tags op de webpagina bevinden. Door het toepassen van CSS lijken de tags

knoppen te zijn, hoewel dit eigenlijk hyperlinks zijn die de bijhorende primaire sleutel van een tag

doorgeven aan de functie binnen de controller. Een tweede parameter, als het ware de geschiedenis

van de zoekopdrachten, geeft aan welke selecties aan deze pagina vooraf gingen. Hierna wordt door



middel van een foreach-lus voor elke tag gezocht naar de overeenkomsten binnen de

sequences_tags-tabel. Op deze manier omzeilen we het probleem. De sequences_tags-tabel bevat

enkel verwijzingen naar respectievelijk tags en sequences door middel van vreemde sleutels. Door

opeenvolgend te zoeken naar de overeenkomstige primaire sleutels van sequenties met een

bepaalde tag, krijgen we een lijst met in elke cel een groep van sequentie-id’s.

foreach($and as $loop):

$this->Sequence->contain();

$temp = $this->SequencesTag->find('all', array('conditions' => array('SequencesTag.tag_id' =>

$loop)));

$seqNrs = array();

foreach($temp as $loop1):

array_push($seqNrs, $loop1['SequencesTag']['sequence_id']);

endforeach;

$output[$counter] = $seqNrs;

$counter++;

endforeach;

De verkregen lijst wordt nog verder gefilterd, omdat deze momenteel alle id’s bevat op basis van een

‘OR’-functie. Dit probleem wordt opgelost door meermaals de PHP-functie array_intersect() toe te

passen. Hiermee simuleren we de AND-functie doordat voor elke resultatenlijst per tag vergeleken

wordt met de eerste. Het element $output[0] behoudt telkens de id’s die tot elke tag in de selectie

toebehoren. Onderstaande code toont deze functie:

for($i = 1; $i < count($output); $i++)

{

$temp1 = $output[0];

$temp2 = $output[$i];

$output[0] = array_intersect($temp1, $temp2);

}

De variabele $output[0] bevat de primaire sleutels van de sequenties die voldoen aan de gestelde

AND-voorwaarde. Indien er maar één tag in de AND-voorwaarde opgenomen is, wordt bovenstaande

stap overgeslagen. Het laatste wat in de controller gebeurt is de bijhorende informatie inladen voor

de verkregen primaire sleutels en doorsturen naar de webpagina. We creëren met andere woorden

een query onder de vorm van:

SELECT * FROM sequences WHERE id IN (1, 2, 8, …)

Deze werkwijze is uiteraard minder efficiënt dan een eenvoudige find-query van CakePHP, maar zoals

eerder aangehaald werkt deze standaard niet voor HABTM-relaties. Men kan zich de vraag stellen of

deze werkwijze op lange termijn werkbaar is. Teneinde te verhinderen dat de performantie van de

website achteruit gaat, werd de volgende functie gebruikt:



$this->paginate['Sequence'] = array('conditions' => $conditions, 'recursive' => 0, 'limit' => 100);

$this->set('results', $this->paginate('Sequence'));

De combinatie van Pagination en recursiviteit zorgt ervoor dat er een minimum aan informatie

doorgegeven wordt aan de webpagina. Er worden telkens maar een fractie van de resultaten

ingeladen en recursive gelijkstellen met nul zorgt ervoor dat geen onnodige gerelateerde data

inlaadt. Dit beperkt aanzienlijk het aantal queries dat CakePHP zal genereren op basis van

bovenstaande functie. Bij het testen van de zoekfunctionaliteit merkten we op dat het aantal queries

doorgegeven aan de database lineair stijgt met het aantal tags waarop men zoekt. Per extra tag

wordt één nieuwe query toegevoegd aan de bewerking, het logische gevolg van de for-lus uit de

code op pagina 36. Om deze reden kunnen we geloven dat de zoekfunctie niet aanzienlijk zal

vertragen naar de toekomst toe. Bovendien wordt het aantal zoekresultaten alsmaar kleiner

naarmate men meer tags selecteert, waardoor men minder resultaten uit de database moet halen en

het aantal opeenvolgende tags eerder beperkt zal zijn.

Bij de algemene werking van onze zoekfunctie kunnen twee aanvullingen gemaakt worden. Een eerst

is de mogelijkheid om geselecteerde tags ongedaan te maken door deze aan te klikken. Opnieuw zijn

dit hyperlinks onder de vorm van een knop met meerdere parameters die aan de controller

doorgegeven worden. Op deze manier wordt de geselecteerde tag verwijderd uit de

zoekgeschiedenis en krijgt men de resultaten terug. Een tweede aanvulling betreft de vraag van de

begeleiding om een veld te plaatsen, waarin men een eerste tag kan invullen. Vaak zal op basis van

een eerste tag reeds een groot deel weggefilterd worden, waardoor deze toevoeging handig is. Deze

maakt eveneens gebruik van bovenstaand algoritme en vergt weinig aanpassen ten opzichte van de

originele code.

4.4.4. Exporteren van zoekresultaten

Na het uitvoeren van één van beide zoekfuncties kunnen de verkregen resultaten gedownload

worden van de website. We verkozen een uitvoerbestand in .txt-formaat te genereren, omwille van

de compatibiliteit met onder meer Excel. Door de verschillende kolommen te splitsen met tabulaties,

kan de gebruiker eenvoudig het .txt-bestand importeren in Excel. Deze downloadfunctie bevindt zich

op meerdere plaatsen binnen verschillende controllers. Telkens wordt dezelfde werkwijze gevolgd.

Onder de zoekresultaten bevindt zich een knop welke naar een downloadfunctie binnen een

controller wijst. Analoog aan bovenstaande zoekfuncties wordt eerst het zoekalgoritme uitgevoerd.

In tegenstelling tot bovenstaande functies worden de zoekresultaten niet doorgegeven aan een

webpagina, maar worden deze rechtstreeks weggeschreven naar de webroot en vervolgens als

download aangeboden aan de gebruiker.



$txtfile="output.txt";

$file=fopen($txtfile,"w");

fwrite($file,"Recording_id:"."\t");

…

De PHP-functie fopen() opent een nieuw bestand binnen de webroot van de server, genaamd

output.txt. Dit bestand wordt telkens overschreven bij het aanvragen van een download. Omdat een

.txt-bestand weinig geheugen inneemt, vormt dit geen probleem. Vervolgens kan men met de

functie fwrite() naar het geopende bestand schrijven. In alle gevallen wordt gestart met het schrijven

van de kolomhoofdingen. Een volgende stap is het wegschrijven van de gevonden zoekresultaten

door middel van een foreach-lus:

foreach ($data as $print):

fwrite($file, $print['Recording']['id']."\t");

…

fwrite($file,"\n");

endforeach;

fclose($file);

Binnen deze lus wordt in bovenstaand voorbeeld de data per recording weggeschreven. Het

wegschrijven van elke recording eindigt met een nieuwe lijn, zodat de output in Excel correct

weergegeven wordt. Eens deze lus doorlopen is wordt het ouput.txt bestand opnieuw gesloten en

kan het door middel van onderstaande code naar de gebruiker gestuurd worden:

header('Content-Description: File Transfer');

header('Content-Disposition: attachment; filename='.basename($txtfile));

header('Content-Transfer-Encoding: binary');

header('Expires: 0');

header('Cache-Control: must-revalidate, post-check=0, pre-check=0');

header('Pragma: public');

header('Content-Length: ' . filesize($txtfile));

ob_clean();

flush();

readfile($txtfile);

exit;

Initieel hadden we moeilijkheden met de feitelijke overdracht naar de gebruiker. Het was niet

onmiddellijk duidelijk hoe men binnen CakePHP het aangemaakte bestand kon overzetten naar de

gebruiker. Via de website PHP.net [4] werd bovenstaande oplossing gevonden. De functies

ob_clean() en flush() zorgen ervoor dat de output buffer bij elke downloadoperatie geleegd wordt.

4.5. Flowcharts

4.5.1. Inleiding

Een duidelijk gebrek bij de oude werkwijze is dat er geen direct verband gelegd wordt tussen de

verschillende video’s. Men kan de herkomst van een bewerkte video wel terugvinden doordat men

strikte naamconventies toepast bij het benoemen van mappen en video’s. Om de gebruikte



algoritmes terug te vinden, moet men de XML-bestanden raadplegen. Het is met andere woorden

niet vanzelfsprekend om op een efficiënte manier onderliggende verbanden te identificeren, laat

staan het te visualiseren. Een wens van de onderzoekers is dan ook om het mogelijk te maken de

onderlinge verbanden visueel voor te stellen. Teneinde dit te kunnen realiseren, worden binnen de

database flowcharts gegenereerd. Deze tonen de volledige weg die een video afgelegd heeft met

bijhorende methode en parameters. Om dergelijke grafische voorstelling te kunnen opstellen, werd

in punt 3.3. de tabel flowcharts aangemaakt. Deze tabel duidt per flowchartelement een source

video en een sink video aan. Beide vreemde sleutels verwijzen naar een video uit de tabel videos. Een

derde vreemde sleutel, method_id, verwijst naar de gebruikte methode bij de omzetting. Ten slotte

is er het attribuut parameters welke de gebruikte parameters opslaat. Deze informatie kan gebruikt

worden om flowcharts te genereren. Dit punt kan in twee onderdelen opgesplitst worden. In het

eerste deel wordt het ingeven van de flowchartdata besproken. We merken op dat er een verschil

bestaat tussen de verwerking van flowcharts voor bewerkte video’s en de verwerking voor

*Sequentie_naam+.out video’s. In het volgende deel worden de visuele weergave van flowcharts

besproken.

4.5.2. Ingeven van flowchartdata

Zoals aangehaald in punt 4.3.5. krijgt de gebruiker na het toevoegen van een bewerkte video of een

[Sequentie_naam].out video onmiddellijk een nieuw formulier voorgeschoteld. Bij bronvideo’s slaat

men deze stap over, omdat deze zich onderaan de hiërarchie bevinden. In het geval van bewerkte

video’s krijgt men een formulier waarbij de sink, namelijk de net toegevoegde video, en de source

automatisch ingevuld worden. De source video kan gemakkelijk afgeleid worden uit de cam*.out

map waarbinnen de sink video zich bevindt. Een voorbeeld kan dit verduidelijken: een source video

binnen de map cam03.out van een bepaalde sequentie is steeds afkomstig van de bronvideo

cam03.avi binnen dezelfde sequentie. Het vinden van de juiste vreemde sleutels voor sink_id en

source_id gebeurt binnen de video controller bij het toevoegen van de ontdekte video. Na het

opslaan van de gedetecteerde video in de database, kan men eenvoudig de sink video vinden door

de primaire sleutel van de laatst toegevoegde video te zoeken met onderstaande code:

$sinkid=$this->Video->find('first', array('order' => array('Video.id DESC')));

CakePHP kent geen find()-functie om het laatst toegevoegde element te vinden. Dit probleem kan

gelukkig snel opgelost worden door de video’s op basis van hun primaire sleutel van groot naar klein

te rangschikken. Zo kunnen we het eerste element, namelijk deze met de grootste primaire sleutel,

selecteren. Voor de source video wordt er binnen alle video’s van de specifieke sequentie gezocht

naar een video met een bepaald path en de respectievelijke primaire sleutel doorgegeven. Omdat er



steeds met dezelfde mappenstructuur gewerkt wordt, kan men op voorhand het path van de

bronvideo voorspellen.

De overige velden, namelijk de methode en bijhorende parameters, moeten door de gebruiker

ingevuld worden. Deze kunnen niet gedetecteerd worden op basis van de informatie binnen de

mappenstructuur. De gebruiker kan door middel van een drop-down list een keuze maken uit de

methoden die zich binnen de database bevinden. Afhankelijk van de gemaakte keuze verschijnen de

bijhorende parameters. Binnen de database worden de parameters opgeslagen als een

geserialiseerde JSON-string. Dit houdt echter in dat we niet kunnen steunen op de

validatiefunctionaliteiten van CakePHP. Om deze reden voorzien we zelf validatieregels met het

gebruik van JavaScript. Het aanmaken en gebruik van methoden wordt in punt 4.6.2. uitvoerig

besproken. Het is ook belangrijk dat de gewenste methode reeds aanwezig is in de database voordat

men overgaat tot documenteren. Indien dit niet het geval is, zal deze methode niet in de keuzelijst

van het formulier verschijnen. Na het invullen van het flowchart formulier is het toevoegen van de

video compleet.

De [Sequentie_naam].out video’s verschillen deels met bovenstaande werkwijze. Er wordt gefocust

op de verschillen. Het flowchart formulier bevat een nieuw veld, namelijk ‘Number of source videos’.

Hierin kan de gebruiker het aantal video’s ingeven die als source moeten dienen. We zagen in de

XML-bestanden dat de parameters en de methode gelijk bleven voor alle source video’s. Om deze

reden laten we de gebruiker meerdere source video’s kiezen en slechts eenmaal een set parameters

invullen. Na het klikken op de submit knop, wordt de data doorgestuurd naar de flowchart controller.

De functie adjust_flow() zet eerst de verstuurde data om in het gevraagde formaat om door te

kunnen geven aan CakePHP, aangezien we gebruik willen maken van de saveAll()-functie binnen

CakePHP. Het vereiste formaat is als volgt [21]:

Array([Flowchart] => Array(

[0] => Array([sink_id] => 5, …)

[1] => Array([sink_id] => 5, …)

…))

Het omzetten van de data is nodig, omdat CakePHP louter de inhoud van het formulier doorstuurt.

Door middel van een for-lus op basis van het aantal source video’s wordt de informatie in een lijst

van bovenstaande vorm gegoten met telkens een verschillende source_id. De overige velden blijven

gelijk. Na deze stap wordt deze lijst doorgestuurd naar de saveAll()-functie:

$this->Flowchart->saveAll($data)



Een nadeel van onze werkwijze is dat een onderzoeker niet verplicht wordt om de flowchart

informatie in te vullen. Hij kan immers een andere webpagina aanklikken of zijn browservenster

sluiten. Omdat deze website intern gebruikt zal worden, kunnen we rekenen op de goede wil van de

onderzoekers. Men zou immers op deze manier het eigen werk ondermijnen.

4.5.3. Visuele weergave van flowcharts

De flowchart informatie, ingegeven door de gebruiker, zal niet worden gebruikt om in tabellen weer

te geven, zoals dit voor bijvoorbeeld sequenties wel het geval is. De informatie wordt gebruikt als

ruggengraat voor de visuele weergave van flowcharts. Op deze manier hoeven onderzoekers niet

langer manueel op zoek te gaan naar onderlinge verbanden of door vele video’s zoeken. Door middel

van een visuele weergave van de onderlinge verbanden krijgt de gebruiker onmiddellijk inzicht in de

afhankelijkheden tussen video’s. De pijlen die video’s met elkaar verbinden geven onmiddellijk de

gebruikte methode en parameters weer. Bovendien kan men op de video’s klikken, zodat men snel

bijkomende informatie kan vergaren. Onderstaande schermafbeelding geeft een voorbeeld van een

flowchart weer:

Figuur 8: Schema flowchart. Figuur aangemaakt in SmartDraw [15].

De flowcharts worden gegenereerd met jsPlumb [22], een uitbreiding van JQuery voor het maken

van diverse flowcharts. Een video wordt voorgesteld door een rechtboek met erin een hyperlink naar

de overzichtspagina voor die video. De pijlen geven de richting aan van het verband en de bijhorende

parameters. De opmaak van de flowchart wordt in JQuery opgesteld. Omdat niet elke flowchart

evenveel niveau’s of video’s telt, wordt deze JQuery-functie in PHP gegenereerd door middel van een

for-lus waarbinnen elke rechthoek als een <div> gedefinieerd wordt en de connecties tussen deze



<div>’s opgesteld wordt binnen de JQuery-functie. Bij het ontwikkelen van deze visuele weergave

kwamen we het probleem tegen dat de flowchart afhankelijk van de schermgrootte niet correct

weergegeven werd. Zo kwam het bij kleinere schermen voor dat de flowchart deels de overige tekst

overlapte. Dit werd opgelost door de elementen van de flowchart, namelijk de rechthoeken, binnen

een overkoepelende <div> te plaatsen en onderstaande JQuery-code te gebruiken:

jsPlumb.draggable($(".window"),{ containment: 'parent' });

Deze code maakt dat de gebruiker de rechthoeken kan verslepen om, indien gewenst, de lay-out van

de flowchart te veranderen. Men kan de rechthoeken echter niet buiten de overkoepelende <div>

verslepen, zodat er ook geen overlapping kan bestaan met de bovenstaande tekst of tabel.

4.6. Methoden

4.6.1. Inleiding

Momenteel voegen de onderzoekers bij het documenteren hun parameters en methode manueel in.

Dit heeft echter als gevolg dat het mogelijk is dat men bepaalde parameters vergeet toe te voegen.

Vanuit de begeleiders kwam de vraag om er rekening mee te houden dat er in de toekomst nieuwe

methoden toegevoegd moeten worden. Dit heeft als gevolg dat deze methoden niet hard gecodeerd

mogen worden. Men moet een dynamische oplossing vinden om methoden te kunnen toevoegen en

bovendien de nodige validatie te voorzien. Er kan namelijk niet langer gerekend worden op de

validatiemogelijkheden binnen CakePHP, omdat de parameters zelf niet langer deel uitmaken van

het model. Teneinde het toevoegen van nieuwe methoden mogelijk te maken, werd een aparte tabel

methods aangemaakt met de methodenaam en parameters als attributen. De parameters worden als

geserialiseerde JSON in de database bijgehouden en dus opgeslagen als string. Onderstaand

voorbeeld toont de JSON-notatie:

$json = '{"Param1":"num", "Param2" :"string","Param3":"bool"}'

Binnen deze notatie worden alle parameters en hun datatype bijgehouden. Dit laatste is belangrijk

omdat het datatype bij het toevoegen van flowcharts gebruikt wordt voor de validatie van

inputvelden. Men kan in ons geval namelijk niet steunen op de validatiemogelijkheden van CakePHP.

Dit zou inhouden dat we binnen het FlowchartModel de variabelen moeten definiëren en valideren.

Het gevolg hiervan is dat de gebruiker telkens de code zou moeten aanpassen na het toevoegen van

een nieuwe methode. Teneinde het toevoegen van methoden zo gebruiksvriendelijk mogelijk te

houden vanuit het standpunt van de gebruiker, passen we een alternatieve wijze toe. Het volgende

onderdeel start met het beschrijven van het toevoegen van methoden, vervolgens wordt er dieper

ingegaan op de validatie op basis van de tabel methods bij het aanmaken van flowchart data.



4.6.2. Toevoegen van methoden

Het toevoegen van nieuwe methoden verloopt via een formulier met twee velden, namelijk de naam

van de methode en het aantal parameters. Van zodra men een waarde ingeeft en op de TAB-toets

drukt, krijgt de gebruiker twee velden per parameter. Het eerste veld laat toe een naam voor een

parameter in te geven, terwijl de drop-down list het datatype vastlegt. De gebruiker heeft de keuze

tussen de datatypes number, boolean of string. Naargelang het gekozen type zullen er bij het

toevoegen van flowcharts bepaalde validatieregels gelden.

Figuur 9: Voorbeeld ingeven van een parameter.

Na het invullen van de gewenste parameters en het drukken op de submit knop wordt alle data

doorgestuurd naar de methods controller. Deze verwerkt de ontvangen data en plaatst de

verschillende parameters met hun bijhorende datatypes in een lijst. Deze lijst wordt op zijn beurt als

input gebruikt voor de PHP-functie json_encode():

$n['Method']['parameters'] = json_encode($prep);

Json_encode() zet een gegeven rij om naar een JSON-string. Na deze stap kan alle verstuurde

informatie opgeslagen worden via de gebruikelijke save()-functie van CakePHP.

4.6.3. Validatie bij toevoegen flowcharts

De tabel flowcharts kent eveneens een attribuut parameters. Deze bevat de eigenlijke parameters

die bij een bepaalde methode gebruikt zijn. Ook deze parameters worden als een JSON-string

bijgehouden, om dezelfde reden: het mogelijk maken om dynamisch methoden toe te voegen. Indien

men bijvoorbeeld maximum 5 parameters zou mogen opgeven (hard gecodeerd in de database),

zouden er problemen optreden indien men een methode met 6 parameters wenst op te slaan. Het

gebruik van een JSON-string stelt geen limieten op het aantal parameters.

Het formulier om flowchart data toe te voegen wordt dynamisch aangemaakt op basis van de

methoden aanwezig in de database. Het is dus voor de gebruiker belangrijk om voor het toevoegen

van nieuwe data te zorgen dat de lijst met methoden up-to-date is. Bij het aanspreken van de

webpagina om flowchart data toe te voegen worden voor alle parameters van alle methoden velden

aangemaakt op basis van hun datatypes. Booleaanse parameters krijgen een checkbox, terwijl

parameters met datatype string of number een invulveld krijgen. Deze velden blijven echter allemaal

verborgen tot de gebruiker een methode uit een drop-down list selecteert. Door middel van



JavaScript maken we de <div> van de gekozen methode zichtbaar. Indien de gebruiker toch een

andere methode wenst te selecteren, verbergt de website opnieuw de vorige en toont het de

nieuwe. Op deze manier krijgt de gebruiker steeds één set van parameters te zien.

De validatie van de ingevulde parametervelden gebeurt analoog. Na het drukken op de submitknop

wordt de ingevulde informatie via JavaScript eerst naar een validatiefunctie gestuurd. Deze functie

wordt bij het openen van de webpagina in PHP gegenereerd. Voor elke methode wordt, indien een

parameter het datatype string of number heeft, een validatieregel opgesteld. Parameters met het

Booleaanse datatype vereisen geen controle, omdat hun waarde door het gebruik van een checkbox

automatisch 1 of 0 wordt. Onderstaande code geeft de algemene validatiecontrole voor

respectievelijk getallen en strings (y is de variabele dat het datatype voorstelt):

if (y == "" || isNaN(y) || y == null) {…} //validatie voor number

if (y == "" || y == null) {…} //validatie voor string

Bij getallen wordt er gekeken of de waarde effectief ingevuld is en of de ingevulde waarde numeriek

is. Komma- en negatieve getallen zijn hierbij toegelaten. Merk op dat men een punt moet gebruiken

bij kommagetallen. Ten slotte controleert de functie of de waarde niet ongeldig is. Bij strings

doorloopt men dezelfde controle, zonder de functie isNaN(). Bij de start van deze validatiefunctie

wordt gekeken naar de geselecteerde methode, zodat enkel de nodige validatieregels per methode

doorlopen worden. Om het de gebruiker nog gemakkelijker te maken wordt bij het ontdekken van

een fout de cursor automatisch in het betreffende veld geplaatst.

Het nadeel van deze werkwijze is dat gebruikers bewust JavaScript kunnen uitschakelen of dat

browsers in de toekomst bepaalde JavaScript-functies niet langer ondersteunen. Bij het ontwikkelen

werd er aandacht besteed om het zowel in Internet Explorer, Firefox als Chrome te doen werken.

Vooral Firefox blijkt strenge eisen te stellen aan de gebruikte syntax. Het probleem van gebruikers

die JavaScript uitschakelen zal zich hier niet stellen. De website is voor intern gebruik en om deze

reden kan men erop rekenen dat de gebruikers zonder kwade bedoelingen met deze website

werken. Men zou immers het eigen werk ondermijnen indien men JavaScript uitschakelt. Een tweede

schijnbaar nadeel van deze werkwijze is dat er veel code gegenereerd wordt waarvan slechts een

klein deel gebruikt wordt. Dit klopt, maar we wensen erop te wijzen dat er slechts één query gebruikt

wordt voor het inladen van de methoden. Het overige is het aanmaken van de code, wat heel snel

gebeurt en dus geen tot weinig impact heeft op de performantie van de webpagina.



4.7. Authenticatie

Ter afscherming van de data wordt een authenticatiesysteem opgezet. Hiervoor werden er eerder de

nieuwe tabellen users en groups aangemaakt (punt 3.4.2.). Bij het opstellen van dit

authenticatiesysteem werd de uitstekende tutorial op CakePHP.org gebruikt [23]. Deze demonstreert

stap voor stap het installeren van een authenticatiesysteem op een generieke website. Uiteraard

vergt het toepassen van deze tutorial op de website meer werk.

Vertrekkende van bovenstaande tabellen kan men het ‘cake bake’-commando uitvoeren om

automatisch een model, controller en de nodige views te genereren. Deze vormen het vertrekpunt

voor de tutorial. Binnen de user controller worden de login()- en logout()-functies aangemaakt als

lege functies. Initieel worden deze nog niet ingevuld, omdat men het authenticatiesysteem op een

moment naar keuze wenst in te schakelen. Voor de loginfunctie wordt onmiddellijk een loginpagina

aangemaakt, waarop de gebruiker later kan inloggen. Deze pagina heeft dezelfde code als een

standaard formulier aangemaakt met de CakePHP HtmlHelper. Doordat de loginfunctie binnen de

AuthComponent als de te gebruiken loginfunctie vermeld zal worden, zal CakePHP automatisch het

wachtwoord verbergen bij het inloggen. Het wachtwoord wordt vervolgens door middel van SHA1

geëncrypteerd en kan dus niet gelezen worden door bijvoorbeeld een administrator. Het definiëren

van de loginfunctie binnen de AuthComponent gebeurt binnen de AppController. Deze moet eerst

aangemaakt worden en binnen de /app-directory geplaatst worden, in tegenstelling tot andere

controllers die zich binnen de /app/controllers-directory bevinden. De complete code van de

AppController vindt u in bijlage 6.6. Na het aanmaken van de AppController gebruiken we opnieuw

de CakePHP console om het commando ‘cake schema create DbAcl’ uit te voeren en Access Control

Lists (ACL) aan te maken door middel van drie nieuwe tabellen. Deze tabellen zullen zorgen voor de

concrete werking van het authenticatiesysteem en controleren of een ingelogde gebruiker rechten

heeft tot een bepaalde actie of pagina. Om onze groep aan de ACL-tabellen te linken, moet men nog

een parentNode()-functie aan beide modellen toevoegen. We kunnen hiervoor dezelfde functie

gebruiken als deze uit de tutorial, aangezien we permissies op het niveau van de groepen gaan

definiëren.

Na dit voorbereidend werk kan er gefocust worden op de specifieke groep die we wensen te

definiëren, namelijk administrators. Om permissies op het niveau van groepen te kunnen definiëren

wordt de functie bindNode() uit de tutorial toegevoegd zonder verdere aanpassingen. Om het

permissiesysteem op te zetten, moeten alle controllers en diens functies opgenomen worden in de

Access Control Objects (ACO)-tabel. CakePHP biedt hiervoor een automatische tool aan onder de

vorm van een script [23]. Dit script kan als een gewone functie uitgevoerd worden door het binnen



een willekeurige controller te plaatsen. Na het uitvoeren van dit script zijn we aangekomen bij de

laatste stap, namelijk het toekennen van permissies aan de administrators. Dit wordt gedaan door

wederom een script uit te voeren, zie bijlage 6.7. Als laatste worden de functies login() en logout()

ingevuld, opdat het authenticatiesysteem volledig zou werken.

De toegekende permissies werden reeds besproken in punt 4.1.2. Elke administrator kan nieuwe

gebruikers aanmaken vanuit de homepage. Bij het invulformulier om een nieuwe gebruiker aan te

maken, hebben we ervoor gekozen om een extra controle in te bouwen met betrekking tot de ingave

van het passwoord. Zoals gebruikelijk op vele websites wordt er gevraagd om het wachtwoord

tweemaal in te geven, opdat men zeker zou zijn dat de gebruiker geen typefouten maakt. De

administrator heeft ook toegang tot de gebruikerslijsten en eventueel gebruikers te verwijderen. Elke

gebruiker kan via het menu User > Change password zijn passwoord veranderen. Teneinde het

onmogelijk te maken alle gebruikers te wissen (inclusief de eigen account), wordt ervoor gezorgd dat

men de originele adminaccount niet kan verwijderen. Het verwijderen van gebruikers wordt niet

beschermd met een extra Booleaans attribuut deleted. We wensen het herstellen van verwijderde

items te beperken tot kerntabellen die tot de essentie van deze website behoren, namelijk het

documenteren van recordings, sequenties, video’s en gerelateerde tabellen.

4.8. Moeilijkheden bij de ontwikkeling

Bij het ontwikkelen van de website kwamen we een aantal moeilijkheden tegen. Een eerste

moeilijkheid was het aanleren van de CakePHP syntax. Het werken in CakePHP was onze eerste

ervaring met het werken binnen een framework. Dit had als gevolg dat er initieel moeilijkheden

waren om de syntax onder de knie te krijgen en de filosofie achter de MVC-architectuur correct toe

te passen. Het heeft een tweetal weken geduurd vooraleer we het gevoel hadden de werking van

CakePHP voldoende onder de knie te hebben. Een tweede moeilijkheid, namelijk de wijze waarop

CakePHP met HABTM-relaties omgaat werd onder punt 4.4.3. eerder besproken. Het leren omgaan

met de mogelijkheden en de limieten van het framework was dan ook de voornaamste uitdaging van

deze masterproef.

Bij het een eerste keer online plaatsen van de website hadden we eveneens problemen. Het

opstellen van CakePHP binnen de verkregen webruimte, verliep initieel niet vlot. Om de website

werkend te krijgen, werden de .htaccess-bestanden binnen de webserver, de app-map en de

app/webroot-map aangepast om de gebruikers via de correcte route naar de website te leiden.

Verder was het van belang om ervoor te zorgen dat de webroot niet enkel read-only was. Bij het

downloaden van een bestand, wordt eerst het bestand output.txt aangemaakt, waardoor er dus



schrijftoegang nodig is tot de webroot. Hetzelfde geldt voor de database. Zonder schrijfrechten kan

men geen nieuwe video’s toevoegen aan de database.

Een laatste moeilijkheid was het toevoegen van een afbeeldingengalerij of het afspelen van een

video binnen de website. Door CSS [24] en Lightbox [25] te combineren was het mogelijk om op een

individuele pagina van een video een fotogalerij te tonen indien een map .png-bestanden bevat.

Indien er sprake van een .avi-video is, wordt door middel van de <embed>-tag de video binnen de

website afspeelbaar. Hierbij is het probleem dat de webserver geen toegang heeft om bestanden te

openen op de client, omwille van beveiligingsredenen. Indien een gebruiker via de webserver

toegang zou hebben tot afbeeldingen op een lokale server, zou hij dit kunnen gebruiken om toegang

te verkrijgen tot andere documenten van de client. Om deze reden wordt dit standaard geblokkeerd

binnen browsers. Teneinde dit probleem op te lossen ontvingen we van Dirk Van Haerenborgh een

PHP-script om (tijdelijk) toegang tot afbeeldingen en video’s te verschaffen. Dit proxy script kan u in

bijlage 6.8. vinden. Hierdoor kan men op de individuele pagina van een video toch een aantal

representatieve afbeeldingen of het videobestand zelf raadplegen. Omwille van de grootte van de

videobestanden (ongeveer 1,5 GB per video) verloopt het afspelen uiteraard minder vlot dan het

rechtstreeks binnen de directory te openen.



5. Conclusie

Tot voor kort werkte de onderzoeksgroep IPI met XML-bestanden en een eenvoudige PHP-

gegenereerde website om experimentele multicameravideo’s te beheren. Deze werkwijze had tot

gevolg dat het beheer op termijn onhoudbaar zou worden. Deze masterproef biedt een oplossing

door een website binnen het CakePHP framework te ontwikkelen voor het beheer van deze video’s.

Deze masterproef vangt aan met het ontwikkelen van een relationele database aan de hand van drie

stappen. In een eerste ronde wordt er informatie verzameld over de te ontwerpen database en de

bijhorende website. Vervolgens wordt een EER-diagram ontwikkeld om de database logisch voor te

stellen. De laatste stap zet dit EER-diagram om naar een databaseschema aan de hand van een

algoritme en voegt een aantal extra tabellen toe in functie van het CakePHP authenticatiesysteem.

Deze website vereenvoudigt het documenteerwerk van onderzoekers aanzienlijk door tal van nieuwe

functionaliteiten. Op basis van de bestaande multicamera directorystructuur werd een

detectiesysteem ontwikkeld. De gebruiker kan op een moment naar keuze deze directory scannen

om een lijst van toe te voegen items te genereren. Hierbij worden automatisch een aantal

elementen, zoals de naam en path automatisch ingevuld. Bovendien wordt het mogelijk gemaakt om

de herkomst van video’s te documenteren. Dit gebeurt deels automatisch. Op basis hiervan wordt

per video een grafische flowchart gegenereerd, welke het voor de onderzoeker mogelijk maakt om

eenvoudig de herkomst van een video tot aan zijn bronvideo(‘s) op te sporen. Elke video wordt op

een individuele pagina weergegeven met een afbeeldingengalerij of de video zelf, indien mogelijk.

Ook nieuw is de mogelijkheid om te zoeken op basis van een string of aan de hand van tags. De

zoekresultaten kunnen op hun beurt als .txt-bestand gedownload worden om verder te verwerken in

Excel. Waar nuttig worden de data ondersteund door een visuele presentatie als een flowchart of

een grafiek.

Er werden twee gebruikersprofielen gedefinieerd. De onderzoekers krijgen een administratoraccount

welke hen toegang verschaft tot alle mogelijkheden van de website. Naast dit profiel wordt een

tweede profiel, de anonieme gebruiker, toegevoegd. Anonieme, niet-ingelogde gebruikers, kunnen

vrij informatie raadplegen, opzoeken en downloaden. Deze account kan de data niet wijzigen. Ten

slotte is er ook naar de toekomst gekeken door het mogelijk te maken nieuwe methoden toe te

voegen. Deze methoden worden onmiddellijk opgenomen in het formulier om flowcharts te

documenteren met de nodige validatie ter controle.

Het ontwikkelen van een website is een proces dat nooit klaar is. Om deze reden hebben we nog een

aantal suggesties om deze website verder aan te vullen.



Een eerste suggestie betreft de lay-out van de website. Gezien onze beperkte kennis van CSS

vertrokken we van de standaard lay-out van CakePHP, omdat we deze reeds overzichtelijk

vonden. Desondanks hebben we geprobeerd een eigen toets aan deze website te geven.

Iemand met meer CSS- en JQuery-ervaring kan ongetwijfeld deze website verder verfraaien.

De huidige website voldoet aan de gestelde vereisten voor deze masterproef, maar indien

we naar de workflow van de gebruikers kijken kan dit nog verder geoptimaliseerd worden

door meerdere video’s tegelijk toe te voegen. Momenteel moet men video per video

documenteren, sommige van deze video’s vertonen een aantal gemeenschappelijke

kenmerken waarvan men zou kunnen profiteren bij het uitbreiden van deze website. Zo zou

men bij detectie van een video binnen een cam01.out map, automatisch diezelfde video

kunnen toevoegen voor de overige cam*.out mappen. Hierbij maken we wel de

veronderstelling dat de parameters gelijk blijven en de video’s in elke cam*.out map

geplaatst worden. Uit de praktijk blijkt dat deze voorwaarden inderdaad aanwezig zijn.

Een laatste mogelijk uitbreiding die we zien is het ontwikkelen van een API waarmee

onderzoekers vanuit hun programma’s rechtstreeks de database kunnen aanvullen. De

website zou dan hoofdzakelijk dienen voor visuele weergave van de data,

zoekfunctionaliteiten en het manueel toevoegen, indien nodig.


Arvid Bouters, Joris D’hont V

6. Bijlagen

6.1. Handleiding

Deze korte handleiding bespreekt de voornaamste functionaliteiten van de website. Er wordt

afgesloten met een overzicht welke zaken men moet aanpassen indien men de website in een

nieuwe server plaatst.

Men kan een nieuwe gebruiker toevoegen via homepage > admin tools > add a new user.

Een nieuwe methode toevoegen kan via homepage > admin tools > add new method of via het menu

Method > New method. Na het invullen van het aantal parameters drukt men op TAB en het

gewenste aantal parameters verschijnt met bijhorende datatypes. Een bestaande methode kan

gewijzigd worden, al wordt dit niet aangeraden. Het zou immers impact kunnen hebben op de

bestaande flowchart data indien men bijvoorbeeld het datatype aanpast.

Nieuwe recordings, sequenties en video’s toevoegen, vereist dat de gebruiker eerst de

respectievelijke mappen en video’s binnen de multicameradirectory plaatst. Deze website baseert

zich op de bestaande structuur en conventies, waardoor het belangrijk is dat men deze correct blijft

volgen. Vervolgens kan men via homepage > admin tools > check for updates of via het menu Home >

Check updates een lijst genereren met alle toe te voegen elementen. Door op een hyperlink te

klikken komt u in het invulformulier. Voor recordings kan de gebruiker kiezen of hij calibratie-info

toevoegt. Indien hij dit niet wenst te doen, laat hij de velden ‘Calibration Method’ en ‘Calibration

Notes’ leeg. Dit kan, indien gewenst, later aangevuld worden door middel van de editfunctie voor

recordings. Toevoegen van sequenties verloopt gelijkaardig. Men kan hierbij ook nieuwe tags

toevoegen door deze in te geven, gescheiden door het teken ‘;’.

Video’s toevoegen verloopt gelijkaardig. Indien het geen bronvideo betreft, volgt er een tweede

formulier om de link met een andere video te leggen. Bij [Sequentie_Naam].out-video’s duidt de

gebruiker zelf aan hoeveel bronvideo’s er zijn en kiest deze uit de lijst. In het andere geval wordt

zowel de sink als source automatisch aangevuld. Kijk voor alle zekerheid na of deze correct zijn.

Flowcharts raadplegen kan op de individuele pagina van video’s.


Arvid Bouters, Joris D’hont VI

Deze website vereist een aantal aanpassingen teneinde deze volledig functioneel te maken bij het

overplaatsen naar een nieuwe webserver. Het gaat hier om de website naam die op sommige

plaatsen hard gecodeerd staat. Momenteel draait de website op de webruimte van

‘~dvhaeren/multicamera’. Indien dit gewijzigd moet worden, moet de naam bovenaan de volgende

pagina’s vervangen worden door de nieuwe naam van de webruimte:

App/views/videos/search_tags.ctp

App/views/videos/view.ctp

App/views/sequences/search_tags.ctp

App/views/recordings/index.ctp

App/views/recordings/view.ctp

App/views/recordings/search.ctp

App/views/layouts/default.ctp

App/webroot/js/lightbox.js

Om ervoor te zorgen dat de website de juiste webroot neemt, moet in elke .htaccess file de volgende

regel toegevoegd worden:

RewriteBase /~[naamwebruitme]

Na deze aanpassingen moeten nog rechten van de map app/tmp en de map app/webroot aangepast

worden, zodat de website kan schrijven naar de cache en naar het SQLite bestand. De laatste stap is

binnen app/controllers/home_controller.php het path van de te scannen directory in te geven bij de

functie update_page().


Arvid Bouters, Joris D’hont VII

6.2. Omzetting EER-diagram

Binnen onderstaande (tussen)resultaten van het omzettingsalgoritme worden primaire sleutels

onderlijnd met een volle lijn, vreemde sleutels met een stippellijn.

1) Omzetting van reguliere entiteittypes:

recordings(id, name, date, description, notes, author, sequence_count, deleted)

sequences(id, name, directory, description, cameras, timesynchronised, video_count, deleted)

videos(id, path, description, author, fps, resolution, date, deleted)

calibrations(id, calibrationDirectory, calibrationMethod, calibrationNotes, deleted)

tags(id, name, deleted)

methods(id, name, parameters, deleted)

2)Omzetting van binaire één-op-één relatietypes

recordings(id, calibration_id, name, date, description, notes, author, sequence_count, deleted)

3) Omzetting van binaire één-op-meerdere relatietypes

sequences(id, recording_id, name, directory, description, cameras, timesynchronised, video_count,

deleted)

videos(id, sequence_id, path, description, author, fps, resolution, date, deleted)

4) Omzetting van binaire meerdere-op-meerdere relatietypes

videos_tags(id, video_id, tag_id)

sequences_tags(id, sequence_id, tag_id)

5) Omzetting van ternaire relatietypes

flowcharts(id, sink_id, source_id, method_id, parameters, deleted)

Vreemde sleutels sink_id en source_id verwijzen naar de tabel videos.


Arvid Bouters, Joris D’hont VIII

6.3. Script SQLite

PRAGMA foreign_keys = ON; create table calibrations (

id integer primary key, calibrationDirectory varchar, calibrationMethod varchar, calibrationNotes varchar, deleted boolean default false

); create table methods (

id integer primary key, name varchar, parameters varchar, deleted boolean default false

); create table recordings (

id integer primary key, name varchar, date datetime, description varchar, notes varchar, calibration_id integer, author varchar, sequence_count integer, deleted boolean default false, foreign key (calibration_id) references calibrations(id) on delete cascade

); create table sequences (

id integer primary key, name varchar, directory varchar, description varchar, cameras integer, timesynchronised boolean, recording_id integer not null, video_count integer, deleted boolean default false, foreign key (recording_id) references recordings(id) on delete cascade

); create table videos (

id integer primary key, path varchar, description varchar, author varchar, sequence_id integer not null, fps integer, resolution varchar, date datetime, deleted boolean default false, foreign key (sequence_id) references sequences(id) on delete cascade

);


Arvid Bouters, Joris D’hont IX

create table flowcharts (

id integer primary key, sink_id integer not null, source_id integer not null, method_id integer not null, parameters varchar, deleted boolean default false, foreign key (sink_id) references videos(id) on delete cascade, foreign key (source_id) references videos(id) on delete cascade, foreign key (method_id) references methods(id) on delete cascade

); create table tags (

id integer primary key, name varchar, deleted boolean default false

); create table videos_tags (

id integer primary key, video_id integer, tag_id integer, foreign key (video_id) references videos(id) on delete cascade, foreign key (tag_id) references tags(id) on delete cascade

); create table sequences_tags (

id integer primary key, sequence_id integer, tag_id integer, foreign key (sequence_id) references sequences(id) on delete cascade, foreign key (tag_id) references tags(id) on delete cascade

); CREATE TABLE users (

id integer PRIMARY KEY, username varchar NOT NULL, password varchar NOT NULL, group_id integer NOT NULL, created DATETIME, modified DATETIME

); CREATE TABLE groups (

id integer PRIMARY KEY, name varchar NOT NULL, created DATETIME, modified DATETIME

);


Arvid Bouters, Joris D’hont X

6.4. Uitwerking ‘ISA’-relatie

Onderstaande voorbeelden illustreren het omzetten van een ‘ISA’-relatie naar een databaseschema.

1) Verschillende basisrelaties, voor het supertype en de subtypes

flowcharts(id, parameters, deleted)

methodX(id, param X1, param X2, param X3)

methodY(id, param Y1, param Y2, param Y3)

…

Voor elke methode is de primaire sleutel tevens een vreemde sleutel naar de tabel flowcharts.

2) Verschillende basisrelaties, enkel voor de subtypes

methodX(id, param X1, param X2, param X3, parameters)

methodY(id, param Y1, param Y2, param Y3, parameters)

…

3) Eén basisrelatie met één typeattribuut

flowcharts(id, param X1, param X2, param X3, param Y1, param Y2, param Y3, type, deleted)

Het datatype van type is Boolean.

4) Eén basisrelatie met meerdere typeattributen

flowcharts(id, param X1, param X2, param X3, param Y1, param Y2, param Y3, methodX, methodY,

deleted)

Het datatype van methodX en methodY is Boolean.


Arvid Bouters, Joris D’hont XI

6.5. Structuur multicameradirectory


Arvid Bouters, Joris D’hont XII

6.6. App Controller

<?php class AppController extends Controller { var $components = array('Acl', 'Auth', 'Session'); var $helpers = array('Html', 'Form', 'Session'); function beforeFilter() { //Configure AuthComponent $this->Auth->authorize = 'actions'; $this->Auth->loginAction = array('controller' => 'users', 'action' => 'login'); $this->Auth->logoutRedirect = array('controller' => 'users', 'action' => 'login'); $this->Auth->loginRedirect = array('controller' => 'home', 'action' => 'index'); } } ?>


Arvid Bouters, Joris D’hont XIII

6.7. Script permissies

function initDB() { $group =& $this->User->Group; //Allow admins to everything $group->id = 1; $this->Acl->allow($group, 'controllers'); echo "all done"; exit; }


Arvid Bouters, Joris D’hont XIV

6.8. Proxy script

<?php // define absolute path to image folder $image_folder = '//glfs/ipi/multiCamera/'; // get the image name from the query string // and make sure it's not trying to probe your file system //THIS IS INCREDIBELY UNSAFE!! (actually, a bit less by now) // && basename($_GET['pic']) == $_GET['pic'] if (isset($_GET['pic']) && (strpos($_GET['pic'], '/') != 0 || strpos($_GET['pic'], '../') != 0 )){ $pic = $image_folder.$_GET['pic']; if (file_exists($pic) && is_readable($pic)) { // get the filename extension $ext = substr($pic, -3); // set the MIME type switch ($ext) { case 'jpg': $mime = 'image/jpeg'; break; case 'gif': $mime = 'image/gif'; break; case 'png': $mime = 'image/png'; break; case 'avi': $mime = 'video/x-avi'; break; default: $mime = false; } // if a valid MIME type exists, display the image // by sending appropriate headers and streaming the file if ($mime) { header('Content-type: '.$mime); header('Content-length: '.filesize($pic)); $file = @ fopen($pic, 'rb'); if ($file) { fpassthru($file); exit; } } } } ?>


Arvid Bouters, Joris D’hont XV

Referenties

1. Van Hese, Peter. Multicamera presentatie. [Powerpoint] 2011.

2. Exforsys Inc. Server Side Scripting. 2011. [Cited: April 28, 2011.]

http://www.exforsys.com/tutorials/client-server/server-side-scripting.html.

3. Keel, S.A. What Is Server-Side Scripting? wiseGEEK. Februari 9, 2011. [Cited: April 28, 2011.]

http://www.wisegeek.com/what-is-server-side-scripting.htm.

4. The PHP Group. PHP.net. Mei 19, 2011. [Cited: Mei 12, 2011.] http://www.php.net/.

5. Wikipedia. CakePHP. Mei 20, 2011. [Cited: Mei 21, 2011.] http://en.wikipedia.org/wiki/CakePHP.

6. CakePHP.org. Understanding Model-View-Controller. CakePHP.org. 2011. [Cited: Mei 12, 2011.]

http://book.cakephp.org/view/890/Understanding-Model-View-Controller.

7. SQLite.org. 2011. [Cited: Maart 26, 2011.] http://www.sqlite.org/.

8. De Tré, Guy. Principes van databases. Principes van databases. Amsterdam : Pearson Education

Benelux bv, 2007.

9. Weldon, Graham. GitHub.com. November 20, 2010. [Cited: Maart 2011, 28.]

https://github.com/cakephp/datasources/blob/master/models/datasources/dbo/dbo_sqlite3.php.

10. Wikipedia. SQLite. Mei 23, 2011. [Cited: Mei 25, 2011.] http://en.wikipedia.org/wiki/SQLite.

11. JQuery. JQuery: The Write Less, Do More, JavaScript Library. 2010. [Cited: Mei 3, 2011.]

http://jquery.com/.

12. CakePHP.org. Model and Database Conventions. 2011. [Cited: Maart 30, 2011.]

http://book.cakephp.org/view/903/Model-and-Database-Conventions.

13. Golding, David. Beginning CakePHP: From Novice to Professional. Berkely, CA (United States) :

Apress, 2008.

14. CakePHP.org. The Manual. 2011. [Cited: April 5, 2011.] http://book.cakephp.org/.

15. SmartDraw. 2011. http://www.smartdraw.com/.

16. JavaScript Array. Simple Drop-Down Menu v2.0. 2010. [Cited: April 29, 2011.] http://javascript-

array.com/scripts/simple_drop_down_menu/.


Arvid Bouters, Joris D’hont XVI

17. Yahoo! Answers. How can I make link look like a button? 2005. [Cited: Mei 11, 2011.]

http://answers.yahoo.com/question/index?qid=1005120800200.

18. Shay, Xavier. TufteGraph. [Cited: Mei 10, 2011.] http://xaviershay.github.com/tufte-graph/.

19. Van Hese, Peter. Multicamera documentation. [PDF] s.l. : UGent, 2010.

20. WebTechNick.com. Juli 11, 2010. [Cited: April 23, 2011.]

http://www.webtechnick.com/wtn/blogs/view/237/HABTM_Search_By_Multiple_Tags_in_CakePHP.

21. CakePHP.org. Saving Your Data. 2011. [Cited: Mei 4, 2011.]

http://book.cakephp.org/view/1031/Saving-Your-Data.

22. Porritt, Simon. JsPlumb. [Online] 2011. [Cited: Mei 13, 2011.]

http://jsplumb.org/jquery/demo.html.

23. CakePHP.org. Simple ACL controlled Application. [Online] 2011. [Cited: Mei 19, 2011.]

http://book.cakephp.org/view/1543/Simple-Acl-controlled-Application.

24. W3 Schools. CSS Image Gallery. [Online] 2011. [Cited: Mei 13, 2011.]

http://w3schools.com/css/css_image_gallery.asp.

25. Dakhar, Lokesh. Lightbox 2. [Online] Maart 18, 2011. [Cited: April 18, 2011.]

http://www.huddletogether.com/projects/lightbox2/.

Dynamische website voor het beheren van experimentele...

Documents

Transcript of Dynamische website voor het beheren van experimentele...