Ontwerp van een summerschoolwebsite in Drupal

Transcriptie

1 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

2 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

3 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

4 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 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 Trefwoorden: CMS, Drupal, summerschool, website iii

5 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 PROBLEEMSTELLING: SUMMERSCHOOLWEBSITE CMS EN DRUPAL WERKWIJZE OPBOUW VAN DE SCRIPTIE... 2 HOOFDSTUK 2 - KERNFUNCTIONALITEIT VAN DRUPAL CONTENT MANAGEMENT SYSTEM HET GEBRUIK VAN DRUPAL SAMENWERKING TUSSEN MODULES... 5 HOOFDSTUK 3 SUMMERSCHOOLWEBSITE: OPBOUW DOELSTELLINGEN: SUMMERSCHOOL? DE VEREISTEN Registratieverwerking en registratiebeheer Opbouw en onderhoud Onze oplossing USE-CASE-DIAGRAM DE DATABANK HOOFDSTUK 4 DE SUMMERSCHOOL MODULE DE BESTANDEN VAN EEN DRUPAL-MODULE SUMMERSCHOOL.MODULE DRIELEDIGE FUNCTIONALITEIT Een summerschool creëren De registratiepagina Summerschool management: het beheren van de registraties iv

6 HOOFDSTUK 5 INSTALLEREN, CONFIGUREREN EN INGEBRUIKNAME DRUPALINSTALLATIE OPTIONELE MODULES ACTIVEREN EEN THEMA KIEZEN INGEBRUIKNAME VAN DE DRUPAL-MODULE AFWERKING HOOFDSTUK 6 CONCLUSIE RESULTAAT PROCES TOEKOMSTPERSPECTIEVEN v

7 Tabel van afkortingen ACACES CMS CSS HiPEAC PHP SQL Advanced Computer Architecture and Compilation for High-Performance and Embedded Systems Content Management System Cascading Style Sheets European Network of Excellence on High Performance and Embedded Architecture and Compilation Hypertext preprocessor Structured Query Language vi

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

9 Lijst van figuren Figuur 1 - Use-case diagram Figuur 2 - Summerschool Configuration Figuur 3 - Summerschool Configuration: Create a summerschool Figuur 4 - Summerschool Configuration: Edit a summerschool Figuur 5 - Summerschool Configuration: Dagdeel aanpassen Figuur 6 - Summerschool Configuration: Cursus toevoegen Figuur 7 - Summerschool Configuration: Cursus aanpassen Figuur 8 - Node view: Flowchart Figuur 9 - Node view: Register Here (a) Figuur 10 - Node view: Register Here (b) Figuur 11 - Node view: Register Here (c) Figuur 12 - Node view: persoonlijke registratipagina (pending) Figuur 13 - Node view: persoonlijke registratipagina (approved) Figuur 14 - Node view: persoonlijke registratipagina (finished) Figuur 15 - Node view: persoonlijke registratiepagina (poster) Figuur management: gebruikersgroep kiezen Figuur management: bestemmelingen kiezen viii

10 Hoofdstuk 1 Inleiding 1.1 Probleemstelling: summerschoolwebsite HiPEAC 1 (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 egreren 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 Drupal- 1 - Inleiding 1

11 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

12 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 ernet. 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 worden 3. 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 houden 4. Zoals bijvoorbeeld het gebruik van spaties en commentaren. 2 - Kernfunctionaliteit van Drupal 3

13 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

14 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 erageren, 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

15 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

16 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, en ten slotte dient deze website als applicatie om deze registraties te beheren. 3.2 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 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

17 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 Opbouw en onderhoud Ook hier zijn verschillende oplossingen mogelijk. De huidige website biedt wel een uitgebreide erface 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. 3 - Opbouw van de website 8

18 Voorbeeld: in de vorige website kon men de audiences, de gebruikersgroepen aan wie men een 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 erface bezitten om de registraties te beheren 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 egreren 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. 3 - Opbouw van de website 9

19 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 3 - Opbouw van de website 10

20 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

21 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 () ssid eventtype varchar () place varchar () price startdate enddate earlydate regdeadline grantdate 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: 3 - Opbouw van de website 12

22 hipeacss_timeslots hipeacss_courses slotid cid ssid slotid start title varchar end instructor 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 ssid 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: 3 - Opbouw van de website 13

23 hipeacss_reg hipeacss_reg_course regid uid ssid cid uid pref will_pay approved paid student_grant grant_ok visum poster regstatus varchar motivation text regdate 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. 3 - Opbouw van de website 14

24 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: 3 - Opbouw van de website 15

25 hipeacss_files hipeacss_posters fid fid ssid title varchar uid authors varchar type 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 aid ssid ssid description varchar name varchar subject varchar query varchar body text sender varchar Tabel 10 en 11- hipeacss_mail en hipeacss_audience 3 - Opbouw van de website 16

26 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. 3 - Opbouw van de website 17

27 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-bestandje 6 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-bestand 7 (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 eractie 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

28 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

29 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 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). 4 - De Summerschool module 20

30 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 egers. Hieronder volgt de query die gebruikt wordt om een summerschool als HiPEAC-activiteit op te slaan, om het gebruik van de placeholders te illustreren: 4 - De Summerschool module 21

31 db_query("insert INTO {hipeac} (place, eventtype, startdate, enddate, earlydate, grantdate, regdeadline) 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. 4 - De Summerschool module 22

32 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

33 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 4 - De Summerschool module 24

34 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 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 voegen we daar aan toe: summerschool_form(), summerschool_insert(), summerschool_update(), 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. 4 - De Summerschool module 25

35 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. 4 - De Summerschool module 26

36 Figuur 8 - Node view: Flowchart 4 - De Summerschool module 27