Handelswetenschappen en Bedrijfskunde Geel. Bachelor in de toegepaste informatica. Optie applicatieontwikkeling. Lekkers met Streken

Handelswetenschappen en Bedrijfskunde Geel Bachelor in de toegepaste informatica Optie applicatieontwikkeling

Lekkers met Streken Online inventaris van streekproducten, ontwikkeld in Kohana PHP

CAMPUS Geel

Lynn Penasse

Academiejaar 2011-2012

3

VOORWOORD In het derde jaar van mijn opleiding tot Bachelor in de toegepaste informatica heb ik dertien weken stage gelopen bij RURANT vzw in Geel. Dit eindwerk is een verslag van het werk dat ik tijdens deze stageperiode verricht heb. Dit verslag is in de eerste plaats gericht naar mijn docenten en de juryleden die mij op het einde van dit jaar zullen moeten beoordelen. Ik hoop dat het een duidelijk beeld geeft van mijn huidige niveau als informaticus. In de tweede plaats is dit verslag bedoeld voor de mensen bij RURANT en Toerisme Provincie Antwerpen, die in de toekomst zullen voortbouwen op het werk dat ik na mijn stageperiode opgeleverd heb. Het kan dienen als extra documentatie en bevat ook de redeneringen die aan bepaalde beslissingen voorafging. Hopelijk vormt het een goede ondersteuning bij hun werk. Ik wil graag een aantal mensen bedanken zonder wie dit eindwerk niet tot stand zou zijn gekomen. In de eerste plaats wil ik mijn stagebegeleider, Greet Aernouts, bedanken omdat ze me de kans gegeven heeft om dit interessante stageproject verder uit te werken. Ook mijn eindwerkbegeleider, Eric Pauwels, wil ik graag bedanken voor zijn tips en zijn steun bij dit project. Verder bedank ik Peter Van Den Broeck, IT-werknemer bij Toerisme Provincie Antwerpen, die vrijwillig heeft aangeboden om mijn datamodel na te kijken – hoewel dit zijn taak eigenlijk niet was – en me nuttige tips gegeven heeft. Zijn snelle reactie bij serverproblemen is eveneens bewonderenswaardig. Ook de collega’s op kantoor bij RURANT verdienen een bedankje. Johny Geerinckx, Marlies de Muijnck, Wim Poelmans, Kristien Vanlommel en Julien Van Oosterwijck hebben ervoor gezorgd dat ik me bij RURANT meteen thuis voelde. Tot slot wil ik nog een welgemeend ‘dank je wel’ richten aan mijn vriend, Pieter Evenepoel. Zonder zijn aanmoedigingen op moeilijke momenten zou dit eindwerk er niet gekomen zijn.

4

SAMENVATTING Dit eindwerk is een verslag van mijn dertien weken durende stage bij RURANT vzw in Geel. RURANT vzw is een platform voor rurale ontwikkeling in de provincie Antwerpen, en een van haar missies is het promoten van streekgebonden producten uit deze provincie. Dit gebeurde vroeger door een inventaris van deze producten bij te houden in een Excelbestand. Mijn taak was om deze inventaris te ontsluiten, door hem om te zetten naar een echte database en een webapplicatie te schrijven om deze data te beheren. Via deze webapplicatie moesten producenten ook in staat zijn hun eigen producten op te geven voor de inventaris, waarbij de beheerder wel steeds moest beslissen of het product al dan niet toegevoegd mocht worden. Dit verminderde het papierwerk voor RURANT aanzienlijk. Het project was een onderdeel van de campagne ‘Lekkers met Streken’, het gezicht van de provinciale werking rond hoeve-en streekproducten. Het design van de webapplicatie is dus gebaseerd op de huisstijl van Lekkers met Streken. De database achter de Lekkers met Streken-inventaris is gebaseerd op MySQL, terwijl de webapplicatie geschreven is in PHP. Als framework voor de applicatie heb ik ervoor gekozen om Kohana te gebruiken.

5

INHOUDSTAFEL VOORWOORD ..................................................................................................... 3 SAMENVATTING ................................................................................................. 4 INHOUDSTAFEL .................................................................................................. 5 FIGURENLIJST .................................................................................................... 7 INLEIDING ......................................................................................................... 8 1

RURANT ............................................................................................... 9

1.1 1.2 1.2.1 1.2.2 1.2.3

Het hoeve- en streekproductenbeleid .................................................. 9 Over welke producten gaat het? .......................................................... 9 Erkend Traditioneel Vlaams Streekproduct ..................................................9 Streekgebonden product ...........................................................................9 Hoeveproduct ........................................................................................ 10

2

STAGEOPDRACHT ............................................................................... 11

2.1 2.1.1 2.1.2 2.2 2.3 2.3.1 2.3.2 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.5 2.6 2.7 2.7.1 2.7.2

Aanleiding en achtergrond van het project ........................................ 11 Problemen met de huidige situatie ........................................................... 11 Voorgestelde verbeteringen ..................................................................... 11 Verwacht resultaat van het project (Shared Vision) .......................... 12 Business Case .................................................................................... 12 Voordelen ............................................................................................. 12 Kosten .................................................................................................. 13 Omschrijving primaire doelgroep en andere stakeholders ................. 13 Kopers van streekproducten .................................................................... 13 Producenten .......................................................................................... 14 Distributie ............................................................................................. 14 Toerisme Provincie Antwerpen ................................................................. 14 Fasering ............................................................................................. 14 Informatie en rapportering ................................................................ 15 Kritische leveringen van buiten het project ....................................... 15 Huisstijl ................................................................................................ 15 Hosting ................................................................................................. 15

3

LEKKERS MET STREKEN ...................................................................... 16

3.1 3.2 3.3 3.3.1 3.3.2 3.4 3.4.1 3.4.2 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.6 3.5.7

De homepage ..................................................................................... 16 De inventaris ...................................................................................... 17 De beheermodules ............................................................................. 18 Accountbeheer ....................................................................................... 19 Opleiding van de beheerders ................................................................... 20 Functionaliteiten voor producenten ................................................... 20 Account registreren ................................................................................ 20 Wachtwoord resetten .............................................................................. 21 Productbeheer en de verschillende productstatussen ........................ 22 Status ‘Onbekend’ .................................................................................. 22 Status ‘In Behandeling’ ........................................................................... 23 Status ‘Goedgekeurd’ ............................................................................. 24 Status ‘Afgekeurd’ .................................................................................. 25 Status ‘In Prullenbak’ ............................................................................. 26 Status ‘Verwijderd’ ................................................................................. 26 Productbeheer door de beheerder ............................................................ 26

6

3.6 3.7

Onderhoud van de applicatie .............................................................. 26 Mogelijke uitbreidingen van de applicatie .......................................... 26

4

DATAMODEL EN DATABASE ................................................................ 28

4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.5 4.6 4.7

Algemene structuur ........................................................................... 28 Tabelnamen .......................................................................................... 28 Attribuutnamen ..................................................................................... 28 Fasering................................................................................................ 28 Accountgedeelte ................................................................................ 29 Gebruikers ............................................................................................ 29 Personen............................................................................................... 30 Adressen ............................................................................................... 31 Regio’s ................................................................................................. 32 Producentgedeelte ............................................................................. 32 Producenten .......................................................................................... 33 Productgedeelte ................................................................................. 33 Producten ............................................................................................. 34 Productcategorieën ................................................................................ 35 Productcertificatie .................................................................................. 36 Producentcertificatie ............................................................................... 37 Overige .............................................................................................. 38 Aanmaken van de database ............................................................... 38 Invoeren van data uit de inventaris ................................................... 38

5

KOHANA PHP...................................................................................... 40

5.1 5.2 5.2.1 5.2.2 5.3 5.3.1 5.3.2 5.3.3

Keuze van het framework .................................................................. 40 Gebruik van Kohana ........................................................................... 40 Naming conventions ............................................................................... 40 Kohana ORM ......................................................................................... 40 Mijn eigen toevoegingen .................................................................... 41 ‘Model_Model’ ........................................................................................ 41 ‘HTML::debug()’..................................................................................... 41 ‘Helper_Menu’........................................................................................ 42

6

HOSTING ............................................................................................ 45

6.1 6.2 6.3 6.3.1 6.3.2

Hosting via mijn eigen webruimte...................................................... 45 Hosting op de servers van TPA ........................................................... 45 Problemen met het overzetten van het project .................................. 45 Probleem met de permissions en .htaccess ................................................ 45 Probleem met het versturen van e-mails ................................................... 46

7

GRAFISCH DESIGN ............................................................................. 47

7.1 7.2 7.2.1 7.2.2 7.2.3 7.3 7.3.1 7.3.2

Het tijdelijke design ........................................................................... 47 De huisstijl ......................................................................................... 48 Kleurgebruik.......................................................................................... 48 Fonts .................................................................................................... 48 De boog onder het logo .......................................................................... 49 Het uiteindelijke design ..................................................................... 49 Browsercompatibiliteit ............................................................................ 50 Validiteit ............................................................................................... 51

BESLUIT…. ....................................................................................................... 52 LITERATUURLIJST ............................................................................................ 53 BIJLAGE 1: DATAMODEL ................................................................................... 54 7.3.3 7.3.4 7.3.5 7.3.6

Accountgedeelte .................................................................................... 54 Producentgedeelte ................................................................................. 55 Productgedeelte ..................................................................................... 56 Overige................................................................................................. 57

7

FIGURENLIJST Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur

1: De homepage van de website ............................................................... 2: De online inventaris van streekproducten ............................................... 3: Detailpagina van twee producten ........................................................... 4: De beheerpagina voor gebruikersaccounts .............................................. 5: Deel een van het formulier om een account toe te voegen ........................ 6: Deel twee van het formulier om een account toe te voegen ...................... 7: Formulier om het wachtwoord te resetten ............................................... 8: Inhoud van de verstuurde e-mail ........................................................... 9: Formulier voor producenten om hun producten toe te voegen ................... 10: De beheerder ziet het product in de lijst met nieuwe producten staan ...... 11: De beheerder kan de validatiegegevens van het product aanpassen ......... 12: Het goedgekeurde product verschijnt in de inventaris ............................ 13: De producent kan de aangepaste gegevens bekijken .............................. 14: De beheerder kan de aanpassingen goedkeuren .................................... 15: Datamodel gebruikers ........................................................................ 16: Datamodel personen .......................................................................... 17: Datamodel adressen .......................................................................... 18: Datamodel regio’s .............................................................................. 19: Datamodel producenten ..................................................................... 20: Datamodel producten ......................................................................... 21: Datamodel productcategorieën ............................................................ 22: Datamodel productcertificatie .............................................................. 23: Datamodel producentcertificatie .......................................................... 24: Datamodel overige............................................................................. 25: De load_date_attribute()-functie ......................................................... 26: De HTML::debug()-functie .................................................................. 27: De functie om het hoofd- en gebruikersmenu te genereren ..................... 28: Een gedeelte van de menustructuur ..................................................... 29: De homepage in het tijdelijke design .................................................... 30: De statusbeheerpagina in het tijdelijke design ....................................... 31: De homepage in het uiteindelijke design ............................................... 32: De statusbeheerpagina in het uiteindelijke design .................................. 33: Het uiteindelijke design in Internet Explorer 7 ....................................... 34: De HTML-code van de applicatie is valid HTML5 .....................................

16 17 18 18 19 20 21 21 22 23 24 24 25 25 29 30 31 32 33 34 35 36 37 38 41 42 43 44 47 48 49 50 50 51

8

INLEIDING Tijdens mijn dertien wekend durende stage bij RURANT vzw in Geel heb ik een inventaris van streekgebonden producten omgezet van een Excelbestand naar een database en webapplicatie. RURANT vzw is een platform voor rurale ontwikkeling in de provincie Antwerpen. Als zodanig is het promoten van streekgebonden producten uit de provincie Antwerpen een van haar missies. Het gezicht van deze campagne is het merk ‘Lekkers met Streken’; hieronder zal ook mijn stageproject gepubliceerd worden. De bedoeling van mijn stageproject was enerzijds de inventaris van streekgebonden producten gemakkelijker toegankelijk te maken, door hem via een webapplicatie met zoekfuncties beschikbaar te stellen. Anderzijds zou de webapplicatie ook het papierwerk voor RURANT verminderen, doordat producenten voortaan zelf in staat zouden zijn om via de applicatie hun streekgebonden producten aan de inventaris toe te voegen. Hierbij moest de beheerder wel steeds beslissen of een product al dan niet voldeed aan de criteria om toegevoegd te mogen worden. Dit eindwerk is een verslag van hoe ik dit project aangepakt heb. Het bevat eveneens meer uitleg bij het eindresultaat: de online inventaris van streekproducten. Ik hoop dat het een hulp zal betekenen voor degene die na mijn stageperiode de applicatie verder moet ontwikkelen. In het eerste hoofdstuk geef ik een korte beschrijving van RURANT en werking binnen de vzw waarin mijn project zich situeert. Het tweede hoofdstuk beschrijft de stageopdracht in meer detail. In het derde hoofdstuk behandel ik het eindresultaat, de webapplicatie, en leg ik de belangrijkste functionaliteiten ervan uit. Hoofdstuk vier handelt over het datamodel en de database achter de applicatie, en bevat verklaringen voor enkele beslissingen die ik tijdens het ontwerp ervan moest nemen. Het vijfde hoofdstuk gaat over Kohana, het framework dat ik gebruikte om de applicatie te programmeren, en over de voordelen en moeilijkheden die dit met zich meebracht. In de laatste twee hoofdstukken geef ik meer informatie over het tot stand komen van respectievelijk de hosting van de applicatie en het grafisch design ervan. Tot slot geef ik mijn bedenkingen bij het hele project in een besluit.

9

1

RURANT

Ik heb dit jaar de kans gekregen om stage te lopen bij RURANT vzw in Geel. RURANT is een platform voor rurale ontwikkeling in de provincie Antwerpen, gevestigd in de Hooibeekhoeve in Geel – Ten Aard. Hun werking richt zich vooral op het stimuleren van gebiedsontwikkeling en het ondersteunen van nieuwe vormen van ruraal ondernemerschap. Een van de missies van RURANT is het promoten van de streekgebonden producten in de provincie Antwerpen. Aangezien mijn stageopdracht zich situeert binnen juist deze missie, zal ik hier wat meer informatie geven over dit onderdeel van de werking van RURANT.

1.1

Het hoeve- en streekproductenbeleid

In de provincie Antwerpen worden heel wat producten gemaakt die een unieke band hebben met de streek, bijvoorbeeld door hun connectie met de geschiedenis van de streek, de traditionele bereidingswijze, of de productie die ter plaatse gebeurt. Het belangrijkste is dat de lokale bevolking het product ziet als een streekeigen product, iets dat echt van hen is. RURANT wil de producenten van deze hoeve- en streekproducten ondersteunen door een duidelijk beleid op te stellen en de nodige diensten te voorzien. Zo wordt bijvoorbeeld de bekendheid van deze producten verhoogd door ze op te nemen in de inventaris van streekproducten. Om hun werking rond hoeve- en streekproducten te promoten heeft RURANT een nieuwe campagne geïntroduceerd: Lekkers met Streken. Ook het resultaat van mijn stageopdracht zal gepubliceerd worden onder deze naam.

1.2

Over welke producten gaat het?

Alleen producten die onder de volgende definities vallen, worden door RURANT en de provincie Antwerpen beschouwd als ‘streekgebonden product’. 1.2.1

Erkend Traditioneel Vlaams Streekproduct

Deze producten dragen het Vlaamse label ‘Streekproduct.be’. Het zijn verse of verwerkte producten, gemaakt van streekeigen grondstoffen of grondstoffen die als streekeigen worden beschouwd. Ze moeten bekend staan als een streekeigen product, in de streek bereid worden, én een langdurige of historische bekendheid genieten. 1.2.2

Streekgebonden product

Als enkel Erkende Traditionele Vlaamse Streekproducten door RURANT gepromoot worden, zouden een groot aantal producenten van regionale hoeve- en streekproducten in de kou blijven staan. Daarom worden binnen Lekkers met Streken ook de streekgebonden producten meegenomen. Streekgebonden producten zijn op één of andere manier verbonden met de streek. Misschien zijn de ingrediënten afkomstig uit de streek, of is de bereidingswijze verbonden met de streek. Er kan ook een verband zijn met de geschiedenis van de streek.

10

Om na te gaan of producten voldoen aan de definitie van streekgebonden product gebruikt RURANT vier toetsingscriteria1. Streekgebonden product A Een streekgebonden product A voldoet aan alle 4 criteria. Indien de producent dit wenst en de criteria van VLAM dit toelaten kan de producent zich laten begeleiden om het label ‘Streekproduct.be’ te behalen. Streekgebonden product B Een streekgebonden product B voldoet aan minstens 2 van de eerste 3 criteria en heeft een aantoonbaar verband met de regio. 1.2.3

Hoeveproduct

Hoeveproducten worden geproduceerd of verwerkt op een actief landbouwbedrijf van een landbouwer in hoofd- of bijberoep. De producten worden hoofdzakelijk ter plaatse of via korte keten aan de consument verkocht.

1

Zie literatuurlijst onder ‘Info productlabels’

11

2

STAGEOPDRACHT

In het eerste semester van dit schooljaar heb ik, samen met een team van medestudenten, al rond de stageopdracht van RURANT gewerkt binnen het vak ‘Businessproject’. We hebben de opdracht geanalyseerd, oplossingen voorgesteld en geprobeerd mogelijke problemen te voorspellen. Tijdens mijn dertien weken durende stageperiode zal ik deze oplossing verder uitwerken. In dit hoofdstuk geef ik wat meer informatie over de achtergrond van de stageopdracht, de betrokken personen en instellingen, en de verwachte oplossing.

2.1

Aanleiding en achtergrond van het project

Momenteel houdt RURANT een lijst van hoeve- en streekproducten uit de provincie Antwerpen bij in de vorm van een Excel-spreadsheet, die te downloaden is via de website van de provincie Antwerpen 2. Na verloop van tijd is duidelijk geworden dat deze opslagmethode een aantal problemen veroorzaakt. 2.1.1

Problemen met de huidige situatie

Ten eerste moeten mensen die informatie uit de inventaris willen opzoeken, steeds het volledige Excelbestand downloaden en met behulp van de ingebouwde zoekfuncties de informatie die ze nodig hebben eruit filteren. Dit is allesbehalve gebruiksvriendelijk. Mensen moeten de lijst steeds opnieuw downloaden om te zorgen dat ze de meest recente versie gebruiken, en bovendien verhindert deze manier van opzoeken dat de resultaten een hoge ranking krijgen in Google. Een ander probleem is dat alle updates van de inventaris momenteel via één persoon verlopen, namelijk de verantwoordelijke voor de inventaris. Producenten van streekgebonden producten die bijvoorbeeld de naam of beschrijving van hun product willen aanpassen, moeten steeds deze verantwoordelijke contacteren, die vervolgens de gegevens in het Excelbestand aanpast. Ook het toevoegen van nieuwe producten verloopt op deze manier. Dit is een omslachtige en tijdrovende manier van werken. Daarnaast heeft de Excel-spreadsheet ook een meer technisch probleem, namelijk dat hij niet genormaliseerd is. Elk product krijgt een eigen rij en de gegevens van de producent zijn in deze rij bijgevoegd. Aangezien verschillende producenten met meerdere producten in de inventaris staan, zijn hun gegevens dubbel aanwezig. Dit verhoogt het risico op inconsistentie wanneer de gegevens van een producent aangepast worden. Tot slot heeft RURANT plannen om op termijn een webshop op te starten waarin producenten hun streekgebonden producten aan de man kunnen brengen. Ze kunnen het Excelbestand hiervoor uiteraard niet als basis gebruiken; er is een echte database nodig. 2.1.2

Voorgestelde verbeteringen

Deze database moet ontworpen worden op basis van het Excelbestand, maar er is nog ruimte voor een aantal verbeteringen. Zo kunnen de mogelijke gegevens van zowel producten als producenten fors uitgebreid worden, met bijvoorbeeld foto’s en extra achtergrondinformatie.

2

Zie literatuurlijst onder ‘Inventaris van streekgebonden producten’

12

De database kan toegankelijk gemaakt worden via een webapplicatie. Bezoekers van de website zullen dan bijvoorbeeld de informatie over streekgebonden producten rechtstreeks online kunnen opzoeken, in plaats van steeds eerst een bestand te moeten downloaden. Voor producenten kan de applicatie functionaliteiten hebben waarmee ze zelf hun producten kunnen opgeven voor opname in de inventaris. Deze nieuwe producten moeten uiteraard eerst gecontroleerd worden door een beheerder, die dan beslist of ze al dan niet aan de inventaris toegevoegd zullen worden. Op termijn kan de database eveneens dienen als basis voor andere applicaties, bijvoorbeeld de webshop.

2.2

Verwacht resultaat van het project (Shared Vision)

Het verwachte resultaat van het project is een platform voor het opzoeken, kopen en verkopen van hoeve- en streekproducten uit de provincie Antwerpen op een gebruiksvriendelijke manier. Dit platform bestaat uit drie onderdelen, hieronder opgesomd in volgorde van belangrijkheid. Het eerste onderdeel is de inventaris. Met behulp van de inventaris kunnen mensen op een gebruiksvriendelijke manier informatie opzoeken over hoeve- en streekproducten. Producenten zijn in staat hun eigen producten toe te voegen en de gegevens van deze producten (in beperkte mate) aan te passen. Alle gegevens in de inventaris worden wel beheerd door RURANT. Als tweede stap wordt aan de inventaris een webshop gekoppeld, waarin producenten de mogelijkheid krijgen hun streekgebonden producten te verkopen, aan particulieren of aan zakelijke klanten. Klanten kunnen hun bestelde producten afhalen via afhaalpunten die door de producent worden opgegeven. Het derde onderdeel ten slotte is de distributie. De producten die via de webshop besteld worden, kunnen door een distributeur bij de kopers aan huis geleverd worden. Hierbij wordt er rekening gehouden met de houdbaarheid van producten en de afstand tussen de producent en de koper. Tijdens mijn stage zal ik waarschijnlijk niet voldoende tijd hebben om het volledige project uit te werken. De inventaris is de eerste prioriteit; deze moet tijdens mijn stageperiode online gezet worden. Daarnaast moet de basis aanwezig zijn om de volgende onderdelen, de webshop en het distributiesysteem, toe te kunnen voegen. Ik zal hiermee rekening moeten houden bij het opstellen van het datamodel.

2.3

Business Case

Het omzetten van de inventaris uit het Excelbestand naar een database en webapplicatie biedt RURANT verschillende voordelen, maar brengt ook bepaalde kosten met zich mee. 2.3.1

Voordelen

Ten eerste zal de gebruikersinterface om de producten uit de inventaris te beheren sterk vereenvoudigd zijn. Alle informatie wordt centraal in één database opgeslagen, zodat iedereen steeds met de meest recente versie werkt en alles gemakkelijk terug te vinden is. Het beheer van de inventaris zal hierdoor minder tijd in beslag nemen. Daarnaast zullen producenten hun nieuwe producten via de webapplicatie kunnen opgeven ter goedkeuring. Ze zullen ook in staat zijn hun eigen gegevens (gedeeltelijk) zelf te updaten. Dit vermindert het papierwerk voor RURANT aanzienlijk. Een tweede voordeel is dat een webapplicatie voor gebruikers gemakkelijker is om mee te werken dan een Excelbestand. Een website is ook veel vlotter te promoten,

13

bijvoorbeeld via advertenties, zodat RURANT op termijn de bekendheid van de inventaris kan vergroten. Daarnaast zullen een aantal problemen verholpen worden die eigen zijn aan de opslag van gegevens in een Excelbestand. Bijvoorbeeld: de contactgegevens van sommige producenten zijn momenteel op meerdere plaatsen in de inventaris opgegeven. In een database zal dit niet meer het geval zijn, waardoor er veel minder kans is op fouten en verouderde informatie. Bovendien kunnen op de database geavanceerde applicaties gebaseerd worden, bijvoorbeeld de webshop en het distributiesysteem. Indien nodig kunnen de gegevens uit de database via het internet gedeeld worden met andere partijen, bijvoorbeeld Toerisme Provincie Antwerpen. Ook aan de webshop zijn vele voordelen verbonden. In tegenstelling tot de inventaris, is de webshop een volledig nieuw project waarvoor binnen RURANT nog geen alternatief bestaat. Als gevolg daarvan hebben veel producenten momenteel hun eigen webshop, met sterk variërende mogelijkheden. Een webshop die door RURANT beheerd wordt, betekent minder werk voor deze producenten. De producenten die nog geen webshop hebben, kunnen profiteren van een nieuw verkoopkanaal. Kopers van streekproducten zullen met de webshop een centraal platform hebben waarop ze bestellingen kunnen plaatsen, in plaats van voor elke producent een andere webshop te moeten gebruiken. Dit is voor hen veel overzichtelijker en kan hen bovendien in contact brengen met voordien onbekende producten. Tot slot kan RURANT zich met behulp van de gegevens over bestellingen via de webshop een beter beeld vormen van de handel in streekproducten, zoals welke producten of producenten het populairste zijn en welke klanten de grootste afnemers zijn. Deze gegevens kunnen nuttig zijn bij het opzetten van nieuwe projecten in de toekomst. 2.3.2

Kosten

Zoals aan alle projecten zijn ook aan dit project een aantal kosten verbonden voor RURANT. Allereerst moet voor de database en webapplicatie webruimte en een domeinnaam voorzien worden. De kosten zijn hier afhankelijk van de verlangde snelheid, schijfruimte en stabiliteit. Een tweede punt is de uitwerking van het project zelf. De ontwikkeling zal in eerste instantie gedaan worden door een stagiair; hieraan zijn dus niet onmiddellijk loonkosten verbonden. Maar in tegenstelling tot het Excelbestand, zullen de database en webapplicatie beheerd moeten worden door een IT-professional. Om de applicatie te kunnen beheren en wijzigen zal RURANT na afloop van de stageperiode een ITmedewerker moeten aannemen, of het beheer van het project moeten uitbesteden aan een extern bedrijf. Hieraan zijn uiteraard significante kosten verbonden.

2.4

Omschrijving primaire doelgroep en andere stakeholders

Naast RURANT zelf zijn er nog een aantal andere groepen bij het project betrokken. 2.4.1

Kopers van streekproducten

Kopers van streekgebonden producten zijn voornamelijk op zoek naar een gebruiksvriendelijk overzicht van het bestaande aanbod. De online inventaris zal aan deze behoefte tegemoet komen.

14

Daarnaast zullen ze met de webshop hun bestellingen op elk moment en vanaf elke locatie via een centraal platform kunnen plaatsen, waardoor ze hier minder tijd aan moeten besteden en een veel beter overzicht zullen hebben van hun eerdere en lopende aankopen. Er wordt een onderscheid gemaakt tussen particuliere klanten en zakelijke klanten. Deze laatste kunnen bijvoorbeeld speciale aanbiedingen of kortingen krijgen. 2.4.2

Producenten

Producenten zijn de personen of bedrijven die de streekgebonden producten op de markt brengen. Voor hen is de inventaris van streekproducten een middel om de bekendheid van hun producten te vergroten. Momenteel gaat er heel wat communicatie op papier aan vooraf om een streekproduct te laten opnemen in de inventaris. De bedoeling van het project is onder andere dit proces te vereenvoudigen door een groot deel van de communicatie via de webapplicatie te laten verlopen. Verder zullen de producenten via de webapplicatie de gelegenheid krijgen om gegevens over hun bedrijf en streekproducten te publiceren en aan te passen, en zullen ze hun producten te koop kunnen aanbieden via de webshop. 2.4.3

Distributie

De webshop kan op termijn uitgebreid worden met een distributiesysteem. De distributeur is dan iemand die op vaste dagen de bestelde producten bij de producent komt ophalen en bij de klant gaat afleveren. Hij moet dus een overzicht kunnen genereren van de bestellingen en de locaties van de producenten en klanten. 2.4.4

Toerisme Provincie Antwerpen

Toerisme Provincie Antwerpen (TPA) is een instelling die instaat voor het provinciaal toerismebeleid van Antwerpen. TPA wil toegang krijgen tot de gegevens van de inventaris om de gegevens over streekproducten te kunnen koppelen aan hun eigen informatie over de streek. Ze verkiezen de benodigde gegevens uit te inventaris op te halen in XML-formaat.

2.5

Fasering

In het ideale geval verloopt het project in de hieronder beschreven fases. In het eerste stadium zal ik een datamodel opstellen, de database aanmaken en de code van de webapplicatie schrijven. Omdat de structuur van de data behoorlijk ingewikkeld is, ben ik van plan dit in fases te doen, waarbij ik telkens een deel van het datamodel ontwerp en de bijbehorende functionaliteiten aan de webapplicatie toevoeg. De opdrachtgever kan in elke fase feedback geven op deze functionaliteiten. Ondertussen moet de bestaande data uit de inventaris in de database ingevoerd worden. Dit is een goede gelegenheid om te testen of alle functionaliteiten naar behoren werken. In een verder stadium moet de website een design krijgen dat overeenkomt met de huisstijl. Omdat deze huisstijl bij het begin van mijn stageperiode nog niet beschikbaar is, zal ik in de tussentijd met een tijdelijke design moeten werken. Ook moet RURANT nog hosting voorzien voor de webapplicatie. Momenteel worden verschillende mogelijkheden hiervoor verkend. Ondertussen plaats ik de database en

15

applicatie op mijn persoonlijke webruimte, zodat mijn stage- en eindwerkbegeleider mijn voortgang online kunnen volgen en de applicatie op elk moment kunnen testen. Pas als er officiële hosting voorzien is, kan de echte testfase beginnen. Hierbij zullen een aantal producenten de kans krijgen om de webapplicatie uit te testen en feedback te geven. Met behulp van hun opmerkingen kan ik de applicatie verder verbeteren. In het laatste stadium zal de inventaris online gepubliceerd worden. Alle betrokken producenten moeten op dat moment op de hoogte gesteld worden van de nieuwe inventaris.

2.6

Informatie en rapportering

Tijdens mijn stageperiode is er een wekelijks overlegmoment met mijn stagebegeleider voorzien. Daarnaast zal ik ook wekelijks mijn voortgang rapporteren aan mijn eindwerkbegeleider.

2.7

Kritische leveringen van buiten het project

Er zijn twee zaken die onontbeerlijk zijn voor het goede verloop van het project, en die tijdens het verloop van het project nog geleverd of geregeld moeten worden. 2.7.1

Huisstijl

Kantara, een communicatie- en marketingadviesbureau, ontwikkelt het merk en de bijbehorende huisstijl voor Lekkers met Streken. Het grafisch design van de website moet conform deze huisstijl zijn; bijgevolg heb ik de beschrijving ervan bij voorkeur nodig voordat de applicatie in de testfase komt. Eventueel kan het design ook nog tijdens de testfase aangepast worden, maar voor de publicatie van de inventaris moet het zeker in orde zijn. 2.7.2

Hosting

De webapplicatie zal ergens gehost moeten worden om online bereikbaar te zijn. Aan wie de hosting uitbesteed zal worden, moet tijdens de stageperiode nog besloten worden. Het is absoluut noodzakelijk dat er webruimte beschikbaar is voordat het project de testfase ingaat. Op dat moment moet de applicatie bereikbaar zijn via de domeinnaam www.lekkersmetstreken.be.

16

3

LEKKERS MET STREKEN

Tijdens mijn stageperiode heb ik een begin gemaakt met een webapplicatie die de oude inventaris – het Excelbestand – kan vervangen. In dit hoofdstuk bespreek ik een beperkt aantal aspecten van dit eindresultaat, en doe ik enkele voorstellen over functionaliteiten die er in de toekomst nog aan toegevoegd kunnen worden.

3.1

De homepage

Figuur 1: De homepage van de website

Op de homepage van de website staat wat meer informatie over Lekkers met Streken. Daarnaast worden er aan de rechterkant van de pagina nog wat extra’s getoond, zoals gerelateerde evenementen. De beheerder kan een product uitkiezen dat op de homepagina getoond wordt onder ‘Product in de kijker’ en zo wat meer in de belangstelling komt te staan.

17

3.2

De inventaris

Figuur 2: De online inventaris van streekproducten

De lijst van streekproducten is het belangrijkste publieke onderdeel van de applicatie. Wanneer een bezoeker van de website de inventarispagina opent, krijgt hij onmiddellijk de lijst van streekgebonden producten te zien. De lijst heeft een aantal sorteermogelijkheden, waaronder ‘naam’, ‘producent’ en ‘gemeente’. Hij kan gefilterd worden op label of op categorie. Bij het filteren op categorie worden alle producten getoond van die categorie, samen met alle producten van zijn subcategorieën. Wanneer een bezoeker meer informatie over een product wenst te zien, kan hij op de afbeelding van het vergrootglas rechts naast de productinformatie klikken. Ook kan hij een aantal producten selecteren en de knop ‘Bekijken’ gebruiken. Van al deze producten wordt dan een meer gedetailleerd overzicht getoond, zoals in de afbeelding hieronder. Merk op dat de naam van de producent een link is. Wanneer een bezoeker van de inventaris hierop klikt, krijgt hij meer informatie over deze producent te zien.

18

Figuur 3: Detailpagina van twee producten

3.3

De beheermodules

De verantwoordelijke voor de inventaris bij RURANT heeft steeds het laatste woord over de data in de inventaris. Daarom zijn er uitgebreide functionaliteiten voorzien om deze data te beheren.

Figuur 4: De beheerpagina voor gebruikersaccounts

Wat betreft de gebruikersinterface, zitten alle beheerpagina’s op dezelfde manier in elkaar. Er wordt een lijst getoond van beschikbare data, waarbij de beheerder de mogelijkheid krijgt deze data in detail te bekijken, aan te passen of te verwijderen. Net als in de inventaris het geval was, kan dit ofwel gebeuren met behulp van de icoontjes aan de rechterkant, ofwel met behulp van de selectievakjes en de knoppen.

19

3.3.1

Accountbeheer

Figuur 5: Deel een van het formulier om een account toe te voegen

Accountbeheer is de functionaliteit die naast productbeheer waarschijnlijk het meest gebruikt zal worden. Ik bespreek deze functionaliteit hier nog eens apart, omdat er bij het implementeren ervan wat onduidelijkheden waren over wat er moest gebeuren met het wachtwoord en de producentinformatie. Het wachtwoord van nieuwe en bestaande accounts Wanneer de beheerder een nieuw account toevoegt, is het niet de bedoeling dat hij ook een nieuw wachtwoord moet verzinnen voor dit account. Het account moet anderzijds wel een wachtwoord hebben om toegevoegd te kunnen worden in de database. Ik heb dit opgelost door bij het toevoegen van een account te controleren of het wachtwoordveld leeg is. Is dit het geval, dan kent de applicatie het account een wachtwoord toe en kan de gebruiker in kwestie dit wachtwoord wijzigen via de ‘wachtwoord resetten’-functionaliteit (zie ook ‘Functionaliteiten voor producenten’). Wanneer de beheerder een account toevoegt, kan hij dus het wachtwoordveld leeg laten. Hij kan natuurlijk ook gewoon een wachtwoord invullen, indien dit een bepaalde waarde moet hebben. Bij het aanpassen van een gebruiker kan de beheerder het wachtwoordveld eveneens gewoon leeg laten. Het wordt dan niet veranderd. Als de beheerder het wachtwoordveld wel invult, wordt het wachtwoord aangepast naar de nieuwe waarde. Producentinformatie invoeren Een ander probleem is het feit dat voor producenten meer gegevens moeten worden ingevoerd dan voor andere soorten gebruikers. De applicatie ‘weet’ echter niet of het nieuwe account een producent zal zijn voordat de beheerder op ‘Toevoegen’ geklikt heeft, waarna het te laat is om nog op een gebruiksvriendelijke manier naar de producentinformatie te vragen. Uiteindelijk heb ik besloten dit probleem op te lossen door het formulier voor gebruikersaccounts in twee delen te splitsen. In het eerste deel vult de beheerder onder andere de functie van het account in (zie bovenstaande afbeelding). Is deze

20

functie ‘Producent’, dan kan de beheerder op de volgende pagina van het formulier de bedrijfsinformatie invullen (zie onderstaande afbeelding). In alle andere gevallen wordt op de tweede pagina enkel om de adresinformatie gevraagd.

Figuur 6: Deel twee van het formulier om een account toe te voegen

3.3.2

Opleiding van de beheerders

In de voorlaatste week van mijn stageperiode heb ik een aantal mensen een woordje uitleg gegeven over de werking van de webapplicatie, en dan meer specifiek de beheermodules. Op dat moment hebben zij ook feedback gegeven op de applicatie. Wegens tijdgebrek heb ik niet al deze aanpassingen kunnen uitvoeren, maar het voornaamste probleem – er was vertrouwelijke informatie zichtbaar in de publieke inventaris – is wel opgelost.

3.4

Functionaliteiten voor producenten

Voor producenten van streekgebonden producten zijn natuurlijk de nodige functionaliteiten voorzien zodat zij hun bedrijfsinformatie en hun producten aan de inventaris kunnen toevoegen. 3.4.1

Account registreren

Producenten kunnen een account registreren voor zichzelf, waarbij ze tegelijkertijd hun bedrijfsinformatie kunnen opgeven. Eens een producent geregistreerd is, kan hij onmiddellijk beginnen met producten toevoegen (hierover meer onder ‘Productbeheer en de verschillende productstatussen’).

21

3.4.2

Wachtwoord resetten

Figuur 7: Formulier om het wachtwoord te resetten

De producenten die al in de oude inventaris aanwezig waren, zijn door RURANT van tevoren toegevoegd aan de database. Zij hebben van de applicatie een voorlopig wachtwoord gekregen, maar moeten dit nog aanpassen voordat ze kunnen inloggen. Hiertoe is een functionaliteit toegevoegd om het wachtwoord te resetten. Wanneer een gebruiker op de ‘wachtwoord resetten’-pagina zijn e-mailadres ingeeft, wordt er een token gegenereerd om deze gebruiker te kunnen authentiseren. Van de combinatie van deze token en het opgegeven e-mailadres wordt een link gemaakt die vervolgens naar het e-mailadres gestuurd wordt (zie onderstaande afbeelding). Wanneer de gebruiker binnen de vierentwintig uur op deze link klikt, wordt hij automatisch ingelogd en doorgestuurd naar het formulier waar hij zijn wachtwoord kan aanpassen.

Figuur 8: Inhoud van de verstuurde e-mail

22

3.5

Productbeheer en de verschillende productstatussen

Voor de werking van de inventaris is het uiteraard essentieel dat producenten hun producten kunnen toevoegen. Wanneer een product door een producent toegevoegd wordt, krijgt het de status ‘Onbekend’. In het daaropvolgende validatieproces kan de status meerdere malen veranderen. Hieronder geef ik uitgebreide uitleg over dit proces en de implicaties die een statusverandering met zich meebrengt. 3.5.1

Status ‘Onbekend’

Figuur 9: Formulier voor producenten om hun producten toe te voegen

Zoals hierboven al vermeld is, krijgen producten die door een producent werden toegevoegd automatisch de status ‘Onbekend’. Deze producten zijn nog niet zichtbaar in de inventaris, aangezien ze nog niet zijn goedgekeurd door de beheerder. De producent kan een overzicht zijn nieuwe producten bekijken onder het menu-item ‘Nieuw’. In de menu-items voor elk van de statussen wordt ook onmiddellijk weergegeven hoeveel producten van een deze status deze producent heeft, zodat een statusverandering snel opgemerkt wordt. Producten die de status ‘Onbekend’ hebben, kunnen nog aangepast worden door de producent. Als de producent dus fouten opmerkt in een recent toegevoegd product, is hij vrij om deze te verbeteren. In de beheermodule verschijnt het nieuwe product eveneens in de lijst met nieuwe producten. Daar blijft het staat totdat de beheerder het product in behandeling neemt.

23

Figuur 10: De beheerder ziet het product in de lijst met nieuwe producten staan

3.5.2

Status ‘In Behandeling’

Op het moment dat de beheerder in de lijst met nieuwe producten op ‘Aanpassen’ klikt, wordt de status van het product veranderd naar ‘In Behandeling’. Vanaf dit moment kan de producent het product tijdelijk niet meer aanpassen. Dit om te voorkomen dat de gegevens van het product nog veranderen terwijl de beheerder bezig is het product te valideren. Wanneer de status van het product verandert, is het product voor de producent niet meer terug te vinden onder het menu-item ‘Nieuw’, maar onder ‘In Behandeling’. De beheerder kan het product nu op alle mogelijke manieren aanpassen – hij kan bijvoorbeeld de naam of de beschrijving van het product wijzigen. Meestal echter zal hij alleen de validatiegegevens van het product willen wijzigen. De beheerder kan voor elk van de validatievragen die de producent bij het toevoegen ingevuld heeft, aanvinken of het opgegeven antwoord in orde is of niet. Deze functionaliteit is handig wanneer de validatie over meerdere dagen gespreid is, of wanneer meerdere beheerders samenwerken aan hetzelfde product. Daarnaast kan hij een aantal gegevens zoals de productieplaats afleiden uit de opgegeven antwoorden en invullen in de daarvoor voorziene velden. Als het product een Erkend Traditioneel Vlaams Streekproduct is, moet de beheerder dit selectievakje manueel aanvinken. Als het product een streekgebonden product is, moet de beheerder de criteria waaraan het product voldoet, aanvinken. Het label wordt dan automatisch bepaald op basis van de aangevinkte criteria.

24

Figuur 11: De beheerder kan de validatiegegevens van het product aanpassen

3.5.3

Status ‘Goedgekeurd’

Wanneer de beheerder bepaald heeft dat het product in orde is en aan de inventaris toegevoegd kan worden, zet hij de status van het product op ‘Goedgekeurd’. Goedgekeurde producten zijn de enige producten die zichtbaar zijn in de publieke inventaris van streekproducten. Merk op dat de status van een product alleen op ‘Goedgekeurd’ gezet kan worden als het product een label heeft. Producten zonder label kunnen dus nooit in de inventaris terechtkomen.

Figuur 12: Het goedgekeurde product verschijnt in de inventaris

Eens de status van het product van ‘In Behandeling’ naar ‘Goedgekeurd’ gezet is, kan de producent het product in beperkte mate aanpassen. Alle aanpassingen die door de producent gedaan worden, moeten eerst door de beheerder goedgekeurd worden

25

voordat ze zichtbaar worden in de inventaris. In de tussentijd kan de producent zijn aangepaste producten bijhouden onder het menu-item ‘Aangepast’.

Figuur 13: De producent kan de aangepaste gegevens bekijken

Ondertussen wordt het product ook voor de beheerder toegevoegd aan de lijst met aangepaste producten. Wanneer hij op zijn beurt op ‘Aanpassen’ klikt, krijgt hij een vergelijking tussen de oude en de nieuwe gegevens te zien. Hij kan deze op elke mogelijk manier verder aanpassen of gewoon rechtstreeks goedkeuren.

Figuur 14: De beheerder kan de aanpassingen goedkeuren

3.5.4

Status ‘Afgekeurd’

Wanneer een producent een product toegevoegd heeft dat niet geschikt is om in de inventaris te verschijnen, zet de beheerder de status van het product op ‘Afgekeurd’. Voor zowel de producent als de beheerder verschijnt het product nu onder het menuitem ‘Afgekeurd’.

26

De producent kan een afgekeurd product nog steeds aanpassen. Wanneer de producent een aanpassing doorvoert, wordt de status van het product weer op ‘Onbekend’ gezet en wordt het verder behandeld als een volledig nieuw product. 3.5.5

Status ‘In Prullenbak’

Wanneer een producent een van zijn producten verwijdert, wordt de status op ‘In Prullenbak’ gezet. Producten in de prullenbak zijn niet meer zichtbaar voor de producent en verdwijnen uit de inventaris. Deze status is voornamelijk toegevoegd om de beheerder een overzicht te geven van de producten die door hun producent verwijderd zijn. 3.5.6

Status ‘Verwijderd’

Wanneer de beheerder een product met een status anders dan ‘Verwijderd’ verwijdert, wordt de status van het product op ‘Verwijderd’ gezet. Het product is dan alleen nog maar zichtbaar voor de beheerder, in de lijst van verwijderde producten. Wanneer de beheerder een product met deze status verwijdert, wordt het definitief verwijderd uit de database. Het is niet aan te raden dit te doen, omdat deze actie onomkeerbaar is. 3.5.7

Productbeheer door de beheerder

Bovenstaande uitleg in verband met statussen geldt uiteraard alleen wanneer het product toegevoegd werd door een producent. Wanneer een beheerder zelf een product toevoegt, kan hij de status van het nieuwe product selecteren in een lijst. Een product dat door de beheerder is toegevoegd, kan dus eender welke status hebben. De beheerder kan deze status natuurlijk ook op elk moment aanpassen.

3.6

Onderhoud van de applicatie

Tijdens het ontwikkelproces is er verschillende malen sprake geweest van vertragingen, zowel in mijn eigen planning als bij het klaarmaken van een server om de applicatie te hosten (zie hoofdstuk 6: ‘Hosting’). Ik heb de basisfunctionaliteiten, zoals hierboven beschreven, kunnen implementeren. Vele extra’s zijn echter weggevallen. Ook heb ik een aantal functionaliteiten niet zo uitgebreid kunnen testen als ik gewild had. In de oorspronkelijke planning was ook een aantal dagen gereserveerd voor testen door producenten, zodat ik hun feedback nog in het project zou kunnen verwerken. Doordat de officiële server echter pas op het einde van mijn stage beschikbaar kwam, hebben we deze tests niet kunnen uitvoeren. Dit zal dus nog moeten gebeuren na mijn vertrek. Op deze manier zullen de meeste bugs hoogstwaarschijnlijk boven water komen. Als gevolg hiervan is het noodzakelijk dat iemand anders na mijn stageperiode deze testen alsnog uitvoert en de nodige aanpassingen in de applicatie doorvoert. RURANT heeft een aantal mensen van de IT-afdeling binnen Toerisme Provincie Antwerpen (TPA) bereid gevonden om dit op zich te nemen, zolang het bij kleine aanpassingen blijft. Voor grote wijzingen aan de applicatie zal RURANT een extern bedrijf moeten inhuren.

3.7

Mogelijke uitbreidingen van de applicatie

Zoals hierboven al vermeld is, ben ik niet toe gekomen aan een aantal in meerdere of mindere mate noodzakelijke extra functionaliteiten voor de applicatie. Het belangrijkste hierbij is waarschijnlijk het gebrek aan extra uitleg op elke pagina en een helpfunctie. In dit eindwerk heb ik geprobeerd zo goed mogelijk de verschillende functionaliteiten

27

van de webapplicatie te beschrijven, vooral diegene die misschien minder voor de hand liggend zijn. Mijn opvolger kan deze informatie gebruiken om helpschermen voor gebruikers aan de applicatie toe te voegen. Verder ben ik er ook niet aan toe gekomen om een aantal webpagina’s uit te rusten met AJAX-functionaliteiten. Een dergelijke functionaliteit was bijvoorbeeld handig geweest bij het toevoegen van een nieuw account, zodat bij het selecteren van een postcode de selectielijst van de gemeentes beperkt zou kunnen worden tot alleen de gemeentes die bij deze postcode kunnen horen. Ook wanneer een beheerder een product valideert door de juiste criteria aan te vinken, zou het handig zijn als het juiste label onmiddellijk mee aangevinkt werd. Een derde onderdeel dat waarschijnlijk nog aanpassingen behoeft, is het ophalen van data uit de database. Ik ben ervan overtuigd dat hier nog veel optimalisatie kan gebeuren, vooral door eerder opgehaalde objecten te cachen in plaats van ze steeds opnieuw uit de database te selecteren. Hierbij denk ik bijvoorbeeld aan gebruikersfuncties, gemeentes, landen, productlabels ... Op termijn kan, zoals oorspronkelijk de bedoeling was, nog een webshop en een distributiesysteem aan de applicatie toegevoegd worden. Hiermee heb ik rekening gehouden bij het opstellen van het datamodel (zie hoofdstuk 4: Datamodel en database).

28

4

DATAMODEL EN DATABASE

Als eerste stap bij het uitwerken van mijn stageproject heb ik een datamodel opgesteld op basis van de bestaande inventaris van streekgebonden producten. In dit hoofdstuk zal ik wat verder ingaan op de structuur van dit datamodel en het ontwikkelproces van de database zelf. Wegens het grote aantal tabellen heb ik besloten dit in kleine stappen te doen, waarbij ik telkens een onderdeeltje van het datamodel bespreek. Het volledige model is terug te vinden in bijlage 1.

4.1

Algemene structuur

Om te beginnen wil ik wat algemene bemerkingen geven bij de opbouw van het datamodel. 4.1.1

Tabelnamen

Bij nader bestuderen van het datamodel valt het waarschijnlijk op dat de namen van de tabellen steeds dezelfde basisstructuur hebben, namelijk ‘onderdeel_tabelnaam’. Hier bestaat een dubbele reden voor. Ten eerste heeft Kohana, het PHP-framework dat ik gebruikt heb, een naming convention waarbij de namen van klassen moeten bestaan uit het pad naar het bestand waarin de klasse zich bevindt, gescheiden door underscores. (In het volgende hoofdstuk meer hierover.) Omdat ik door het grote aantal tabellen ook een groot aantal bijbehorende modelklassen zou moeten aanmaken, heb ik besloten deze klassen te verdelen in submappen. Elke klassenaam moest dus het prefix ‘Model_[mapnaam]_’ krijgen. Ik heb besloten dit systeem door te trekken naar het datamodel, zodat Kohana automatisch de namen van de tabellen die bij deze klassen hoorden, zou kunnen bepalen – wat mij de moeite bespaarde van deze handmatig te moeten configureren. De tweede reden is dat ik vermoedde dat, door het grote aantal tabellen, het moeilijk zou worden om een bepaalde tabel in de lijst snel terug te vinden. Door bij elkaar horende tabellen hetzelfde prefix te geven, staan deze in een alfabetisch gesorteerde lijst mooi gegroepeerd. 4.1.2

Attribuutnamen

In het datamodel heb ik er zorg voor gedragen dat alle attributen van het type ‘date’ of ‘datetime’ eindigen op het suffix ‘_date’. Met behulp van deze naming convention heb ik zelf code geschreven die de data van strings omzet naar echte datumobjecten. 4.1.3

Fasering

Omdat vanaf het begin duidelijk was dat het datamodel erg uitgebreid zou worden, heb ik besloten het ontwerp ervan in fases aan te pakken. Ik ben begonnen met het gedeelte voor de gebruikersaccounts, omdat ik op die manier vroeg in het ontwikkelproces al inlog- en autorisatiefunctionaliteiten kon toevoegen. Het was tenslotte belangrijk dat deze functionaliteiten uitgebreid getest konden worden voor de publicatie van het project. Daarnaast werd op die manier ook voorkomen dat ongeautoriseerde gebruikers tijdens het ontwikkelproces de beheerpagina’s van de applicatie konden gebruiken. Het volgende gedeelte dat ik aan het datamodel toevoegde, was dat van de producenten: de extra informatie die aan accounts met de functie ‘producent’ gekoppeld moest worden. Aan deze tabellen kon ik ten slotte de tabellen in verband met de producten koppelen.

29

Ik zal de onderdelen van het datamodel hieronder in dezelfde volgorde bespreken als ik ze tijdens mijn stageperiode opgesteld heb.

4.2

Accountgedeelte

Het accountgedeelte van het datamodel omvat alle tabellen met informatie over gebruikersaccounts en de gebruikers zelf. 4.2.1

Gebruikers

Figuur 15: Datamodel gebruikers

De bovenstaande tabellen bevatten de informatie in verband met gebruikersaccounts. De centrale tabel hier is ‘user_users’, die de basisinformatie van een account zoals email, wachtwoord, en wat extra inloggegevens bevat. Aan een account zijn tokens gekoppeld; deze hebben in de applicatie een dubbele functie. Ten eerste worden ze gebruikt om gebruikers die dit verkiezen aangemeld te houden, ook in volgende browsersessies. Dit gebeurt door middel van een cookie, die dezelfde string bevat als in het ‘token’-attribuut in de tabel. Ten tweede worden tokens gebruikt als authenticatiestring wanneer een gebruiker zijn wachtwoord reset. Daarnaast is aan een account ook een functie gekoppeld. Elke functie heeft een of meerdere permissies, die doorheen de applicatie gebruikt worden om te controleren of de ingelogde gebruiker wel het recht heeft om bepaalde data te bekijken of een bepaalde actie uit te voeren.

30

4.2.2

Personen

Figuur 16: Datamodel personen

Achter elk account zit logischerwijs een persoon. De bovenstaande tabellen bevatten informatie over deze persoon, zoals zijn naam en contactinformatie. Ik heb de persoonsinformatie in het datamodel bewust gescheiden gehouden van de accountinformatie, omdat binnen het domein ook personen zouden kunnen voorkomen die geen account hebben – bijvoorbeeld de contactpersonen van de producenten, of de producenten waarvan geen e-mailadres beschikbaar is (voor meer informatie hierover: zie ‘producentgedeelte’). In de eerste versie van het datamodel bevatte de tabel ‘person_profiles’ ook nog een attribuut ‘gender’. Na verloop van tijd heb ik echter geconcludeerd dat deze informatie in feite dubbel in de database zat, doordat elke persoon al een naam met een aanspreektitel (‘honorific’) had. Aangezien elke aanspreektitel bedoeld is voor ofwel een man, ofwel een vrouw, kon het geslacht van de persoon al op deze manier afgeleid worden. Ik heb het overbodige attribuut dus verwijderd. Een ander punt dat het vermelden waard is, is het aantal adressen dat een persoon kan hebben. In het datamodel is voorzien dat dit meerdere adressen kunnen zijn, terwijl in de applicatie op het moment van schrijven maar één adres gebruikt wordt, namelijk het adres waar de waarde van het attribuut ‘is_main’ op 1 staat. De mogelijkheid van meerdere adressen is vooral interessant als in de toekomst een webshop toegevoegd wordt. Op dat moment zullen met name de producenten waarschijnlijk een thuisadres en een bedrijfsadres nodig hebben.

31

4.2.3

Adressen

Figuur 17: Datamodel adressen

Dit gedeelte van het datamodel bevat alle informatie die met adressen te maken heeft, zoals straat, gemeente, postcode en land. Op het moment van schrijven hebben alleen personen adressen, maar in de toekomst kan dit gedeelte van het datamodel bijvoorbeeld ook gebruikt worden voor afhaalpunten van producten. Een punt van aandacht is hier de splitsing tussen internationale adressen enerzijds, en Belgische adressen anderzijds. Door de structuur van het datamodel is het voor Belgische adressen verplicht een bestaande Belgische gemeente en postcode te hebben. Met behulp van de koppeling van deze laatste twee tabellen doorheen ‘address_cities_postcodes’, is het ook nog eens mogelijk om te controleren of de gemeente en postcode wel degelijk een geldige combinatie zijn. Ik heb besloten om de correctheid van Belgische adressen op deze manier af te dwingen om twee redenen. Ten eerste is het absoluut noodzakelijk dat de adressen correct zijn wanneer later een webshop met distributiesysteem toegevoegd wordt. Op dat moment zal de distributeur namelijk moeten weten waar hij de producten moet ophalen en waar hij ze naartoe moet brengen. Waarschijnlijk is het daarbij handig als de applicatie de adressen kan aanduideden op een kaart – bij voorkeur via Google Maps. Er zal waarschijnlijk ook sprake zijn van een maximale afstand tussen producent en klant, waarbij de klant een foutmelding moet krijgen als hij te ver weg woont om zijn bestelling aan huis geleverd te krijgen. Ten tweede is er met het oog op een koppeling met het systeem van Toerisme Provincie Antwerpen ook de mogelijkheid voorzien om de toeristische regio van een

32

gemeente op te geven (zie hieronder). Het spreekt voor zich dat de gemeentes hiervoor gestandaardiseerd moeten zijn in een aparte tabel. 4.2.4

Regio’s

Figuur 18: Datamodel regio’s

De tabel ‘address_provinces’ bevat uiteraard de tien Belgische provincies, terwijl de tabel ‘address_regions’ verwijst naar de toeristische regio’s van de provincie Antwerpen3. De koppeling tussen deze beide tabellen doorheen ‘address_provinces_regions’ zorgt voor een extra controle of de combinatie regioprovincie wel correct is. Bij het opstellen van het datamodel heb ik deze tabellen toegevoegd als voorbereiding op een koppeling met het systeem van Toerisme Provincie Antwerpen (TPA). TPA wil op basis van de regio de streekgebonden producten in die regio kunnen terugvinden. Achteraf bekeken lijkt het me waarschijnlijk dat TPA de koppeling tussen regio’s en gemeentes in hun eigen database zal voorzien, en dat zoeken op de naam van de gemeente voor hen voldoende zal zijn. Deze tabellen zijn dus hoogstwaarschijnlijk overbodig en in de applicatie zelf is bijgevolg geen module voorzien om de regio’s te beheren.

4.3

Producentgedeelte

In een volgend stadium van het ontwikkelproces heb ik de tabellen in verband met producentgegevens aan het datamodel toegevoegd. Dit gedeelte omvat alle tabellen die met het bedrijf van de producent te maken hebben.

3

Zie literatuurlijst onder: ‘Toerisme Vlaanderen’

33

4.3.1

Producenten

Figuur 19: Datamodel producenten

In principe omvatten de producentgegevens in het datamodel gewoon de tabel ‘producer_profiles’. In het datamodel zijn tabellen voorzien om filmpjes, foto’s en commentaar aan de producent te koppelen, maar deze functionaliteiten zijn wegens tijdgebrek niet aan de applicatie toegevoegd. Het is het waard om op te merken dat eerder in het ontwikkelproces de tabel ‘producer_profiles’ niet gekoppeld was aan ‘person_profiles’ maar aan ‘user_users’ – rechtstreeks aan de gebruikersaccounts dus. Het probleem met deze constructie was dat voor een aantal producenten, die al in de inventaris aanwezig waren, geen emailadres beschikbaar bleek te zijn. Omdat het e-mailadres gebruikt wordt om in te loggen en dus niet weggelaten kon worden, was het onmogelijk om deze producenten in de database in te geven. Dit probleem heb ik opgelost door de producentgegevens te koppelen aan ‘person_profile’, zodat in de toekomst wel alle producentgegevens ingegeven kunnen worden, maar dan zonder account eraan gekoppeld. Een andere bemerking is dat in het datamodel de mogelijkheid voorzien is om voorlopige ‘producer_data’ in te geven. Via deze tabel kunnen producenten een label toegekend krijgen (zie ‘producentcertificatie’). Het idee was dat een producent voor zichzelf de juiste labels kon selecteren, die dan eerst door een beheerder bevestigd moesten worden om officieel in de inventaris opgenomen te worden. Deze functionaliteit is wegens tijdgebrek echter niet aan de uiteindelijke applicatie toegevoegd.

4.4

Productgedeelte

Als laatste heb ik het productgedeelte aan het datamodel toegevoegd. Dit gedeelte omvat alle tabellen die informatie over de streekgebonden producten bevatten.

34

4.4.1

Producten

Figuur 20: Datamodel producten

Dit gedeelte van het datamodel bevat informatie over de streekgebonden producten zelf, zoals de naam, de beschrijving en de status. Net als voor de producenten, is er voor de producten wel ruimte voorzien in het datamodel om filmpjes, foto’s en commentaar toe te voegen, maar heeft geen van deze het gehaald tot de uiteindelijke applicatie. Ook de recepten zijn wel in het datamodel maar niet in de applicatie zelf aanwezig. Wat betreft de splitsing van de productgegevens in ‘product_products’ en ‘product_profiles’, de reden hierachter is dat de producent in staat moet zijn om de gegevens van zijn eigen producten aan te passen. Deze wijzigingen moeten vervolgens eerst goedgekeurd worden door de beheerder, voordat ze zichtbaar mogen worden in de inventaris. Door de gegevens die door de producent te wijzigen zijn, apart te zetten in de tabel ‘product_profiles’, kan bij een wijziging door de producent een ‘suggested_profile’ aan het product gelinkt worden. De gegevens hierin kunnen dan bevestigd worden door de beheerder, waarna ze gekopieerd worden naar het originele ‘product_profile’. In de inventaris wordt uiteraard alleen het bevestigde ‘product_profile’ getoond. Een andere opmerking is dat het attribuut ‘is_active’ in ‘product_products’ oorspronkelijk bedoeld was om ongeldige producten uit de inventaris te verwijderen, zonder daarom de productgegevens definitief te moeten verwijderen. Deze functionaliteit is later vervangen door de status ‘DELETED’, waardoor ‘is_active’ overbodig werd.

35

De tabel ‘product_highlights’ bevat geen informatie over de streekgebonden producten zelf. In plaats daarvan bevat ze een verwijzing naar één bepaald product, dat op de homepage van de website getoond wordt als ‘product in de kijker’. 4.4.2

Productcategorieën

Figuur 21: Datamodel productcategorieën

Elk product kan tot één of meerdere categorieën behoren, en elke categorie kan een subcategorie zijn van één of meerdere andere categorieën. In de inventaris wordt het product dan gerekend tot zijn rechtstreekse categorieën en al hun bovenliggende categorieën. Bij een zoekoperatie op elk van deze categorieën zal het product dus tevoorschijn komen.

36

4.4.3

Productcertificatie

Figuur 22: Datamodel productcertificatie

De informatie in deze tabellen is vooral van belang voor de beheerder van de webapplicatie, en in mindere mate voor de producenten. Wanneer een producent een product wil toevoegen aan de inventaris, moet hij eerst een aantal vragen over het product beantwoorden. Deze vragen worden opgehaald uit de tabel ‘certification_questions’. De antwoorden worden vervolgens opgeslagen in de tabel ‘product_answers’. Op basis van de informatie in deze antwoorden kan de beheerder van de inventaris de informatie in de tabel ‘product_certificationdata’ invullen. Ook kan hij voor elk van de vier criteria voor streekgebonden producten (zie hoofdstuk 1: streekgebonden product) aanvinken of het product er al dan niet aan voldoet. De criteria zelf zijn opgeslagen in de tabel ‘certification_criterions’. Als het product aan een bepaald criterium voldoet, wordt er voor dat product en dat criterium een rij aangemaakt in ‘product_criterions’. De tabel ‘certification_marks’ bevat de labels die aan een product toegekend kunnen worden. Sommige van deze labels, bijvoorbeeld ‘Erkend Traditioneel Vlaams Streekproduct’, moet de beheerder manueel aanvinken. De labels ‘Streekgebonden Product A’ en ‘Streekgebonden Product B’ worden door de applicatie automatisch toegekend op basis van de criteria waaraan het product voldoet.

37

4.4.4

Producentcertificatie

Figuur 23: Datamodel producentcertificatie

Sommige labels worden niet aan het product zelf, maar aan de producent ervan toegekend. Dit is met name het geval voor hoeveproducten. Als een producent het label ‘hoeveproducent’ heeft, moeten al zijn producten het label ‘hoeveproduct’ krijgen. Ik heb dit opgelost door aan de tabel ‘certification_marks’ een attribuut ‘name_producer’ toe te voegen. Bij het toevoegen van een producent wordt dan een selectievakje met de waarde van ‘name_producer’ getoond, voor alle labels waarbij dit attribuut niet NULL is – dit zijn de labels die aan een producent kunnen worden toegekend. Via de tabel ‘producer_certifications’ wordt bijgehouden welke labels een producent heeft. Wanneer binnen de applicatie dan de labels van een product worden opgevraagd, wordt er ook gecontroleerd of de producent bepaalde labels heeft. Deze labels worden dan gewoon mee teruggegeven alsof ze aan het product zelf gekoppeld waren.

38

4.5

Overige

Figuur 24: Datamodel overige

De tabellen ‘data_photos’, ‘data_movies’ en ‘data_comments’ waren oorspronkelijk bedoeld om informatie over foto’s, filmpjes en commentaar voor zowel producenten als producten op te slaan. Zoals hierboven reeds vermeld staat, is deze functionaliteit wegens tijdsgebrek niet aan de uiteindelijke applicatie toegevoegd. In de tabel ‘data_events’ worden de evenementen opgeslagen die op de homepage van de website getoond worden.

4.6

Aanmaken van de database

Voor de eigenlijke database heb ik het relationeel database management system ‘MySQL’ gebruikt. Deze beslissing is genomen in de loop van het vak ‘businessproject’ in het eerste semester van dit schooljaar, en stond al vast op het moment dat mijn stageperiode begon. De doorslaggevende argumenten waren hier het feit dat MySQL open source en gratis is, en de goede samenwerking met PHP. Tijdens het ontwikkelproces van het datamodel heb ik telkens een gedeelte klaar was, met de hand het SQL-script geschreven om de tabellen aan te maken. Ik verkies deze methode boven het gebruik van een GUI of automatische codegeneratie vanwege de extra controle die vanzelf gebeurt tijdens het typen van het script. Ik heb op deze manier nog verscheidene onvolmaaktheden en zelfs echte fouten in het datamodel kunnen oplossen. Vervolgens heb ik de database aangemaakt door de scripts uit te voeren via phpMyAdmin. Latere kleine aanpassingen aan de database heb ik via de GUI van phpMyAdmin uitgevoerd.

4.7

Invoeren van data uit de inventaris

Nadat de eigenlijke database aangemaakt was en in de applicatie de nodige functionaliteiten voorzien waren om de data te beheren, moesten de bestaande gegevens uit de inventaris nog ingevoerd worden in het nieuwe systeem. Dit kon niet op een geautomatiseerde manier gebeuren, om verschillende redenen. Ten eerste waren er bepaalde inconsistenties aanwezig in de producentgegevens, waardoor dezelfde producent mogelijk twee keer in de database ingevoerd zou worden. Daarnaast werd het label ‘hoeveproduct’ in de oude inventaris gezien als een productcategorie, terwijl het in de nieuwe versie een volwaardig label is. Alle hoeveproducten uit de oude inventaris moesten dus nog in een echte categorie ingedeeld worden. Omdat de categorie-indeling in de nieuwe versie van de inventaris

39

ook niet helemaal dezelfde was als daarvoor, waren er ook nog andere producten die een andere categorie moesten krijgen. Een derde probleem was dat in de oude inventaris sommige rijen meerdere producten bevatten, bijvoorbeeld ‘aardbeien, appelen en peren’. Deze rijen moesten gesplitst worden bij het invoeren in de database. Uiteindelijk heeft een medewerker van RURANT de meeste producenten uit de oude inventaris ingegeven in het nieuwe systeem. Diezelfde medewerker heeft ook een begin gemaakt met het ingeven van de producten, zodat ik deze kon gebruiken als testgegevens.

40

5

KOHANA PHP

In dit hoofdstuk geef ik wat meer informatie over mijn keuze voor Kohana en mijn ervaringen met het gebruik van dit framework.

5.1

Keuze van het framework

In de loop van het vak ‘businessproject’ in het eerste semester van dit schooljaar is besloten om als programmeertaal voor dit project PHP te gebruiken. Dit stond dus al vast op het moment dat mijn stageperiode begon. De keuze van het te gebruiken framework lag echter bij mij. Omdat er bij RURANT aan het begin van mijn stageperiode nog niets bekend was over wie de applicatie zou onderhouden na de stageperiode, kon ik hier bij mijn keuze geen rekening mee houden. Ook heb ik tijdens mijn opleiding nog geen ervaring opgedaan met het gebruik van een framework in PHP. Vorig jaar, toen ik in het tweede jaar zat, was het laatste jaar dat de tweedejaars nog PHP leerden zonder framework. Vanaf dit jaar gebruiken ze CodeIgniter. Ik heb voordat ik aan mijn stage begon op het internet wat opzoekwerk gedaan naar vergelijkingen tussen PHP-frameworks en uiteindelijk gekozen voor Kohana, een objectgericht maar ook licht framework.

5.2

Gebruik van Kohana

Omdat het framework me onbekend was, had ik in het begin van mijn stageperiode wat moeite met een goede stijl van programmeren te vinden die binnen het framework paste en dit optimaal kon benutten. Gaandeweg heb ik meer bijgeleerd over het gebruik van Kohana en de meer geavanceerde functies ervan. Hieronder bespreek ik enkele van de eigenschappen van dit framework. 5.2.1

Naming conventions

Kohana heeft een aantal naming conventions die in het begin vrij eigenaardig overkwamen. Zo moeten de namen van de klassen bestaan uit het pad naar de het bestand van klasse, gescheiden door underscores. Het bestand op de locatie ‘classes/controller/admin/user.php’ moest dus de klasse Controller_Admin_User bevatten. Dit principe assisteert Kohana bij het automatisch laden van de klassen, zonder dat er een ‘include’ of ‘require’ nodig is. Ik heb deze vorm van naamgeving doorgetrokken naar de namen van de tabellen uit de database (zie ook hoofdstuk 4: Datamodel en database, onder ‘Tabelnamen’). 5.2.2

Kohana ORM

Een Object Relational Mapping tool of ORM tool kan gebruikt worden om data uit een relationele database – zoals degene die ik gebruikte voor dit project – om te zetten naar echte objecten. Kohana heeft een optionele ORM-module, die ik gebruikt heb om de gegevens van de modellen uit de database op te halen. Achteraf bekeken heeft mijn gebruik van deze module tot veel problemen en tijdverlies geleid. De functies van Kohana ORM zijn vrij beperkt in vergelijking met wat ik gewend was door mijn ervaring in Java. Ik heb geprobeerd dit te compenseren door zelf extra functionaliteiten toe te voegen, maar uiteindelijk verloor ik hier meer tijd mee dan wanneer ik de data-accessfunctionaliteiten handmatig geprogrammeerd zou hebben, dus zonder gebruik van Kohana ORM.

41

5.3

Mijn eigen toevoegingen

Tijdens de loop van het project heb ik zelf eigen herbruikbare functionaliteiten toegevoegd of verder gebouwd op functionaliteiten die aanwezig waren in Kohana. Hieronder geef ik een aantal voorbeelden. 5.3.1

‘Model_Model’

‘Model_Model’ is de basisklasse van al de modellen in het project. Het is een extensie van de ‘Kohana_ORM’-klasse en voegt hier heel wat functionaliteit aan toe. Een beschrijving hiervan zou me te ver voeren, dus ik volsta met het voorbeeld van een simpele functie die een date- of datetime-attribuut uit de database automatisch omzet naar een instantie van Helper_Date (een andere eigen toevoeging). Aangezien het datamodel behoorlijk wat van dit type attributen bevat, heeft het automatisch oproepen van deze functie voor alle velden die eindigen op ‘_date’ me veel tijd bespaard (zie ook hoofdstuk 4: Datamodel en database, onder ‘Attribuutnamen’).

Figuur 25: De load_date_attribute()-functie

5.3.2

‘HTML::debug()’

Deze functie voert in principe gewoon een var_dump() uit, maar voegt hier de nodige opmaak aan toe om de informatie leesbaarder te maken. Later in mijn stageperiode heb ik hier ook functionaliteit aan toegevoegd om een leesbare versie van modelobjecten te kunnen printen, in plaats van het ellenlange resultaat van een standaard var_dump(). Deze functie heeft me erg geholpen bij het debuggen van de modelklassen.

42

Figuur 26: De HTML::debug()-functie

5.3.3

‘Helper_Menu’

‘Helper_Menu’ is een klasse die ik heb geschreven om het hoofd- en gebruikersmenu, het submenu en de breadcrumbs te genereren op basis van een config-bestand dat de menustructuur bevat. Het laat toe om eenvoudig wijzigingen aan te brengen in deze structuur zonder dat de code daarvoor op andere plaatsen aangepast moet worden.

43

Figuur 27: De functie om het hoofd- en gebruikersmenu te genereren

44

Figuur 28: Een gedeelte van de menustructuur

45

6

HOSTING

RURANT had in het begin van mijn stage nog geen webruimte ter beschikking om de applicatie te hosten. Tijdens mijn stageperiode moesten verschillende stappen ondernomen worden om dit te regelen.

6.1

Hosting via mijn eigen webruimte

Ik vond het handiger als het project zo snel mogelijk via het internet bereikbaar was, zodat mijn stage- en eindwerkbegeleider vanop afstand mijn voortgang konden volgen en zo nodig bijsturen. Bovendien kon ik veel gemakkelijker tools als de W3C Markup Validation Service gebruiken als de applicatie online stond. Omdat RURANT nog geen webruimte had en dit ook niet op korte termijn kon regelen, besloot ik om het project voorlopig via mijn persoonlijke provider te hosten. Aangezien ik nog ongebruikte schijfruimte en bandbreedte had, vormde dit voor mij geen enkel probleem.

6.2

Hosting op de servers van TPA

Ondertussen informeerde RURANT naar verschillende mogelijkheden voor hosting. RURANT is eigenaar van verschillende websites die via externe bedrijven gehost worden, maar voor Lekkers met Streken ging de voorkeur uit naar de servers van Toerisme Provincie Antwerpen (TPA), dat regelmatig nauw samenwerkt met RURANT en wel vaste IT-medewerkers in dienst heeft om de server te beheren. Het had behoorlijk wat voeten in de aarde voor er toestemming van bovenaf kwam om het project op de servers van TPA te hosten, waardoor men bij TPA pas drie weken voor het einde van mijn stageperiode kon beginnen met het gereedmaken van een server. De eigenlijke installatie daarvan werd ook nog een aantal malen uitgesteld, waardoor de server pas drie dagen voor het einde van mijn stage beschikbaar kwam. Het forwarden van het domein www.lekkersmetstreken.be werd pas de volgende dag in orde gemaakt. Ik had dus nog anderhalve dag tijd om het project op de nieuwe server te plaatsen.

6.3

Problemen met het overzetten van het project

Met behulp van WinSCP heb ik uiteindelijk de projectbestanden naar de nieuwe server geüpload. Ik had van tevoren de requirements van de applicatie doorgegeven aan TPA; hierdoor waren er gelukkig een minimum aan problemen bij het overzetten van het project. 6.3.1

Probleem met de permissions en .htaccess

Voor de goede werking van Kohana is het noodzakelijk dat het framework schrijfrechten heeft op de ‘cache’- en ‘logs’-mappen. Dit was na het overzetten van de bestanden niet meer het geval. Daarnaast maakt de applicatie gebruik van een .htaccess-bestand om door middel van URL rewriting het ‘index.php’-gedeelte uit de URL te verwijderen. Omdat .htaccess op de nieuwe server niet geactiveerd bleek te zijn, gaven alle links op de website – die immers geen van allen het ‘index.php’-gedeelte bevatten – een error wanneer erop geklikt werd. Beide problemen werden gelukkig snel opgelost na een mailtje naar TPA.

46

6.3.2

Probleem met het versturen van e-mails

Halverwege de laatste dag van mijn stageperiode kwam ik erachter dat het versturen van e-mails – noodzakelijk voor het resetten van gebruikerswachtwoorden – niet meer werkte vanaf de nieuwe server. Ondanks een mail naar de verantwoordelijke bij TPA, was dit nog steeds niet opgelost aan het einde van de dag. Ik heb zoveel mogelijk gegevens over het probleem doorgestuurd naar de verantwoordelijke bij TPA, zodat die een oplossing kan zoeken.

47

7

GRAFISCH DESIGN

Om de applicatie te kunnen publiceren, was het nodig dat ze er toonbaar en gebruiksvriendelijk uitzag in zoveel mogelijk verschillende browsers. Omdat Lekkers met Streken een merk met een bijbehorende eigen stijl is, moest het design van de webapplicatie hier zo goed mogelijk in passen. Bij het begin van mijn stage waren er voor Lekkers met Streken al een aantal ontwerpen van brochures, presentaties, ... als voorbeeld beschikbaar. De uiteindelijke beschrijving van de huisstijl liet echter nog op zich wachten. Daarom moest ik me aanvankelijk baseren op een voorbeeld-ontwerp van hoe een Lekkers met Strekenwebsite er zou kunnen uitzien. Toen ik tegen het einde van mijn stageperiode het uiteindelijke huisstijlhandboek in handen kreeg, werd duidelijk dat ik een groot deel van het tijdelijke design zou moeten herwerken om in overeenstemming te zijn met de regels van de huisstijl. In dit hoofdstuk geef ik wat meer informatie over dit proces.

7.1

Het tijdelijke design

Figuur 29: De homepage in het tijdelijke design

Het oorspronkelijke ontwerp van de webapplicatie heb ik in de eerste dagen van mijn stageperiode gemaakt. De bedoeling was dat de webapplicatie vanaf het begin zo dicht mogelijk bij de Lekkers met Streken-stijl zou aanleunen, zodat het voor RURANT duidelijk zou zijn hoe de uiteindelijke applicatie er zou uitzien. Hierdoor werd het makkelijker om feedback te geven. Dit design komt vrijwel volledig overeen met de print die ik kreeg als voorbeeld van hoe een website in de huisstijl er zou kunnen uitzien. Ik heb er wel een aantal zaken aan toegevoegd, zoals de breadcrumbs en het gebruikersmenu in de rechterbovenhoek. Ook de foto van de producten rechts bovenaan was anders dan in het originele ontwerp, doordat in deze versie een foto van echte streekgebonden producten gebruikt is. Het was de bedoeling om deze foto op termijn te vervangen door een andere foto van betere kwaliteit, die beter in het design zou passen. Omdat ik op dit moment nog niet wist in hoeverre ik het ontwerp zou moeten aanpassen om de huisstijl te volgen, heb ik in deze fase nog geen rekening gehouden

48

met verouderde – maar nog steeds veelgebruikte – browsers zoals Internet Explorer 7. De screenshots geven weer hoe het design eruit zag in een standards compatible browser zoals Mozilla Firefox of Google Chrome.

Figuur 30: De statusbeheerpagina in het tijdelijke design

7.2

De huisstijl

In de laatste weken van mijn stage kreeg ik uiteindelijk het huisstijlhandboek te zien. Bij lezing werd onmiddellijk duidelijk dat er een aantal moeilijkheden zouden zijn om het design hieraan aan te passen. 7.2.1

Kleurgebruik

Volgens de huisstijl mogen Lekkers met Streken-publicaties slechts gebruik maken van drie kleuren: wit, lichtbruin en donkerbruin. De twee bruintinten moesten steeds de exact opgegeven kleur zijn; ze mochten dus geen lichtere of donkerdere toonwaarde hebben. Hierdoor moest ik al een groot deel van het tijdelijke design aanpassen, aangezien ik hier veelvuldig gebruik had gemaakt van lichtere tinten bruin. Het voornaamste probleem met deze regel was dat de donkerbruine kleur volgens mij nog steeds te licht was om goed leesbaar te zijn op een computerscherm, zelfs tegen de witte achtergrond. Na verder informeren bij de maker van de huisstijl, bleek dat ik naast wit en bruin ook grijstinten mocht gebruiken. Ik heb de tekst dus in een donkere kleur grijs kunnen zetten. 7.2.2

Fonts

De huisstijl bevatte ook een regel dat als font Helvetica gebruikt moest worden. Op de meeste Windows-computers staat dit font echter niet geïnstalleerd. Bij verder doorvragen zei de maker van de huisstijl dat ik in dat geval Arial moest gebruiken. Het tijdelijke design gebruikte het font Open Sans, via Google Fonts. Dit font heeft verschillende gradaties van vette tekst, wat ik veelvuldig gebruikt had in titels en menu-items. Door Arial te gebruiken, zou ik deze mogelijkheden niet meer hebben. Uiteindelijk heeft RURANT toestemming gegeven om als font Open Sans te blijven gebruiken.

49

7.2.3

De boog onder het logo

In de huisstijl stond dat de bruine boog onder het logo gevormd moet worden door de bovenkant van een ovaal, die twee keer zo breed is als de drager. In het geval van een website is het echter onmogelijk de breedte van de drager te bepalen, gezien de oneindige mogelijkheden qua schermresoluties en venstergroottes. In het tijdelijke design had ik het probleem met die boog op grote schermresoluties al opgelost door de boog na een tijd te laten overgaan in een rechte lijn, die op elke schermresolutie toch doorliep naar de rand van het scherm (dit is ook zichtbaar in de screenshots van het uiteindelijke design). Ik heb besloten deze oplossing gewoon te behouden, bij gebrek aan een beter alternatief.

7.3

Het uiteindelijke design

Figuur 31: De homepage in het uiteindelijke design

Bovenstaande is een screenshot van het design zoals het in de uiteindelijke applicatie gebruikt zal worden. Ik heb het oude design aangepast aan de huisstijl door alleen de kleuren wit, het opgegeven licht- en donkerbruin, en een grijstint voor de tekst te gebruiken. Bovendien heb ik mijn eigen toevoegingen, zoals de breadcrumbs en het gebruikersmenu, meer in het design verwerkt. Daarnaast is de productfoto bovenaan de pagina verwijderd, aangezien er aan het einde van mijn stageperiode nog steeds geen geschikte foto beschikbaar was.

50

Figuur 32: De statusbeheerpagina in het uiteindelijke design

7.3.1

Browsercompatibiliteit

Omdat dit design ook echt door veel mensen gebruikt zal worden, heb ik het getest in en aangepast voor de meest populaire browsers, met name Mozilla Firefox, Google Chrome, Opera, en Internet Explorer 7 tot en met 9. In Internet Explorer 7 en 8 worden vierkante in plaats van ronde hoeken gebruikt, aangezien deze verouderde browsers deze functionaliteit niet ondersteunen. Bovendien zijn er in Internet Explorer 7 een aantal onvolmaaktheden, veroorzaakt door de vele bugs in deze browser. Ik heb me er echter van overtuigd dat alle onderdelen van de applicatie in elke browser bruikbaar zijn en dat er geen echt storende fouten zichtbaar zijn.

Figuur 33: Het uiteindelijke design in Internet Explorer 7

51

7.3.2

Validiteit

Tijdens het ontwikkelproces heb ik geregeld zowel de HTML- als de CSS-code gecontroleerd met behulp van de beschikbare validators. Al de HTML-code valideert als HTML5. De CSS-code valideert momenteel niet; dit komt doordat de validator op het moment van schrijven bepaalde CSS3-properties nog niet herkent.

Figuur 34: De HTML-code van de applicatie is valid HTML5

52

BESLUIT…. De afgelopen dertien weken heb ik voor RURANT vzw gewerkt aan de online inventaris van streekgebonden producten, onder de naam Lekkers met Streken. Ik heb een datamodel opgesteld, de bijbehorende database gecreëerd en een webapplicatie geschreven waarmee de data van de inventaris beheerd kan worden. Na afloop van mijn stageperiode bevat de webapplicatie de nodige basisfunctionaliteiten. Ik heb echter een aantal extra’s moeten laten vallen wegens tijdsgebrek. In de toekomst zal iemand anders het project moeten overnemen. Misschien zal dit stageverslag dan een hulp vormen om deze extra functionaliteiten alsnog toe te voegen. Tijdens deze stage heb ik heel wat bijgeleerd over databaseontwerp en ontwikkeling van webapplicaties in PHP. Vooral over het gebruik van Kohana heb ik nu veel meer kennis dan in het begin van mijn stage. Daarnaast heb ik in deze dertien weken ook een veel beter beeld gekregen van mijn eigen werktempo en van wat haalbaar is en wat niet. Als ik het opnieuw kon doen, zou ik waarschijnlijk veel beter in staat zijn om een haalbare planning op te stellen en me daaraan te houden. Als afsluiter kan ik zeggen dat ik blij ben met de ervaring die ik tijdens mijn stage op al deze vlakken opgedaan heb. Ik weet zeker dat die mij in mijn toekomstige job verder zal helpen.

53

LITERATUURLIJST Beleidsnota: Streekgebonden producten in de provincie Antwerpen. (2012). Opgehaald van http://www.rurant.be/mediafiles/351.pdf Conventions and Coding Style. (sd). Opgeroepen op 2012, van http://kohanaframework.org/3.2/guide/kohana/conventions Exploring Kohana as an Alternative to CodeIgniter. (sd). Opgeroepen op 2012, van http://onwired.com/blog/exploring-kohana-as-an-alternative-to-codeigniter/ Hoeve- en streekproducten. (sd). Opgeroepen op 2012, van http://www.rurant.be/hoeve-streekproducten Info productlabels. (sd). Opgeroepen op 2012, van http://www.lekkersmetstreken.be/page/info/certification#regional Inventaris van streekgebonden producten. (sd). Opgeroepen op 2012, van http://www.provant.be/ondernemen/hoeve-_en_streekprod/inventaris/index.jsp Kohana or CodeIgniter? (sd). Opgeroepen op 2012, van http://stackoverflow.com/questions/717836/kohana-or-codeigniter Kohana vs CodeIgniter, year 2011. (sd). Opgeroepen op 2012, van http://stackoverflow.com/questions/5559549/kohana-vs-codeigniter-year-2011 Plattelandsbeleid, D. L.-e. (sd). Beleidsnota: Streekgebonden producten in de provincie Antwerpen. Opgeroepen op 2012, van http://www.rurant.be/mediafiles/351.pdf Removing the index.php. (sd). Opgeroepen op 2012, van http://kerkness.ca/kowiki/doku.php?id=removing_the_index.php Toerisme Vlaanderen. (sd). Opgeroepen op 2012, van http://nl.wikipedia.org/wiki/Toerisme_Vlaanderen

54

BIJLAGE 1: DATAMODEL 7.3.3

Accountgedeelte

55

7.3.4

Producentgedeelte

56

7.3.5

Productgedeelte

57

7.3.6

Overige