Een nieuwe werkwijze

Er werd besloten om niet zoveel tijd meer te laten zitten in het uitwerken van

documenten. De stagiair wist af en toe niet zo goed hoe hij de verschillende documenten goed moest uitwerken en bleef vaak hangen op modellen of schema’s. De kennis binnen het bedrijf was ook niet voldoende om de stagiair hierbij te helpen en vanuit de opleiding werd er geen ondersteuning geleverd. Uit de verschillende boeken en de gegevens online werd de stagiair ook niet altijd veel wijzer. Door dit gebrek aan informatie verloren de documenten veelal hun waarde en kostten ze enorm veel tijd om uit te werken.

De nieuwe methode die zou worden toegepast was meer DSDM gericht. Er zou een ontwerp uitgewerkt worden, waarbij er rekening werd gehouden met de van tevoren opgestelde eisen. In het ontwerp waren vervolgens alle velden uitgewerkt die in het formulier opgenomen moesten worden en onder welke voorwaarde ze zichtbaar moesten zijn. Hierna werd het formulier in het systeem uitgewerkt en geprogrammeerd. Op verschillende plaatsen werd er in formulieren gebruik gemaakt van drop down listboxen.

De opbouw van deze drop down listboxen werd ondergebracht in een PHP-functie die gemakkelijk met een aantal variabelen aangeroepen kon worden.

Bij het uitwerken van de ontwerpen in het programma bleek echter dat er telkens gegevens door gegeven moesten worden tussen de iframes om de juiste aanvullende informatie daar op te halen. Hiervoor is uiteindelijk weer in elke tabel van de database een enkel attribuut toegevoegd als unieke sleutel, zodat alleen deze unieke sleutel doorgegeven hoefde te worden aan het volgende iframe. Dit was in de oude situatie ook al zo, maar officieel horen dit soort attributen niet thuis in een database en om die reden waren ze in het oorspronkelijke ontwerp voor de nieuwe database weggelaten. Het maakte het werken binnen een website echter wel een stuk eenvoudiger.

De opbouw van de menu’s zoals ze in figuur 7.7 te zien zijn, in de donker grijze blokken, is ook dynamisch en zowel de teksten als de acties die in het menu staan worden vanuit de database ingelezen.

Afstudeerverslag januari 2005

Pagina 36 van 267

Figuur 7.7: Edit content voorbeeld weergave 7.8.2 Het gebruik van brede functies

De verdeling van de code onder meerdere bestanden bleek ook een goede aanpak te zijn. Zo kon voorkomen worden dat een stuk code met een bepaalde functie niet twee keer aangepast moest worden als er iets aan die functie veranderde. Slechts op een plaats hoefde er in zo’n geval iets aangepast te worden en hierna was de functie op alle delen in het programma waar de functie werd gebruikt aangepast.

Dit had ook zijn nadelen, omdat een functie op sommige plaatsen soms enkele uitzonderingen had, waardoor er net even iets anders moest gebeuren. Dit werd opgevangen door extra variabelen die in zo’n geval er dan voor zorgden dat een extra deel in de functie uitgevoerd werd.

Doordat functies steeds meer uitgewerkt werden begonnen de formulieren ook steeds meer gelijkenissen te vertonen. Dit werkt gebruikersvriendelijkheid uitstekend in de hand. Een voorbeeld: het opbouwen van een pagina bestaat nog steeds uit het indelen van modules. Om nog opnieuw even een indruk te geven van modules kunnen dit één of meerdere logo’s zijn, een zoekfunctie, een menu, of een winkelwagentje. In de nieuwe situatie is het aantal echter niet meer beperkt tot drie kop regels, vier hoofdkolommen en twee voet regels. In een paginagroep is het mogelijk om de kop en de voet regels te vullen. Hierbij geldt dat er een onbeperkt aantal regels is aan te maken. In deze regels zijn vervolgens weer een onbeperkt aantal modules toe te voegen. Wel moet er rekening gehouden worden met het feit dat modules in een regel naast elkaar komen te staan. In de kolommen op een pagina worden de modules weer onder elkaar geplaatst.

In figuur 7.8 is een voorbeeld te zien van hoe de header, de kop van een pagina, is in te vullen met modules. In de onderste dikke balk, waar header in staat, zien we de knop waar nieuwe regels mee toe te voegen zijn. Modules zijn vervolgens in de rijen toe te voegen in een rij.

Hier zien we ook een goed voorbeeld van de eis dat de gebruiker alleen in beeld heeft waar hij op dat moment wat mee kan, of zou moeten doen. Na het selecteren van een modulegroep bijvoorbeeld zal de optie in beeld komen om een module te selecteren en een stijl voor de groep. Dit zien wij terug in figuur 7.9, waar een module is geselecteerd en er nog een is aangemaakt. Op een zelfde manier werkt het om een regel toe te voegen.

Afstudeerverslag januari 2005

Pagina 37 van 267

Figuur 7.8: Pagegroup settings, headers

De iconen die voor deze functies zijn ‘ontworpen’ zijn echter niet definitief, maar ter illustratie in elkaar gezet door de stagiair. Het echte ontwerp voor deze iconen zal achteraf door Koen Smits worden gemaakt.

De ‘up’ en ‘down’ knoppen in de balk van de moduleregel maken het mogelijk om de regels van volgorde te wisselen.

Figuur 7.9: Een module ingevuld en één toegevoegd.

Vervolgens moest er voor het invullen van de kolommen in de ‘page settings’ een soort gelijke functie uitgewerkt worden. Uiteindelijk is dit dezelfde functie geworden. Het hele deel om regels en kolommen met modules aan te maken is opgenomen in een functie die op sommige plaatsen een ander woord invult en in de database iets anders opslaat. Op database niveau gebruiken de tabellen ‘pagegroup’ en ‘page’ ook dezelfde twee

tussentabellen naar ‘modules’, namelijk ‘columnrow’ en ‘crmod’. In dit geval waren er twee tussentabellen nodig, omdat in een pagina, of paginagroep, meerdere kolommen, of regels, kunnen zitten, waarin meerdere modules voor kunnen komen. In de tabel

‘columnrow’ wordt er een onderscheiding in type gemaakt. Type 1 is dan een paginakolom, type 2 is een paginagroep header en type 3 een paginagroep footer.

Afstudeerverslag januari 2005

Pagina 38 van 267

7.8.3 De formulieren

Elk deel van het programma, dat in het hoofdmenu is opgenomen, bestaat uiteindelijk uit twee formulieren, één voor groepen en één voor items. Bij elk deel horen ook de

standaard mogelijkheden voor het aanmaken e.d. van groepen en items, zoals eerder is beschreven.

Een uitzondering hierop is het formulier voor ‘Site settings’. Dit is slecht een enkel formulier per taal waarin de klant zijn site kan aanbieden. De klant kan hier ook geen groepen of items toevoegen.

De hieronder genoemde formulieren zijn voor de opdrachtomschrijving, of daar buitenom geheel of gedeeltelijk uitgewerkt:

Contentgroep en content, Menugroep en menu

Multimediagroep, multimedia en upload, Modulegroep,

Pagegroup en page en Site.

Met gedeeltelijk uitgewerkt wordt bedoeld dat er nog een klein deel van kan ontbreken.

Voor content is bijvoorbeeld de mogelijkheid om een item een bepaalde leefduur mee te geven, waarna het gedeactiveerd wordt. De reden dat dit tijdelijk achterwege is gelaten is omdat het de wens is hiervoor een datumselectie programma uit te werken. De tijd die hiervoor nodig was, woog op dat moment niet op tegen het voordeel dat ermee te

behalen was. Ook had de opdrachtgever met de eerdere versie van Flexcite ervaren dat deze mogelijkheid ook niet zo vaak werd gebruikt.

7.8.4 Uitzonderlijk multimedia

Multimedia was een uitzondering met drie formulieren. Het toevoegen van een item in multimedia betekende het uploaden van een bestand. Om deze reden krijgt de gebruiker bij het aanklikken van ‘nieuw bestand’ een formulier te zien voor het uploaden. Bij het achteraf selecteren van een eerder toegevoegd bestand krijgt hij het formulier voor multimedia te zien.

Voor multimedia was ook in de systeemeisen opgenomen dat een klant een omschrijving moest kunnen toevoegen aan een bestand. Deze omschrijving werd ook een geval apart, omdat, in het formulier van multimedia, de mogelijkheid hiervoor gelijk zichtbaar moest zijn. Afgezien van deze omschrijving is multimedia verder taalonafhankelijk en zal de omschrijving voor elke taal waarover de klant beschikt in te vullen moeten zijn. Voor elk formulier geldt dat elk blok in een formulier is geprogrammeerd in HTML, met

uitzondering met het invullen van de velden, wat met PHP en MySQL gebeurt. In dit geval wordt uit de database geselecteerd welke omschrijvingen zijn toegevoegd, maar elke taal moet worden geplaatst. Met een ander soort selectie, een ‘right-join’, was het probleem op te lossen dat het plaatsen van het blok voor een omschrijving die nog niet was aangemaakt ook op het scherm verscheen. In andere gevallen was in het formulier ook de unieke sleutel van dat deel onzichtbaar opgenomen zodat dit in de ‘save’-module van het programma goed verwerkt zou worden. Echter hier waren er delen geplaatst die

figuur 7.10: Blok voor omschrijving

Afstudeerverslag januari 2005

Pagina 39 van 267

niet uit de database kwamen en dus geen sleutelwaarde hadden. Deze moesten bij het opslaan worden toegevoegd. En dat betekende een aanpassing in de ‘save’-module.

7.8.5 De ‘save’-module

De ‘save’-module is ontwikkeld voor het opslaan vanuit elk deel het programma en wordt uitgevoerd in het iframe ‘action’. Ook hier was er vaak sprake van uitzonderingen

waarvoor een deel toegevoegd of aangepast moest worden. Een voorbeeld hiervan is de omschrijving van een bestand in multimedia, die hierboven besproken is.

De velden van een formulier hebben een aantal instellingen als een naam, een type voor de stijl, en een waarde. In de veldnamen zitten vervolgens een aantal elementen

opgenomen die nodig zijn om op te slaan. De tabel word gespecificeerd, het identiteitsnummer en de naam van het attribuut in de database.

Door een aanpassing in de veldnamen van het formulier op te nemen kon de ‘save’-module deze speciale actie herkennen. Het identiteitsnummer kon in deze veldnamen niet opgenomen worden en werden herkenbaar gemaakt met een ‘*’. Ook gaan er drie letters aan de veldnaam vooraf; ‘dum’. Elke veldnaam die met deze drie letters begint, doorloopt niet de standaard procedure. Dit soort maatregelen werden er genomen om verschillen aan te kunnen pakken.

Deze ‘save’-module word aangesproken indien men klikt op save, save as copy of save and show. In de laatste twee gevallen moeten er meer acties uitgevoerd worden dan voor de eerste.

Een andere belangrijke uitzondering is het opslaan van bestanden. Er wordt daar niet alleen gewerkt met gegevens uit de database, maar ook met bestanden op de server. Als dit bestand geroteerd is, bijvoorbeeld, moet ook het bestand opnieuw opgeslagen

worden. Omdat de server voor dit programma onder het operating system UNIX werkt, vereiste dit enkele UNIX commando’s die in de PHP code onder gebracht moesten worden.

7.8.6 Iframe ‘action’

Eerder is al gesproken van het iframe ‘action’. Dit iframe is een klein iframe waarin een actie als save wordt uitgevoerd. Het bestand dat die functie uitvoert wordt dan in dat iframe geladen. De actie die het bestand vervolgens uitvoert is niet zichtbaar voor de gebruiker, maar feedback wordt wel doormiddel van een ‘animated-gif’, een bewegend plaatje, gegeven. Voorbeelden van deze plaatjes zijn gegeven in figuur 7.11. Deze plaatjes knipperen zodat het opvalt voor de klant.

Daarnaast wordt de actie in dit iframe wel zichtbaar gemaakt door de resultaten van de actie uit te schrijven in dit scherm. Echter doordat het iframe zo klein is, blijft deze informatie onzichtbaar voor de klant. Het is een zo genaamde achterdeur voor de programmeur. Indien men dubbel klikt op dit iframe, klapt deze uit en is de tekst leesbaar. Op deze manier is te zien wat er fout is gegaan, of juist dat alles is gegaan zoals het hoort.

Figuur: 7.11: feedback in het iframe ‘action’

Afstudeerverslag januari 2005

Pagina 40 van 267

7.8.7 Nieuwsfunctie

Wat eigenlijk niet tot de opdrachtomschrijving behoorde is het uitwerken van de nieuwsfunctie van Flexcite. Deze functie heeft tot doel klanten van het product op de hoogte te stellen van de nieuwste ontwikkelingen. In de oudere versie was dit een statische tekst op de hoofdpagina van het programma.

Tijdens het uitwerken van het deel van de database waarin de teksten voor het systeem werden opgeslagen, kwam hier ook het onderwerp naar boven om het nieuws ook hierin op te slaan. Dit is uiteindelijk gebeurt nadat er een type aan deze teksten werd

toegevoegd, zodat niet alle teksten overal werden geladen.

De stagiair had vervolgens in zijn vrije tijd een functie uitgewerkt voor zijn eigen website om afbeeldingen weer te geven op zijn site. Dit inspireerde hem om hetzelfde concept te gebruiken om de nieuwsberichten uit te lezen en op te bouwen.

Figuur 7.12: Flexcite nieuws

Voor een speciale groep afbeeldingen werd er uiteindelijk een instelling aangemaakt waardoor de keuzemogelijkheid voor het bekijken van deze afbeeldingen binnen ‘Edit multimedia’ alleen zichtbaar was voor de programmeurs van Flexcite, indien ingelogd onder een specifieke naam.

Zo rond het eind van de afstudeerperiode maakte de stagiair nog een deel bij de

nieuwsfunctie waarbij hij gebruik maakte van dezelfde instelling. Dit nieuwe deel maakte het mogelijk om via een formulier een nieuwsbericht toe te voegen aan de lijst.

Dit is verder allemaal in de vrije tijd gemaakt en hierbij is niet echt een ontwerpfase aan vooraf gegaan. De functie is er ook een, die alleen toegankelijk is voor de programmeurs en het voornamelijk voor hen gemakkelijker is dat deze functie bestaat. Voor de klant heeft deze functie mogelijk alleen de uitwerking dat Flexcite zelf ook dynamisch is.

Afstudeerverslag januari 2005

Pagina 41 van 267

8. Het testen van Flexcite

Dit hoofdstuk gaat wat meer in op enkele technische details van het programmeer werk.

Op deze manier kan duidelijk gemaakt worden hoe het systeem in elkaar zit en waar de problemen naar boven zijn gekomen. Testen is iets wat door het hele project is gedaan.

Uiteindelijk zijn er ook nog testen gedaan aan het eind van de afstudeerperiode. Deze laatste testen zouden gedaan worden in drie fasen, welke we in het tweede deel van dit hoofdstuk zullen beschrijven.

8.1 Testen tijdens het programmeren

Tijdens het programmeren is er veel getest. Telkens als een deel van het systeem was ontwikkeld werd het systeem op dat deel ook getest. Het kwam echter ook wel eens voor dat er pas op een later moment problemen boven water kwamen. Bijvoorbeeld als er ergens iets was veranderd, of als er een vreemde handeling werd uitgevoerd. Ook een bepaalde volgorde van handelingen kon problemen naar voren brengen. Al deze

problemen werden genoteerd als het een onbekende oorzaak had. Indien de oorzaak van het probleem wel duidelijk was kon dit probleem gelijk aangepakt worden als de

aanpassing niet te veel tijd zou kosten.

8.1.1 Kleine problemen

De meeste problemen die naar boven kwamen hadden vaak te maken met een simpele vergissing in de code. Een stuk code dat niet goed afgesloten was met een accolade, was veelal het probleem. Het programma van Macromedia, Dreamweaver, gebruikt kleuren om de code beter leesbaar te maken. De programmeurs lieten de code inspringen om deze nog beter leesbaar te maken. Dit maakte het doorzoeken naar fouten

gemakkelijker. Een voorbeeld van de code in Macromedia Dreamweaver is opgenomen in figuur 8.1.

Figuur 8.1: Voorbeeld van kleurcodering in Macromedia Dreamweaver.

Afstudeerverslag januari 2005

Pagina 42 van 267

Er zijn meerdere programma’s die ook dit soort kleurcodes gebruiken. De meeste HTML-editors werken hiermee. Macromedia Dreamweaver is een zeer goed uitgerust

programma die onder andere ook over een FTP-functie beschikt.

8.1.2 Problemen met ‘Div’-tags

Niet altijd was een fout makkelijk te vinden en meestal moest dan de broncode van de website doorzocht worden op de opbouw. Meestal was er in zo’n geval een zogenaamde

‘div-tag’ niet afgesloten, waardoor de website ‘vertekend’ werd. Het programma is opgebouwd met enorm veel verschillende ‘div’s’. Deze ‘div’s’ kunnen het beste gezien worden als blokken informatie die onder bepaalde voorwaarden wel of niet gevuld zijn.

Ze werden gebruikt als een soort iframe en gevuld of geleegd met een JavaScript code die bestanden uitlas. De code uit dat bestand werd dan uitgewerkt in de ‘div’.

Een voorbeeld van een probleem dat zich kan voordoen, indien een ‘div’ niet goed wordt afgesloten, is dat bij het legen van een blok meer verwijderd worden van het scherm dan de bedoeling is. Dit voorbeeld wordt gevisualiseerd in figuur 8.2. Indien de rode ‘</div>’ wordt vergeten wordt het 1^e blok pas afgesloten bij de blauwe ‘</div>’ en verdwijnt bij het legen van de eerste ‘div’ ook de informatie van het 2^e blok.

Ook is het een stuk moeilijker om de broncode van zo’n ‘div’ te bekijken. De code om de ‘div’ te vullen wordt er pas ingezet nadat de website al volledig is geladen. De broncode van de website wordt echter niet gewijzigd indien er een ‘div’

gevuld of geleegd wordt met JavaScript, na een handeling van de gebruiker.

Om de HTML code te kunnen lezen, die door een PHP bestand wordt geschreven, nadat deze wordt aangeroepen door de JavaScript code, moet het PHP bestand in de browser worden aangeroepen.

Hierbij moeten de juiste variabelen meegegeven worden in de link, de URL. Dit klinkt net zo ingewikkeld als het werkelijk is, omdat het bij elkaar zoeken van die variabelen meestal door de JavaScript functie wordt uitgevoerd. Ook zijn er voor sommige bestanden een flink aantal

variabelen nodig om de PHP code uit het bestand succesvol uit te kunnen voeren. Pas nadat deze handeling succesvol is uitgevoerd kan de HTML code, die dan gegenereerd is, gelezen worden.

Een voorbeeld van zo’n link is dan bijvoorbeeld:

‘http://www.flexcite.nl/edit/20site/getgroups.php?group=cn_here&curLng=uk&curId=16’

Het bestand dat normaal gesproken in een ‘div’ wordt uitgevoerd is in dit geval

‘getgroups.php’. In deze link zijn vervolgens drie variabelen opgenomen: ‘group’, ‘curLng’

en ‘curId’. Deze link werkt nu echter niet meer, omdat het bestand inmiddels een andere naam heeft gekregen. Hij haalt namelijk de items binnen een groep op, maar dat is verder niet ter sprake. Sommige van deze links hadden nog veel meer variabelen nodig, maar gelukkig was het niet altijd nodig om de HTML code te kunnen bekijken.

<div>

Figuur 8.2: Voorbeeld div info

Afstudeerverslag januari 2005

Pagina 43 van 267

8.1.3 Aanpassingen op de database

Bij de start van het programmeren was het nog niet altijd even duidelijk hoe een volgend deel geprogrammeerd zou worden. Hierdoor was het af en toe nodig om verbeteringen aan te maken in de database. Uiteraard hadden deze wijzigingen ook wel eens een effect op de al bestaande code. Meestal direct na het aanpassen van de database werd de code

Bij de start van het programmeren was het nog niet altijd even duidelijk hoe een volgend deel geprogrammeerd zou worden. Hierdoor was het af en toe nodig om verbeteringen aan te maken in de database. Uiteraard hadden deze wijzigingen ook wel eens een effect op de al bestaande code. Meestal direct na het aanpassen van de database werd de code

In document Afstudeerverslag. 14 januari Mw. J.M.A. Ruigt (pagina 35-0)