Dynamische website voor het beheren van experimentele multicameravideo ing. Arvid Bouters, Joris D hont

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

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

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

I

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

II

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

III

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

IV

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

V

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

VI

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

VII

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

VIII

Dynamische website voor het beheren van experimentele multicameravideo

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 Arvid Bouters, Joris D’hont

1


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 XMLbestanden 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. Arvid Bouters, Joris D’hont

2


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.

Arvid Bouters, Joris D’hont

3


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. Arvid Bouters, Joris D’hont

4


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 Arvid Bouters, Joris D’hont

5


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 phpbestand.



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.


6


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 DataSourceArvid Bouters, Joris D’hont

7


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.


8


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 SQLitedatabase. 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 XMLbestanden 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 Arvid Bouters, Joris D’hont

9


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 XMLbestanden. 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 Arvid Bouters, Joris D’hont

10


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]. Arvid Bouters, Joris D’hont

11


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


12


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 Arvid Bouters, Joris D’hont

13


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:


14


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.


15


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 (SHA1encryptie) 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 PHPscript. 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 Arvid Bouters, Joris D’hont

16


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.


17


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 XMLbestanden 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 .txtbestand. 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.


18


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.


19


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.


20


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


21


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 CRUDfuncties. 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


22


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


23


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]. Arvid Bouters, Joris D’hont

24


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]. Arvid Bouters, Joris D’hont

25


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 Arvid Bouters, Joris D’hont

26


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 Arvid Bouters, Joris D’hont

27


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 Arvid Bouters, Joris D’hont

28


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 Arvid Bouters, Joris D’hont

29


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 .aviformaat, 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 Arvid Bouters, Joris D’hont

30


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. Arvid Bouters, Joris D’hont

31


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 plugins 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


32


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. Arvid Bouters, Joris D’hont

33


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.


34


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 Arvid Bouters, Joris D’hont

35


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:


36


$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.


37


$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 Arvid Bouters, Joris D’hont

38


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


39


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)


40


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
gedefinieerd wordt en de connecties tussen deze Arvid Bouters, Joris D’hont

41


’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
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
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.


42


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 Arvid Bouters, Joris D’hont

43


JavaScript maken we de
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.


44


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


45


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


46


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.


47


5. Conclusie Tot voor kort werkte de onderzoeksgroep IPI met XML-bestanden en een eenvoudige PHPgegenereerde 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.


48




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.


49


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.


V


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().


VI


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.


VII


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

VIII


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 );


IX


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.


X


6.5. Structuur multicameradirectory


XI


6.6. App Controller 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'); } } ?>


XII


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; }


XIII


6.8. Proxy script


XIV


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://javascriptarray.com/scripts/simple_drop_down_menu/. Arvid Bouters, Joris D’hont

XV


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/.


XVI

Dynamische website voor het beheren van experimentele multicameravideo ing. Arvid Bouters, Joris D hont

Recommend Documents