Ontwerp van een summerschoolwebsite in Drupal

Ontwerp van een summerschoolwebsite in Drupal Stefanie Samaey

Promotor: prof. dr. ir. Koen De Bosschere Begeleiders: Klaas Millet, Wouter De Raeve Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica

Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

Dankwoord Hierbij zou ik graag iedereen bedanken die mij geholpen heeft bij het realiseren van de masterproef, en het voltooiien van deze opleiding. In de eerste plaats zou ik mijn promotor, Prof. Dr. Ir. Koen De Bosschere willen bedanken voor de kans deze masteproef te maken. Speciale dank gaat ook naar mijn thesisbegeleider Klaas Millet voor de geboden hulp het afgelopen jaar, en de vele suggesties die deze masterproef in de juiste richting stuurden.

i

Toelating tot bruikleen

De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.

Stefanie Samaey, 2 september 2010 ii

Universiteit Gent Faculteit Ingenieurswetenschappen Vakgroep Elektronica en Informatiesystemen

Ontwerp van een summerschoolwebsite in Drupal Stefanie Samaey

Promotor: prof.dr. Koen De Bosschere Begeleider: Klaas Millet, Wouter De Raeve Masterproef ingediend tot het behalen van de academische graad van Master in de Toegepaste informatica Academiejaar 2009-2010

Samenvatting In het kader van het Europees project HiPEAC wordt jaarlijks een summerschool georganiseerd. Rond deze activiteit werd een 5-tal jaar geleden een website ontwikkeld. Deze website, gebouwd met behulp van php, bevat reeds een aantal functionaliteiten, zoals lestoewijzing en inschrijvingsmoderatie,... Maar de onderliggende structuur, zowel de databank als de website, heeft echter een aantal tekortkomingen die een verdere ontwikkeling of uitbreiding bemoeilijken. Het doel van deze masterproef bestaat erin om deze website te herontwerpen in Drupal. Hiertoe werd een nieuwe drupalmodule ontwikkeld, die gebruik maakt van de reeds aanwezige functionaliteiten (gebruikersadministratie,...) in de overkoepelende website. Het resultaat is terug te vinden op http://trappist.elis.ugent.be/~sksamaey/acaces/. Trefwoorden: CMS, Drupal, summerschool, website iii

Inhoudstafel DANKWOORD ................................................................................................................................................... I TOELATING TOT BRUIKLEEN ............................................................................................................................. II ONTWERP VAN EEN SUMMERSCHOOLWEBSITE IN DRUPAL ............................................................................ III INHOUDSTAFEL ............................................................................................................................................... IV TABEL VAN AFKORTINGEN .............................................................................................................................. VI LIJST VAN TABELLEN ....................................................................................................................................... VII LIJST VAN FIGUREN ....................................................................................................................................... VIII HOOFDSTUK 1 – INLEIDING .............................................................................................................................. 1 1.1

PROBLEEMSTELLING: SUMMERSCHOOLWEBSITE ................................................................................................ 1

1.2

CMS EN DRUPAL........................................................................................................................................ 1

1.3

WERKWIJZE ............................................................................................................................................... 1

1.4

OPBOUW VAN DE SCRIPTIE ........................................................................................................................... 2

HOOFDSTUK 2 - KERNFUNCTIONALITEIT VAN DRUPAL ..................................................................................... 3 2.1

CONTENT MANAGEMENT SYSTEM ................................................................................................................. 3

2.2

HET GEBRUIK VAN DRUPAL ........................................................................................................................... 3

2.3

SAMENWERKING TUSSEN MODULES................................................................................................................ 5

HOOFDSTUK 3 – SUMMERSCHOOLWEBSITE: OPBOUW .................................................................................... 6 3.1

DOELSTELLINGEN: SUMMERSCHOOL? ............................................................................................................. 6

3.2

DE VEREISTEN ............................................................................................................................................ 7

3.2.1

Registratieverwerking en registratiebeheer ...................................................................................... 7

3.2.2

Opbouw en onderhoud ...................................................................................................................... 8

3.2.3

Onze oplossing................................................................................................................................... 9

3.3

USE-CASE-DIAGRAM.................................................................................................................................. 10

3.3

DE DATABANK .......................................................................................................................................... 11

HOOFDSTUK 4 – DE SUMMERSCHOOL MODULE............................................................................................. 18 4.1

DE BESTANDEN VAN EEN DRUPAL-MODULE.................................................................................................... 18

4.2

SUMMERSCHOOL.MODULE ......................................................................................................................... 18

4.3

DRIELEDIGE FUNCTIONALITEIT ..................................................................................................................... 20

4.3.1

Een summerschool creëren.............................................................................................................. 20

4.3.2

De registratiepagina ........................................................................................................................ 25

4.3.3

Summerschool management: het beheren van de registraties ....................................................... 33

iv

HOOFDSTUK 5 – INSTALLEREN, CONFIGUREREN EN INGEBRUIKNAME ........................................................... 37 5.1

DRUPALINSTALLATIE .................................................................................................................................. 37

5.2

OPTIONELE MODULES ACTIVEREN................................................................................................................. 37

5.3

EEN THEMA KIEZEN ................................................................................................................................... 37

5.4

INGEBRUIKNAME VAN DE DRUPAL-MODULE ................................................................................................... 38

5.5

AFWERKING............................................................................................................................................. 38

HOOFDSTUK 6 – CONCLUSIE ........................................................................................................................... 39 RESULTAAT ........................................................................................................................................................... 39 PROCES ............................................................................................................................................................... 39 TOEKOMSTPERSPECTIEVEN ...................................................................................................................................... 40

v

Tabel van afkortingen ACACES

Advanced Computer Architecture and Compilation for High-Performance and Embedded Systems

CMS

Content Management System

CSS

Cascading Style Sheets

HiPEAC

European Network of Excellence on High Performance and Embedded Architecture and Compilation

PHP

Hypertext preprocessor

SQL

Structured Query Language

vi

Lijst van Tabellen Tabel 1 en 2 – hipeac en hipeacss_price ............................................................................. 12 Tabel 3 en 4- hipeacss_timeslot en hipeacss_courses ........................................................ 13 Tabel 5 - hipeacss_node ............................................................................................... 13 Tabel 6 en 7- hipeacss_reg en hipeacss_reg_course .......................................................... 14 Tabel 8 en 9 - hipeacss_files en hipeacss_posters .............................................................. 16 Tabel 10 en 11- hipeacss_mail en hipeacss_audience ........................................................ 16 Tabel 12 - Registratiestatussen ........................................................................................... 30

vii

Lijst van figuren Figuur 1 - Use-case diagram ................................................................................................ 10 Figuur 2 - Summerschool Configuration.............................................................................. 22 Figuur 3 - Summerschool Configuration: Create a summerschool ..................................... 23 Figuur 4 - Summerschool Configuration: Edit a summerschool .......................................... 23 Figuur 5 - Summerschool Configuration: Dagdeel aanpassen ............................................ 24 Figuur 6 - Summerschool Configuration: Cursus toevoegen............................................... 24 Figuur 7 - Summerschool Configuration: Cursus aanpassen ............................................... 25 Figuur 8 - Node view: Flowchart.......................................................................................... 27 Figuur 9 - Node view: Register Here (a) .............................................................................. 28 Figuur 10 - Node view: Register Here (b) ............................................................................ 29 Figuur 11 - Node view: Register Here (c) ............................................................................. 29 Figuur 12 - Node view: persoonlijke registratipagina (pending) ......................................... 31 Figuur 13 - Node view: persoonlijke registratipagina (approved) ...................................... 31 Figuur 14 - Node view: persoonlijke registratipagina (finished) ......................................... 32 Figuur 15 - Node view: persoonlijke registratiepagina (poster).......................................... 33 Figuur 16 - Email management: gebruikersgroep kiezen .................................................... 35 Figuur 17 - Email management: bestemmelingen kiezen ................................................... 36

viii

Hoofdstuk 1 – Inleiding 1.1 Probleemstelling: summerschoolwebsite HiPEAC1 (het ‘European Network of Excellence on High Performance and Embedded Architecture and Compilation’) werd opgericht om het onderzoek in dit domein te sturen, en de samenwerking tussen de onderzoekers en de industriële sector te bevorderen. Dit netwerk organiseert verscheidene activiteiten met betrekking tot hun onderzoeksdomein. Hieronder vallen ‘computing system weeks’, jaarlijkse conferenties, en Summerschools. Bij de organisatie van de summerschool werd de voorbije jaren gebruik gemaakt van een reeds bestaande website. De studenten kunnen zich er registreren, en deze registraties worden met behulp van uitgebreide beheerspagina’s opgevolgd en beheerd. Maar vooral het jaarlijks updaten van de website, was voor de beheerder van deze site niet eenvoudig. In deze context gaat men op zoek naar een nieuwe website voor de jaarlijkse summerschool. De nieuwe website moet gemakkelijk te integreren zijn in het overkoepelende HiPEAC-systeem, en ze moet op een relatief eenvoudige manier jaarlijks te hergebruiken zijn. De belangrijkste functies die deze website moet vervullen zijn het meedelen van de praktische informatie over de summerschool, en het beheer van de registraties van deze activiteit.

1.2 CMS en Drupal Voor de ontwikkeling van deze website werd gebruik gemaakt van het open source content management system Drupal. Dit CMS steunt op het principe van samenwerkende modules, thema’s, ontwikkeld door de wereldwijde Drupal-community. Aanwezige functionaliteiten zoals een goed uitgewerkt gebruikersbeheer, het eenvoudig publiceren van nieuwe inhoud, en dergelijke meer kunnen we zeker gebruiken,

1.3 Werkwijze Het doel van deze masterproef bestaat er met andere woorden in om een nieuwe summerschool module te ontwikkelen, te implementeren in een overkoepelende Drupal1 - Inleiding

1

website. Zodat deze module in de toekomst kan gebruikt worden, op een eenvoudige manier, om de jaarlijkse summerschool websites te ontwerpen. Naast het voorzien van de benodigde functies in de afzonderlijke module, moet de module ook nog geïnstalleerd worden, en dient men de site op een gepaste manier te configureren. Hierbij wordt beroep gedaan op enkele andere verkrijgbare Drupalmodules, en wordt een eigen Drupal-thema ontwikkeld en geïnstalleerd.

1.4 Opbouw van de scriptie In het volgende hoofdstuk wordt dieper ingegaan op wat Drupal precies is, en welke kernfunctionaliteiten voor onze website van belang zijn. Hoofdstuk 3 handelt over de opbouw van de gehele website. Hiervoor gaan we eerst op zoek naar wat een summerschool precies is, en welke vereisten nodig zijn om deze website te ontwerpen. Daarnaast vinden we in deze sectie ook een use-case diagram een een databank-overzicht. In hoofdstuk 4 gaan we dieper in op de details van de ontwikkelde summerschool-module. Terwijl we in het laatste hoofdstukje overlopen hoe men deze module kan gebruikern. Ten slotte volgt eer een kort

besluit waarin we het resultaat en enkele

toekomstmogelijkheden bespreken.

1 - Inleiding

2

Hoofdstuk 2 - Kernfunctionaliteit van Drupal 2.1 Content Management System Een content management system is een systeem dat het mogelijk maakt om op een eenvoudige manier dynamische gegevens te publiceren en te beheren op het internet. De voordelen van een dergelijk systeem zijn onder meer de aanwezigheid van enkele basisfunctionaliteiten zoals bijvoorbeeld het gebruikersbeheer. Het vergt enige inwerking of ervaring om een dergelijke website op te zetten, te configureren en alle functionaliteiten te implementeren. Maar eens het systeem op punt gesteld, kan men als beheerder op een relatief eenvoudige manier het systeem gebruiken en beheren. Drupal, gepubliceerd onder een open-source licentie, is het systeem dat hier gebruikt werd. Dit systeem werd oorspronkelijk ontwikkeld door Dries Buytaert (vanaf 2000), en is de afgelopen tien jaar uitgegroeid tot een systeem gedragen door een wereldwijde gemeenschap, die actief bijdraagt tot de verdere ontwikkeling van modules, thema’s, en de Drupal core zelf.2 Aangezien de site waarvoor de summerschoolmodule dient ontwikkeld te worden, met Drupal 5 werd gemaakt, heb ik er ook voor gekozen. Om up to date te blijven leek uiteindelijk Drupal 6 een logischere keuze. Het converteren van de module, bood zelfs enkele nieuwe inzichten in het systeem.

2.2

Het gebruik van Drupal

Het besturingssysteem maakt op zich weinig uit, Drupal werkt op elke besturingssysteem waarop PHP geïnstalleerd kan worden3. De aangeraden webserver is Apache en als databankserver MySql. Alternatieven zijn echter ook mogelijk. Drupal is geprogrammeerd in PHP, wat het voor velen mogelijk maakt om zelf modules en themas te coderen of aan te passen. Het wordt sterk aangemoedigd om je eigen bijdragen te publiceren op de Drupal-website. Om de codes van al deze bijdragen leesbaar te houden wordt gevraagd aan de ontwikkelaars om zich aan de zogenaamde coding standards te houden4. Zoals bijvoorbeeld het gebruik van spaties en commentaren. 2 - Kernfunctionaliteit van Drupal

3

Het Drupal-framework is te downloaden via Drupal.org. De reeds aanwezige functionaliteiten, naast een basis CMS, zijn onder meer: gebruikersbeheer, sessiebeheer en logging. Drupal is een modulair opgebouwd systeem. Elke functionaliteit wordt door een eigen module vervuld. Er zijn in totaal vijf core-modules, die ingeschakeld moeten zijn om het syteem te doen werken: block, filter, node, system, users en watchdog. Daarnaast worden er nog enkele andere modules standaard meegeleverd, o.a.: blog, forum en path. Een aantal modules die kenmerkend zijn voor elke drupal-site, zijn de volgende:  Block Deze module beheert de blokken, dit zijn groepen gerelateerde informatie, zoals bijvoorbeeld de menu-items, die op bepaalde plaatsen rond de hoofdinhoud (sidebar, header,...) getoond worden.  Node De belangrijkste elementen in een drupal-site zijn de nodes: alle inhoud wordt opgeslagen in nodes. Een node is met andere woorden het basis-inhoudstype. Standaard node-types in een drupal-site zijn bijvoorbeeld pages, blogs, stories, forums. Daarnaast kan je nog types toevoegen met afzonderlijke modules, of zelf nodes ontwikkelen. Ook voor de summerschool wordt een afzonderlijk node-type gedefinieerd. De node module beheert deze inhoudstypes. De inhoud van de nodes wordt op de site zelf ingevuld en weergegeven, en kan er ook gewijzigd of verborgen worden.  User De gebruikersmodule maakt het mogelijk voor gebruikers om zich te registreren, in- en uit te loggen. Aan zo'n account worden onder meer gekoppeld: inhoud gepubliceerd door de user, specifieke rollen, een profiel... Op de gebruikersbeheerpagina's worden de toegangsrechten, profielen en rollen beheerd. De eerste user, aangemaakt bij het creëren van de site, de zogenaamde superuser, bezit alle rechten. Een rol verzamelt een aantal rechten, en biedt zo de mogelijkheid om de gebruikers te groeperen. Op de basis drupal-site zijn er twee rollen: ‘anonymous user’ en 2 - Kernfunctionaliteit van Drupal

4

‘authenticated user’. Wij zullen een derde rol, ‘summerschool admin’ toevoegen. Met deze rol kan de summerschool beheerder alle taken vervullen die nodig zijn om all summerschool informatie te delen, en om de binnenkomende registraties te beheren.

2.3

Samenwerking tussen modules

Een modulair opgebouwd systeem zou veel van zijn mogelijkheden verliezen als de modules niet zouden kunnen samenwerken. In Drupal gebeurt dat aan de had van zogenaamde hooks. Hooks zijn functies die een module de mogelijkheid bieden om met andere modules van de Drupal-core te interageren, om beroep te doen op hun diensten als het ware.5 In de volgende sectie komen specifieke voorbeelden aan bod die dit principe verduidelijken.

2 - Kernfunctionaliteit van Drupal

5

Hoofdstuk 3 – Summerschoolwebsite: opbouw In deze sectie gaan we dieper in op de opbouw van de website: eerst overlopen we de verschillende onderdelen van een summerschoolwebsite, vervolgens bekijken we verschillende manieren waarop we met deze onderdelen een website kunnen ontwerpen, hen halen we hieruit de vereisten en doelstellingen. Deze vereisten bundelen we in een use-case diagram. Daarnaast kijken we naar de opbouw van de database die ontworpen werd om de doelstellingen te bereiken.

3.1

Doelstellingen: summerschool?

De belangrijkste onderdelen van deze activiteit worden hieronder kort besproken:  Cursussen (courses) Lijk vanzelfsprekend, tijdens een summerschool worden er cursussen gedoceerd. In ons voorbeeld zijn er twaalf verschillende cursussen.  Dagdelen (timeslots) Deze cursussen worden gegroepeerd volgens dagdeel: het moment van de dag waarop de cursus gegeven wordt. In ons voorbeeld zijn er 4 dagdelen, met elk drie verschillende cursussen waaruit de deelnemer kan kiezen  Lesgevers De lesgevers doceren de cursussen.  Beheerder De beheerder zien we hier als persoon die de website publiceert, de inhoud bepaalt en ervoor zorgt dat de registraties op de juiste manier behandeld worden. In werkelijkheid kunnen deze taken door meerdere personen gebeuren.  Deelnemer De deelnemer volgt een aantal cursussen van de summerschool.

3 - Opbouw van de website

6

Het doel van deze website drieledig.  Men wil aan de hand van deze website de informatie (de cursussen, de data, de uren, de plaats, de lesgevers,…) in verband met deze activiteit communiceren,  maar ook de bezoekers van deze website, de potentiële deelnemers, de kans geven om zich te registreren, 

3.2

en ten slotte dient deze website als applicatie om deze registraties te beheren.

De vereisten

Om voor deze activiteit een website te ontwerpen, kan men kiezen uit verschillende manieren. Eerst zal ik dieper ingaan op de verschillende soorten aanpak die er bestaan om de registraties en het registratiebeheer te organiseren. Vervolgens worden de verschillende manieren om dergelijke website te onderhouden besproken.

3.2.1 Registratieverwerking en registratiebeheer Men kan deze functie vervullen op een eenvoudige manier door bijvoorbeeld een afzonderlijk registratieformulier ter beschikking te stellen op de website, en de deelnemers te vragen om deze ingevuld door te sturen. Een gelijkaardige manier is het weergeven van een registratieformulier op de website en het op die plaats laten invullen en doorsturen, maar dat deze inschrijving bijvoorbeeld toekomt in de inbox van de registratiebeheerder. De eerste oplossing is weinig gebruiksvriendelijk voor de deelnemer, de tweede oplossing lijkt beter. Maar beide manieren zijn omslachtig voor de registratiebeheerder, aangezien de registraties in allebei de gevallen manueel in het systeem gevoerd worden. Ten eerste wordt er dubbel werk geleverd: de beheerder moet hetzelfde aanduiden in het systeem, wat de deelnemer reeds deed in het inschrijvingsformulier. Ten tweede wordt de kans op fouten hierdoor vergroot, bij het ingeven van de registraties in het systeem moet diegene die dit werk vervult, zeer alert zijn. Bij een derde oplossing wordt de registratie, bij het ingeven van de gegevens door de deelnemer, automatisch opgeslagen in het systeem. Deze manier is gelijkaardig aan de 3 - Opbouw van de website

7

werking van de huidige summerschoolwebsite. Voordelen zijn dat het dubbel werk, en dus ook de kans op fouten, verdwijnen. Een nadeel is dat er, net als bij de vorige manieren, een kans bestaat dat bepaalde personen zich dubbel inschrijven, na bijvoorbeeld een eerste foutieve inschrijving, aangezien hier geen controle op bestaat. Ook hier moet de beheerder dus alert blijven bij het goedkeuren van de inschrijvingen. Een vierde mogelijkheid is dus dat de deelnemer zich, nog voor de definitieve summerschoolregistratie, moet registreren in inloggen in het systeem. Elke persoon wordt gekoppeld aan één account, en kan zich dus maar één keer inschrijven per activiteit. Een tweede voordeel hierbij is dat de deelnemer zelf de controle heeft over zijn persoonlijke gegevens. De voorwaarden met betrekking tot het registratiebeheer die we uit bovenstaande alinea’s kunnen halen zijn dus:  De deelnemer moet een account kunnen aanmaken  Het registratieformulier moet op de website zelf in te vullen zijn  De inhoud van het registratieformulier wordt automatisch opgeslagen in het systeem 

De beheerder moet deze registraties kunnen goedkeuren.

3.2.2 Opbouw en onderhoud Ook hier zijn verschillende oplossingen mogelijk. De huidige website biedt wel een uitgebreide interface om de registraties te beheren, maar het ontbreekt aan een eenvoudige mogelijkheid om de site jaarlijks up te daten. Hierdoor is het wel mogelijk om een summerschool te beheren zonder uitgebreide technische kennis. Maar is het moeilijk om de website zelf te beheren. De beheerder van de website is vaak de enige die heel goed weet hoe de website ineen zit, hoe ze werkt. Hierdoor is het vaak problematisch voor anderen om de website te onderhouden en up te daten.


8

Voorbeeld: in de vorige website kon men de ‘audiences’, de gebruikersgroepen aan wie men een e-mail wil sturen, in het mailmanagement gedeelte, opslaan door de WHEREclause van de SQL-query in te geven. In deze oplossing wordt getracht om de gewenste gebruikersgroep in te geven aan de hand van een formulier. De voorwaarden die we hieruit besluiten zijn met andere woorden dat:  De website moet voorzien zijn van een mogelijkheid om zonder uitgebreide technische kennis en inwerking in het systeem, jaarlijks hergebruikt te worden. 

De website moet, net zoals de vorige website, een interface bezitten om de registraties te beheren.

3.2.3 Onze oplossing Uit deze situatieschets kunnen we besluiten dat het gebruik van een content management system is in dit geval zeker aan te raden is. Op deze manier kunnen de verschillende activiteiten eigen webpagina’s behouden, maar worden deze toch beheerd onder hetzelfde systeem. Deze oplossing is aantrekkelijk om dit complexe systeem door meerdere mensen (op een eenvoudige manier) te laten beheren. Ook voor de bezoekers zijn er een aantal voordelen aan verbonden. Een van de voordelen die we uit deze aanpak kunnen halen is het integreren van de website in een overkoepelend systeem. Hierdoor worden gebruikers, die zich hadden ingeschreven voor een activiteit in het verleden, teruggevonden in het systeem en vermijden we redundantie. Ook voor de gebruiker is dit efficiënter omdat zij niet opnieuw hun gegevens moeten ingeven. Het grootste voordeel aan de zijde van de beheerder, is dat het hergebruiken van de website een stuk eenvoudiger gemaakt wordt. Alle nieuwe gegevens kunnen on-line ingegeven worden waardoor men als beheerder locatie en platformonafhankelijk kan werken. Een manuele manipulatie van de database is hierdoor ook niet meer noodzakelijk. Alle aanpassingen kunnen dus gebeuren met eenvoudige formulieren. We moeten er vanuit gaan dat de beheerder het achterliggende systeem en de database niet kent.


9

Ook de bijvoorbeeld de titels en lesgevers van alle cursussen worden aan de hand van een formulier op de correcte manier opgeslagen in de databank, en kan men indien nodig op een eenvoudige manier wijzigen.

3.3

Use-case-diagram

Figuur 1 - Use-case diagram

De acties die in dit diagram voorkomen, vervullen de vereisten van de summerschoolwebsite  Summerschool toevoegen


10

De beheerder kan een nieuwe summerschool toevoegen.  Summerschool aanpassen Maar ook de reeds aangemaakte summerschools aanpassen.  Summerschool-informatie bekijken Al de praktische informatie over de summerschool en over de registratieprocedure is voor iedereen toegankelijk.  Registreren voor de summerschool Het registreren voor een summerschool kan enkel indien men reeds geregistreerd is in het overkoepelende systeem, met andere woorden, indien men reeds zijn persoonlijke gegevens ingegeven heeft. (zie registreren/inloggen)  Eigen registratie opvolgen. Mensen die zich zowel in de overkoepelende site als voor de summerschool geregistreerd hebben, kunnen hun registratieproces voor deze activiteit opvolgen. Hierbij hoort ook het kunnen uploaden van bestanden.  Registraties beheren De beheerder moet in kunnen zien wie zich reeds geregistreerd heeft, en moet deze registraties kunnen goedkeuren, en opvolgen.  Registreren/inloggen Twee rollen standaard aanwezig in een drupal-site zijn een anonieme en een ingelogde gebruiker. Voorlopig worden ook de lesgevers gerekend tot de geregistreerde gebruikers, maar ze kunnen in de toekomst ook een rol met eigen rechten, krijgen.

3.3

De databank

De databasetabellen van de summerschool-module worden bij het installeren van de module toegevoegd aan de Drupal-database. Bij het formulier waarmee de beheerder de summerschool ingeeft en eventueel aanpast, worden de gegevens weggeschreven naar 3 - Opbouw van de website

11

twee tabellen: hipeac en hipeacss_price. In de tabellen hieronder worden de primaire sleutels weergegeven met een gekleurde achtergrond, en worden de vreemde sleutels onderlijnd. hipeac

hipeacss_price

id

int ()

ssid

int

eventtype

varchar ()

price

int

place

varchar ()

startdate

int

enddate

int

earlydate

int

regdeadline

int

grantdate

int

Tabel 1 en 2 – hipeac en hipeacss_price

In de hipeac-tabel worden alle HiPEAC -activiteiten bijgehouden, het eventtype waarmee wij werken, is uiteraard ‘summerschool’. Naast een uniek id (de primaire sleutel) en het type activiteit, wordt ook andere informatie die bij elke activiteit gebruikt wordt in deze tabel opgeslagen: de plaats, begin –en einddatum, vroege en uiterste registratiedatum. De basisprijs van de summerschool wordt bijgehouden in een afzonderlijke tabel, aangezien dit een eigenschap is eigen aan het eventtype summerschool. Voor de andere informatie over de summerschool, die in het configuratiegedeelte ingevuld worden: de dagdelen en de cursussen, gebruiken we de volgende tabellen:


12

hipeacss_timeslots

hipeacss_courses

slotid

int

cid

int

ssid

int

slotid

int

start

int

title

varchar

end

int

instructor

int

Tabel 3 en 4- hipeacss_timeslot en hipeacss_courses

De primaire sleutels “slotid” en “cid” worden aangemaakt in een auto-increment-veld. In de hipeacss_timeslot-tabel vinden we nog een vreemde sleutel die verwijst naar het summerschool-id in de hipeac-tabel, en twee getallen die het start- en einduur van de dagdeel bepalen (telkens het aantal minuten na middernacht). In de hipeacss_coursestabel hebben we naast de primaire sleutel, een vreemde sleutel die verwijst naar het slotid van het dagdeel waartoe de cursus behoort, een titel, een een lesgever. Deze laatste is een vreemde sleutel die verwijst naar het uid (user-id) van de lesgever in de drupal-user-tabel. Om alle node-gerelateerde informatie, opgeslagen in de reeds aanwezige drupal-tabellen zoals ‘node’ te linken aan de summerschool activiteit, wordt een extra tabel aangemaakt. In deze tabel wordt met de “nid”, verwezen naar de node-tabel, en met de “ssid”, een vreemde sleutel die verwijst naar het id van de HiPEAC -activiteit in de hipeac-tabel. hipeacss_node nid

int

ssid

int

Tabel 5 - hipeacss_node

De informatie die de deelnemers doorgeven met het registratieformulier, worden bijgehouden in de hipeacss_reg en de hipeacss_reg_course tabellen:


13

hipeacss_reg

hipeacss_reg_course

regid

int

uid

int

ssid

int

cid

int

uid

int

pref

int

will_pay

int

approved

int

paid

int

student_grant

int

grant_ok

int

visum

int

poster

int

regstatus

varchar

motivation

text

regdate

int

Tabel 6 en 7- hipeacss_reg en hipeacss_reg_course

Met de vreemde sleutels ‘ssid’ en ‘uid’ in de hipeacss_reg-tabel wordt bijgehouden welke persoon zich wil registreren voor welke summerschool. De andere attributen staan voor de voorkeuren die de deelnemer meegaf in het registratieformulier, en voor het verloop van de registratie:  Will_pay: Houdt het bedrag bij dat de deelnemer moet betalen, dit veld wordt bij het aanvaarden van de beheerder (zonder dat een eventuele grant-aanvraag goedgekeurd wordt), ingevuld met de basisprijs van de summerschool. Maar kan ook aangepast worden door de beheerder in het summerschool-management gedeelte.  Paid: Duidt aan of het bedrag reeds betaald werd of niet.


14

 Student_grant: Duidt aan of de deelnemer een grant heeft aangevraagd.  Grant_ok: Duidt aan of een eventuele grant aanvraag goedgekeurd werd  Visum  Poster: Als de student in het registratieformulier heeft aangeduid dat hij een poster wil presenteren, wordt dit hier bijgehouden, en kan de student, na het aanvaarden en goedkeuren van de registratie, een abstract uploaden.  Regstatus: De codes die de registratiestatus aanduiden, werden in het vorige hoofdstuk besproken. De defaultwaarde van dit veld is ‘p’, pending.  Motivation: Bij de registratie moet de deelnemer zijn aanvraag tot deelname aan de summerschool motiveren.  Regdate: Registratiedatum. De hipeacss_reg_course-tabel heeft een samengestelde primaire sleutel: de uid van de gebruiker, en de cid van de cursus waarvoor de persoon zich wil registreren. Het attribuut ‘pref’ duidt aan of deze cursus de eerste, tweede of derde keuze is van de deelnemer, en ‘approved’ is een boolean die aanduidt of deze cursus voor deze gebruiker al dan niet de definitieve keuze is. Na het afronden van de inschrijving, kan de deelnemer, indien gewenst, ook een abstract uploaden. Naast het gebruik van de reeds aanwezige drupal-tabellen voor het beheren van de geuploade bestanden, worden ook een aantal tabellen, horende bij de summerschool-module aangemaakt:


15

hipeacss_files

hipeacss_posters

fid

int

fid

ssid

int

title

varchar

uid

int

authors

varchar

type

int

varchar

Tabel 8 en 9 - hipeacss_files en hipeacss_posters

De primaire sleutel in beide tabellen is fid, en verwijst naar de drupal-files-tabel. In de eerste tabel wordt het bestand gelinkt aan een summerschool en een gebruiker via vreemde sleutels, en aan een bepaald type bestand. Momenteel is er maar één type bestand waarmee gewerkt wordt in de summerschool-module, maar eventueel kan dit later nu uitgebreid worden. De abstracts krijgen het type ‘poster’ mee, en krijgen een record in de tabel hipeacss_posters, waarin ook de titel en de auteurs die meegewerkt hebben aan dat bepaalde project, opgeslagen worden. Ten slotte zijn er de tabellen die gebruikt worden in het mail-gedeelte van de summerschool-management pagina’s: hipeacss_mail

hipeacss_audience

mid

int

aid

int

ssid

int

ssid

int

description

varchar

name

varchar

subject

varchar

query

varchar

body

text

sender

varchar

Tabel 10 en 11- hipeacss_mail en hipeacss_audience


16

In beide tabellen is er een vreemde sleutel ssid, die verwijst naar de summerschool waarbij deze mails en gebruikersgroepen behoren. In hipeacss_mail heb je nog een omschrijving van de mail, waardoor je de mail gemakkelijk kan terugvinden op de mailpagina. En vervolgens de velden die nodig zijn om een mail te versturen: een onderwerp, de inhoud van de mail, en de afzender. In de hipeacss_audience-tabel worden de queries opgeslagen die de juiste groep gebruikers opvraagt, en ten slotte is er ook nog een naam die het audience meekrijgt.


17

Hoofdstuk 4 – De Summerschool module 4.1

De bestanden van een Drupal-module

Elke Drupal-module bestaat uit minstens drie verplichte bestanden: [modulenaam].info, [modulenaam].install en [modulenaam].module. Het info-bestandje6 bezorgt, zoals de naam het zegt, de meta-data over de module. De vereiste velden zijn: de naam van de module, een omschrijving en voor welke Drupal-core ze geschreven werd. Eventueel kan men daar bijvoorbeeld nog afhankelijkheden (van andere modules), of de PHP-versie aan toevoegen. Het [modulenaam].install-bestand7 (geschreven in PHP) wordt uitgevoerd op het moment dat de module geïnstalleerd wordt. De [modulenaam].install-functie maakt de nodige tabellen aan in de databank. De uninstall-functie wordt uitgevoerd op het moment dat de module verwijderd wordt, en verwijdert de databanktabellen van de module. Terwijl men in Drupal 5 nog zelf in SQL de queries moet schrijven (zowel voor MySQL als voor PostgreSQL-databanken), wordt dit in Drupal 6 vereenvoudigd met behulp van hook_schema().

4.2

Summerschool.module

De eigenlijke module wordt geschreven in het [modulenaam].module bestand. Om beroep te doen op een aantal andere functionaliteiten, en om de interactie met de andere modules reeds aanwezig in de drupal-site te garanderen, worden in de broncode eerst een aantal hooks geïmplementeerd: 

Hook_node_info()8

Deze hook wordt gebruikt om aan te duiden dat in de module één, of meerdere nodetypes gedefiniëerd worden. Hierin worden de namen van deze nodes meegegeven. Wij creëren een node met de naam ‘Summerschool’, horende bij de module ‘summerschool’, en geven in een beschrijving mee dat deze node een registratiepagina aanmaakt.

4 - De Summerschool module

18



Hook_perm()9

Bij het implementeren van deze hook worden de toegangsrechten gegeven. Zo kunnen de rechten toegekend worden aan bepaalde rollen of users op de gebruikersadministratiepagina's. Ook in de module zelf keren deze rechten terug, bij bijvoorbeeld de menu-items (zie hook_menu()). 

Hook_access()10

Hier kunnen voorwaarden meegegeven worden en toegekend aan bepaalde rechten. 

Hook_menu()11

Deze hook maakt het mogelijk om de paths die gebruikt zullen worden, te registreren. De return value is een array met de verschillende menu-items (die niet noodzakelijk in een menu weergegeven zullen worden). De velden waarvan ik gebruik maak zijn: title, page callback , page arguments, access arguments en type. Voorbeeld van een menu-item (Drupal 6): function summerschool_menu() { $items = array(); $items['admin/settings/summerschool/%/courses/%/edit']= array( 'page callback' => 'drupal_get_form', 'page arguments' => array('_editcourse_summerschool'), 'title' => 'Edit a course', 'access arguments' => array('create summerschool'), 'type' => MENU_CALLBACK, ); }

Het path wordt dus meegegeven als key. De value is op zijn beurt weer een array waarin de velden ingevuld worden. 'page callback' geeft de functie die opgeroepen wordt bij het bezoeken van dat bepaalde path. In dit geval is het drupal_get_form(), de form API zullen we later bespreken. Als argument ('page argument') staat er de functie die het formulier teruggeeft. Daarnaast geven we nog een titel, ‘access arguments’ en het ’type’. De ‘access arguments’ verwijzen naar de rechten die bepalend is voor het toegang krijgen tot de pagina. In dit geval is het type van het menu-item MENU_CALLBACK, wat erop wijst dat dit niet verschijnt in een menu, maar dat de 'page_callback' 4 - De Summerschool module

19

uitgevoerd wordt op het moment dat het path bezocht wordt. Het standaard type is MENU_NORMAL_ITEM

12

, deze items verschijnen wel in het menu, en kunnen verplaatst of

verborgen worden door de beheerder. 

hook_help()13

Met deze hook wordt de optionele module 'help' aangesproken. Deze module maakt het mogelijk om zelf helpteksten te publiceren over je eigen module. Dit kan op de pagina admin/help/summerschool maar eventueel ook op andere plaatsen binnen de module.

4.3

Drieledige functionaliteit

De module kan opgedeeld worden in drie grote delen: het eerste biedt de mogelijkheid om een summerschool, met de nodige info, in de database op te slaan en eventueel aan te passen. Het tweede creëert een registratieformulier, en de pagina waar de deelnemers hun registratie kunnen opvolgen. En ten laatste zijn er de pagina's waar de registraties opgevolgd en beheerd kunnen worden.

4.3.1 Een summerschool creëren Gebruikers

met

de

summerschool-admin

toegansrechten

kunnen

de

pagina

admin/settings/summerschool bezoeken. Het eerste wat moet gebeuren vooraleer de site toegankelijk gemaakt wordt, is het invullen van de concrete gegevens van de summerschool. De summerschool wordt opgevat als een HiPEAC-event, net zoals bijvoorbeeld een conferentie, en wordt opgeslaan in de algemene databasetabel “hipeac”, belangrijkste velden zijn de plaats, de data, registratiedata, uiteraard het activiteit-type (bijvoorbeeld een summerschool, conference,...) en een basisprijs. Vervolgens zijn er de cursussen die gegeven zullen worden, deze worden gegroepeerd per dagdeel. Daarom dient men eerst de dagdelen aan te maken, met begin -en einduur. Ze worden gesorteerd volgens beginuur. Het cursusformulier bevat de volgende velden: een dagdeel (opties te kiezen uit de reeds aangemaakte dagdelen), een titel (tekstveld), en een lesgever (opties die men kan kiezen uit een lijst met reeds geregistreerde gebruikers).


20

Bij het kiezen van de lesgevers wordt er dus van uit gegaan dat deze zich reeds geregistreerd hebben op de website. In het voorbeeld zijn er vier dagdelen, waarin telkens keuze is tussen drie verschillende cursussen. Aangezien er in het registratieformulier (zie verder) verwacht wordt dat de student per dagdeel waarvoor ze zich willen inschrijven, een eerste, tweede, en derde keuze ingeeft, dient er per dagdeel minstens drie keuzes aan te bieden. 

Form API

De form-api, die hier gebruikt wordt om formulieren te genereren om een summerschool aan te maken, aan te passen, een dagdeel in te geven, een dagdeel aan te passen (eenzelfde functie), en om hetzelfde te doen met de cursussen, wordt heel vaak opgeroepen in deze module. Aangezien er op heel veel plaatsen informatie naar de database geschreven wordt, en eventueel aangepast wordt, zal de functie drupal_get_form()in de module heel vaak gebruikt worden.

Er wordt gebruik gemaakt van een systeem gelijkaardig als dat van het menu: er wordt een array $form[] teruggegeven (bij menu is dat $items[]). En voor elke $form terug een array met de parameters die het formulierveld definiëren. Naast de functie die als argument bij het oproepen van drupal_get_form() meegegeven wordt, is er nog een _validate() en _submit()-functie. En in het geval van meerdere knoppen kan je aan elke extra knop (bijvoorbeeld bij een delete-knop) een eigen submitfunctie koppelen, zoals in Drupal 6 het geval is. De _validate() functie valideert de input, en geeft eventuele foutmeldingen terug. Indien de input aan alle voorwaarden voldoet, wordt de _submit() functie uitgevoerd. De Drupal functies die gebruikt worden om gegevens uit de databank op te halen zijn db_query(), om de databank aan te spreken met een SQL-query en db_fetch_object(),

om de resultaten van een query in objecten op te slaan. Om een variabelen in queries te gebruiken, dient men dit aan de hand van placeholders te doen: '%s' voor een string en %d voor digitale data zoals integers. Hieronder volgt de query die gebruikt wordt om een summerschool als HiPEAC-activiteit op te slaan, om het gebruik van de placeholders te illustreren:


21

db_query("INSERT enddate,

INTO

earlydate,

{hipeac} grantdate,

(place,

eventtype,

regdeadline)

startdate,

VALUES

('%s',

'%s', %d, %d, %d, %d, %d)", $place, "summerschool", $startdate, $enddate, $earlydate, $grantdate, $regdeadline);

Deze pagina's worden dus gebruikt om al de informatie over de summerschool, die zal gebruikt worden bij het registreren, in te vullen. De andere informatie van het event wordt toegevoegd in statische pagina's (met het gebruik van het node-type 'page'). Hieronder volgt een overzicht van de formulieren waarmee de beheerder de summerschool-gegevens kan ingeven en aanpassen. Als men de pagina admin/settings/summerschool bezoekt, krijgt men eerst een overzicht van de reeds aangemaakte summerschools. Een summerschool aanpassen, kan door op de plaats te klikken. Een summerschool bijmaken, kan door op “Add a summerschool” te klikken.

Figuur 2 - Summerschool Configuration

Bij het creëren van een summerschool kunnen de plaats en alle data ingevuld worden.


22

Figuur 3 - Summerschool Configuration: Create a summerschool

Bij het bekijken en aanpassen van een summerschool kan men naast het aanpassen van de data, de plaats en de prijs, ook de dagdelen definiëren en cursussen toevoegen aan de reeds aangemaakte dagdelen.

Figuur 4 - Summerschool Configuration: Edit a summerschool 4 - De Summerschool module

23

Bij het aanmaken van een dagdeel, kan een beginuur en einduur gekozen of aangepast worden. Bij het wijzigingsformulier kan het dagdeel ook verwijderd worden.

Figuur 5 - Summerschool Configuration: Dagdeel aanpassen

Bij het aanmaken van een cursus kan men deze toevoegen aan één van de reeds aangemaakte dagdelen, een titel invullen, en uit een lijst van personen die reeds een account hebben een lesgever kiezen.

Figuur 6 - Summerschool Configuration: Cursus toevoegen


24

Figuur 7 - Summerschool Configuration: Cursus aanpassen

Na het invullen van deze formulieren, werd alle informatie, nodig om een registratieformulier te maken, ingegeven, en kan men over gaan naar de volgende stap.

4.3.2 De registratiepagina Na het ingeven van de praktische informatie, kan de summerschool-admin een node creëren. Hiermee wordt het registratieformulier voor de studenten aangemaakt. In de module zelf worden hiervoor de nodige functies uit de nodes API opgeroepen: We hadden al summerschool_node_info(), om aan te geven dat er een node-type gedefinieerd

wordt.

Nu

summerschool_insert(),

voegen

we

daar

aan

summerschool_update(),

toe:

summerschool_form(),

summerschool_delete(),

en

ten slotte summerschool_view(). 

hook_form()

Hier wordt het formulier, om de node te creëren, aangepast. In dit geval bestaat het formulier uit een lijst met plaatsen van de reeds aangemaakte summerschools. Daarnaast is er nog een tekstveld “information”, waarin de beheerder eventueel meer informatie kan meegeven die in de body van de node zal verschijnen, net boven het registratieformulier.


25



hook_insert()

Bij het submitten van het formulier, wordt de node toegevoegd aan de node-tabel. Met de hook_insert kunnen we hier bepalen wat er, naast het creëren van de node, verder nog moet gebeuren of moet opgeslagen worden. Hier gaan we in een afzonderlijke tabel de nid (node-id) linken aan de ssid (summerschoolid) 

hook_update()

Deze functie wordt opgeroepen als de node aangepast wordt, en bestaat dus uit een update-query. 

hook_delete()

Zoals de naam het zegt, definieert men hier de query die men wil uitvoeren op het moment dat men de node, en alle informatie afhankelijk van de node, wil verwijderen. 

hook_view()

Hier wordt beschreven wat weergegeven wordt als men het adres node/[nid] bezoekt, met andere woorden, het registratieformulier. Wat de student te zien krijgt als hij het registratieformulier bezoekt, is afhankelijk van verschillende zaken: het al dan niet ingelogd zijn, de uiterste registratiedatum die wel of niet overschreden is, of de student zich al geregistreerd heeft voor deze summerschool of niet, en de registratiestatus van de student. De twee grote functies hieraan gekoppeld zijn ss_reg_form() en ss_reg_prog(). De eerste functie geeft het eigenlijke registratieformulier terug. ss_reg_prog() geeft de volgende elementen: de voorkeuren die de student ingevuld heeft, het voorlopige programmavoorstel of het definitieve na het overlopen van alle registratiestappen. Om de inhoud van de node-body te verduidelijken volgt op in onderstaande figuur een flowchart met alle mogelijkheden.


26

Figuur 8 - Node view: Flowchart


27

Eerst wordt nagegaan of de gebruiker is ingelogd, indien niet, krijgt de bezoeker een melding om zich in te loggen in de drupal-site, of om een account aan te maken. Is de gebruiker ingelogd? Dan kijken we of deze gebruiker zich reeds heeft geregistreerd voor deze summerschool. Heeft hij dat reeds gedaan, wordt de functie ss_reg_prog() opgeroepen, die het verloop van de registratie, en het voorlopige of definitieve persoonlijke programma weergeeft. Als de gebruiker wel ingelogd is, maar zich nog niet heeft geregistreerd voor deze summerschool, wordt gecontroleerd of de registratiedatum reeds overschreden is. Is dat niet het geval wordt het registratieformulier getoond. Bij de eerste mogelijkheid die we zien in onderstaande afbeelding, heeft de gebruiker zich nog niet ingelogd of geregistreerd in de drupal-website. Deze bezoekers krijgen onderstaande melding te lezen.

Figuur 9 - Node view: Register Here (a)

Bij de tweede mogelijkheid ziet de ingelogde gebruiker een registratieformulier. Het bovenste gedeelte (eerstvolgende afbeelding) biedt de mogelijkheid de keuzes voor de cursussen in te vullen. Het onderste gedeelte bevat de andere keuzes die met de registratie meegegeven worden.


28

Figuur 10 - Node view: Register Here (b)

Figuur 11 - Node view: Register Here (c)

In het derde geval wordt ss_reg_prog() opgeroepen. De inhoud van deze gepersonaliseerde programmapagina is afhankelijk van de registratiestatus, hieronder volgt een tabel met de verschillende statussen, hun code, en een korte omschrijving.


29

De student heeft het registratieformulier ingevuld. Hij ziet op de P

Pending

registratiepagina zijn persoonlijke keuzes en andere verzoeken, en moet afwachten op actie van de beheerder. De inschrijving werd aanvaard door de beheerder, en er werd een

A

Accepted

programmavoorstel verstuurd naar de deelnemer. registratiepagina

kan

dit

programmavoorstel

Op de

bekeken

en

goedgekeurd of afgewezen worden. Het voorstel werd aanvaard door de student, de inschrijving is bij

F

Finished

N

Not coming

Het voorgestelde programma werd door de student afgewezen.

R

Rejected

De deelnemer werd geweigerd.

W

Waiting

deze afgerond.

De student staat op de wachtlijst, maar kan op de registratiepagina nog steeds zijn persoonlijke voorkeuren zien.

Tabel 12 - Registratiestatussen

Net na het invullen van het registratieformulier, is dit pending: men krijgt de persoonlijke voorkeuren te zien.


30

Figuur 12 - Node view: persoonlijke registratipagina (pending)

Na het goedkeuren van de beheerder van de inschrijving, krijgt de deelnemer een voorstel te zien. Deze kan hij accepteren of weigeren.

Figuur 13 - Node view: persoonlijke registratipagina (approved)

De extra functionaliteiten die in dit gedeelte aan bod komen, zijn de mogelijkheden om bijlagen up te loaden en om te betalen. Na het accepteren van het voorstel, is de 4 - De Summerschool module

31

registratie afgerond, kan de deelnemer betalen (indien geen grant toegekend), en een abstract uploaden (indien in het eerste formulier aangeduid dat hij een poster wil presenteren).  Betalen Het betalen wordt voorlopig voorgesteld door een knop ‘pay’ (indien registratie de status ‘finished’ is, er geen grant werd gevraagd, of de grant request geweigerd werd). Het enige wat de submit-functie bij deze knop voorlopig doet is het veld ‘paid’ in het record van de student in de tabel met registraties van 0 op 1 zetten. Daarna verschijnt de knop uiteraard niet meer, maar wel een berichtje dat de student reeds betaald heeft.

Figuur 14 - Node view: persoonlijke registratipagina (finished)

 File-upload Na het goedkeuren van de inschrijving door de beheerder en het aanvaarden van het voorgestelde programma door de student, kan de student, indien het vakje 'poster' aangeklikt in het eerste registratieformulier, zijn abstract van de poster uploaden. En na het uploaden indien nodig ook verwijderen.


32

Figuur 15 - Node view: persoonlijke registratiepagina (poster)

4.3.3 Summerschool management: het beheren van de registraties Op deze pagina's kan de beheerder zien wie geregistreerd heeft, voor welke cursussen, met welke voorkeuren. Men kan men deze registraties hier ook beheren: het al dan niet goedkeuren, een definitief programma voorstellen aan de student, het toekennen van grants. Daarnaast kan op de pagina’s ‘statistics & course table’ de statistieken opvragen en onder ‘mail’ mails opslaan en versturen naar een bepaalde groep personen. Dit wordt hier het summerschool management genoemd. Deze pagina’s zijn niet bereikbaar via admin/settings/summerschool zoals bij het opzetten van de summerschool, maar wel via admin/ssmanagement omdat dit toch fundamenteel anders is. De administratiepagina's horen eigenlijk bij de node die aangemaakt werd.  Applications Op de pagina administer/ssmanagement/applications. Ziet men op één pagina alle personen die een registratieformulier ingediend hebben, gerangschikt volgens status, en met alle informatie uitgezonderd de cursusvoorkeuren. Men kan wel doorklikken naar een pagina met meer gedetailleerde informatie, als men op de naam van een deelnemer klikt. Op deze pagina kan de beheerder alles aanpassen: een grant toekennen of weigeren, de status aanpassen, een programmavoorstel (met zicht op de persoonlijke voorkeuren van de deelnemer) doorgeven en de eventuele geuploade abstracts bekijken.


33



Statistics & course table

Deze pagina geeft een overzicht van hoeveel registraties er zijn. Daarnaast is er ook nog een cursustabel die per cursus het aantal ingeschrevenen geeft: namelijk het aantal pending registraties met de respectieve keuzes 1, 2 of 3, het aantal studenten die de cursus als voorstel gekregen hebben (A), en het aantal definitieve inschrijvingen (F). Per cursus kan men doorklikken naar een afzonderlijke pagina per cursus, met per status, de aantallen en namen van de deelnemers. 

Mail

Om het versturen van e-mails naar een bepaalde groep personen (lesgevers, deelnemers, deelnemers met een bepaalde registratiestatus, iedereen,...) te vergemakkelijken, kunnen van hieruit mails opgeslagen en verstuurd worden. Hiervoor wordt de volgende procedure gevolgd: Eerst kan men een mail opstellen en opslaan, of eventueel bewerken. Daarnaast kan ook een bepaalde groep personen (een zogenaamde 'audience') gekozen worden, dit gebeurt aan de hand van een formulier.


34

Figuur 16 - Email management: gebruikersgroep kiezen

Om een mail te versturen, kan men op 'send', naast de omschrijving klikken. Vervolgens kan men kiezen uit de lijst reeds opgeslagen groepen. En ten slotte, kan men voor het versturen, de lijst met afzenders bekijken, en eventueel enkele namen uitklikken.


35

Figuur 17 - Email management: bestemmelingen kiezen


36

Hoofdstuk 5 – Installeren, configureren en ingebruikname 5.1

Drupalinstallatie

De installatie is vrij eenvoudig: de Drupal map kan men downloaden vanop Drupal.org en kopiëren naar de eigen webapplicatiemap. Vooraleer het eerste gebruik van de website moet een nieuwe databank aangemaakt worden. Bij dit eerste gebruik dient men een aantal instructies op te volgen zodat Drupal de default-instellingen kan aanpassen om de databank aan de site te koppelen.

5.2

Optionele modules activeren

Naast het installeren van de summerschool-module worden ook nog enkele optionele modules ingeschakeld bij de configuratie van de summerschool-website: hierbij de profile-module, en de help-module. Uiteraard hebben we voor de registratie voor de summerschool meer persoonlijk informatie nodig dan een standaard drupal-site vraagt van zijn gebruikers (gebruikersnaam, wachtwoord, e-mail adres), namelijk zijn adresgegevens (land, plaats, adres), en geslacht. Dit kan gevraagd worden door gebruik te maken van de profilemodule. Hierdoor is het ook mogelijk om eenvoudig de gebruikersgegevens op te vragen tijdens de registratieprocedure. De help module maakt het mogelijk om op de help pagina in het beheerdergedeelte, ook wat meer informatie over je eigen module te plaatsen. Voor de beheerders van de site is het handig om vlug te kunnen opzoeken hoe deze module werkt, welke functies ze vervult, wat alle mogelijkheden zijn en hoe deze module correct te gebruiken.

5.3

Een thema kiezen

De layout van de website wordt in Drupal bepaald door thema's. Standaard worden er enkele meegeleverd, maar daarnaast bestaan er ook veel thema's in de Drupal gemeenschap die vrij te verkrijgen zijn, net zoals bij de modules.

5 - Installeren, configureren en ingebruikname

37

Als basis van het summerschool-thema, werd gekozen voor het basisthema Zen. Dit thema werd speciaal ontwikkeld om zelf op een eenvoudige manier een eigen subthema aan te maken. Net als een module, bezit ook een thema een .info bestand 14. De informatie die hier meegegeven wordt, bestaat onder meer uit de naam, een beschrijving, de Drupal-core,en de theme-engine. Maar er wordt ook vermeldt wat er zicht in welke region (left, right, content, header, footer) bevindt, zoals bijvoorbeeld een sidebar of de inhoud. Verder wordt er nog vermeldt welke stylesheets toegepast worden. En ten slotte ook welke opties er op de themaconfiguratiepagina verschijnen: de keuze van een logo, een favicon, een slogan,... In het subthema kunnen bestanden uit het basisthema overschreven worden, bijvoorbeeld het page.tpl.php bestand, of het gebruik van eigen CSS-bestanden. In het page.tpl.php bestand wordt de structuur van een pagina bepaald.

5.4

Ingebruikname van de Drupal-module

Op de modulepagina van het beheerdergedeelte kan je de summerschool-module aanklikken, bij de installatie van de module worden de nodige databasetabellen en de menu-items

aangemaakt.

Hierna

kan

de

informatie

toegevoegd

worden

bij

admin/settings/summerschool (zie Figuur 2 tot Figuur 7). Bij het creëren van de node, kan er gekozen worden tussen de reeds aangemaakte summerschools aan de hand van de plaats en kan men tevens ook informatie over de summerschool of over de registratie meegeven. Deze extra informatie zal dan bovenaan het registratieformulier verschijnen. Net als de andere nodes, kan ook een summerschool-node aangepast worden, waarbij je dan eventueel de informatie kan wijzigen, of de node kan promoveren tot de startpagina van de site.

5.5

Afwerking

Het afwerken bestaat uit het eventueel configureren van de menu’s, blocks, en het toevoegen van de overige informatie over de activiteit. De inhoud die in het voorbeeld toegevoegd werd, werd overgenomen van de beschikbare ACACES 2009 website.15 5 - Installeren, configureren en ingebruikname

38

Hoofdstuk 6 – Conclusie Resultaat Er werd een Drupal-module ontwikkeld die als basis kan dienen om een summerschool website te ontwerpen. Een voorbeeld van hoe de module kan gebruikt worden, bevindt zich op het volgende adres: http://trappist.elis.ugent.be/~sksamaey/acaces/. Deze module maakt het mogelijk om de informatie over de summerschool te delen, om zich als student te registreren voor deze activiteit, en om als beheerder de registraties op te volgen en te beheren. Hierbij behoren bijvoorbeeld ook de mogelijkheden om abstracts te uploaden of om vanuit het beheerdergedeelte mails te versturen naar een bepaalde groep deelnemers. Kenmerkend voor deze aanpak, is dat men moet werken met een dubbele registratie. Dit was niet zo in de vorige website. Vooraleer zich te kunnen registreren voor een summerschool, of een andere activiteit, dienen de deelnemers eerst een account aan te maken. Er zijn echter nog een aantal functionaliteiten die voorlopig niet overgenomen werden uit de ACACES 2009- website, zoals het beheren van de kamers, het gebruik van een ranking om te bepalen welke studenten toegelaten worden en wie op een wachtlijst terechtkomt.

Proces Het tot stand komen van deze website, was naast het creëren van de site zelf, ook een persoonlijk leerproces. Aanvankelijk was er weinig kennis van het gebruik en de mogelijkheden van PHP en een CMS (Drupal in het bijzonder). Hierdoor verliep de totstandkoming niet altijd even efficiënt. Het schrijven van een module ‘from scratch’ en het converteren van een module van Drupal 5 naar Drupal 6, was geen eenvoudige maar een des te meer leerrijke ervaring.

6 - Conclusie

39

Toekomstperspectieven Daarnaast zijn er ook nog mogelijkheden om de huidige functionaliteiten verder uit te bouwen:  Men kan eventueel meer informatie over de cursussen of over de summerschool zelf, automatisch laten genereren, in plaats van handmatig als pagina toe te voegen.  Aangezien de lesgevers hun eigen account hebben, kunnen ze eventueel meer rechten toegekend krijgen, zoals bijvoorbeeld het kunnen aanpassen van informatie over de eigen cursus. Dit kan men doen, gebruik makend van een nieuwe rol.  Het mail systeem kan nog verbeterd worden, dan gaat het vooral over de keuzes van een audience, de mogelijkheden van het huidige formulier zijn eerder beperkt.  Momenteel is er al een aanzet tot het gebruik van een wachtlijst, maar ook dit kan nog verder uitgewerkt worden.

6 - Conclusie

40

Referenties [1]

http://www.hipeac.net

[2]

http://www.drupal.org

[3]

Vandyck, J. K. & Westgate, M. (2007). Pro Drupal Development, New York: Apress. p 2.

[4]

http://drupal.org/coding-standards

[5]

http://api.drupal.org/api/group/hooks

[6]

http://drupal.org/node/231036

[7]


[8]

http://api.drupal.org/api/function/hook_node_info

[9]

http://api.drupal.org/api/function/hook_perm

[10]

http://api.drupal.org/api/function/user_access/6

[11]

http://api.drupal.org/api/function/hook_menu

[12]

http://api.drupal.org/api/group/menu/6

[13]

http://api.drupal.org/api/function/hook_help

[14]


[15]

http://trappist.elis.ugent.be/~sksamaey/acacesxx

Referenties

41

Ontwerp van een summerschoolwebsite in Drupal

Recommend Documents