Ontwikkeling van een commercieel webplatform

Academiejaar 2009 – 2010

Departement Toegepaste Ingenieurswetenschappen Schoonmeersstraat 52 - 9000 Gent

Ontwikkeling van een commercieel webplatform

Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica

Johnny RYMENANS Promotor:

Geert VAN HOOGENBEMT

Hogeschool Gent INWE

De ontwikkeling van een commercieel webplatform voor Invent-Design

p 3/96

Abstract

Nederlands: Het opzet van deze masterproef was het ontwikkelen en uitwerken van een commercieel webplatform voor Invent Design, een recent opgericht Vlaams bedrijf. Het moest een uitbreidbaar systeem worden dat toelaat dat gebruikers inhoud kunnen toevoegen die gebruikt zou worden om aan andere gebruikers, die de juiste machtigingen hebben, te tonen. Om dit mogelijk te maken werd er gebruik gemaakt van het open-source Content Management System Drupal, uitgebreid met een aantal zelfgeschreven modules. Er wordt een beschrijving van Drupal gegeven, er wordt beschreven hoe men modules kan schrijven, de analyse van de site wordt toegelicht, er wordt uitgelegd welke content types en views werden gedefinieerd, wat het nut van de gebruikte modules is en verder worden Drupal en Joomla met elkaar vergeleken. Uiteindelijk wordt er dieper ingegaan op de previewapplicatie, een uitbreiding die geschreven werd in Flex.

English: The aim of this thesis was to develop a commercial web platform for a newly founded Flemish company, Invent Design. It had to be an expandable system that allowed users to add content which would be used to show to users who have the appropriate permissions. In order to facilitate the development, an open-source Content Management System called Drupal was used. The CMS was extended with a number of self-written modules. In the thesis text, there’s a description of Drupal and a how-to about writing your own modules. The analysis of the site is explained and there’s information about the content types and views that have been defined. Furthermore, there’s a description about the usefulness of the modules that were used. There’s also a comparison between Joomla and Drupal. We also take a closer look at the previewapplication, an extension which was written in Flex.

Johnny Rymenans

juni 2010


Johnny Rymenans


p 4/96

juni 2010



p 5/96

Inhoudsopgave ABSTRACT .......................................................................................................... 3 NEDERLANDS: ....................................................................................................... 3 ENGLISH: ............................................................................................................ 3 INHOUDSOPGAVE ............................................................................................... 5 1

WOORD VOORAF .......................................................................................... 9

2

VOORSTELLING VAN INVENT DESIGN ........................................................ 11

3

DRUPAL ...................................................................................................... 13 3.1 3.2 3.3 3.4 3.5

4

HET SCHRIJVEN VAN EEN MODULE ............................................................. 19 4.1 4.2 4.3 4.4

5

DE TECHNOLOGY STACK ..................................................................................13 DE CORE ...................................................................................................14 MODULES IN DRUPAL.....................................................................................15 HET CONCEPT: NODE .....................................................................................16 DE MAPPENSTRUCTUUR VAN DRUPAL ...................................................................16

INV_CATEGORIEEN.INFO .................................................................................19 INV_CATEGORIEEN.MODULE .............................................................................20 INV_CATEGORIEEN.INSTALL .............................................................................22

HET RESULTAAT VAN DE DEZE MODULE ................................................................23

ANALYSE, OPBOUW EN IMPLEMENTATIE VAN DE SITE ............................... 25 5.1 INDELING IN ROLLEN .....................................................................................25 5.1.1 Auteur ..............................................................................................26 5.1.2 Jurering ............................................................................................26 5.1.3 Topklanten ........................................................................................27 5.1.4 Merchandising....................................................................................27 5.1.5 Leverancier .......................................................................................28 5.2 SCHEMA’S .................................................................................................28 5.2.1 Pagina-aanvragen ..............................................................................28 5.2.2 Inloggen ...........................................................................................29 5.2.3 Voorbeeld1: de merchandising rol ........................................................29 5.2.4 Voorbeeld2: de auteursrol ...................................................................29 5.2.5 Voorbeeld3: de topklant rol .................................................................30

6

DE GEBRUIKTE MODULES ........................................................................... 37 6.1 CONTRIBUTED MODULES .................................................................................37 6.1.1 Functionaliteit toevoegen voor de site ...................................................38 6.1.2 Functionaliteit voor de ontwikkelaar......................................................42 6.1.3 Tips voor de keuze van modules ..........................................................43 6.2 ZELFGESCHREVEN MODULES .............................................................................44 6.2.1 Eigen geschreven modules ..................................................................44 6.2.2 Modules van geëxporteerde code .........................................................46 6.2.3 Aangepaste contributed module ...........................................................46

7

CONTENT TYPES EN VIEWS ........................................................................ 49 7.1

DE GEDEFINIEERDE CONTENT TYPES ...................................................................49

Johnny Rymenans

juni 2010



p 6/96

7.1.1 Voor Auteurs .....................................................................................49 7.1.2 Voor Juryleden ...................................................................................50 7.1.3 Voor Topklanten .................................................................................50 7.1.4 Voor Merchandising ............................................................................50 7.1.5 Voor Leveranciers...............................................................................51 7.1.6 Voor Admin .......................................................................................51 7.2 DE GEDEFINIEERDE VIEWS ..............................................................................52 7.2.1 Voor Auteurs .....................................................................................54 7.2.2 Voor Juryleden ...................................................................................54 7.2.3 Voor Topklanten .................................................................................54 7.2.4 Voor Merchandising ............................................................................54 7.2.5 Voor Leveranciers...............................................................................55 7.2.6 Voor Admin .......................................................................................55 7.3 VERDUIDELIJKING VAN DE WORKFLOW VAN DE SITE .................................................55 7.3.1 Vanuit het standpunt van een Auteur....................................................55 7.3.2 Vanuit het standpunt van een Jurylid ....................................................56 7.3.3 Vanuit het standpunt van een Topklant .................................................57 7.3.4 Vanuit het standpunt van een Merchandiser ..........................................57 7.3.5 Vanuit het standpunt van een Leverancier .............................................58 7.3.6 Vanuit het standpunt van een Admin ....................................................58 7.4 ACTIES EN TRIGGERS BEVORDEREN WORKFLOW .....................................................59 8

EEN KORTE VERGELIJKING TUSSEN JOOMLA! EN DRUPAL .......................... 61 8.1 JOOMLA! ...................................................................................................61 8.1.1 Het Framework ..................................................................................61 8.1.2 Voordelen van Joomla! ........................................................................63 8.1.3 Nadelen van Joomla! ..........................................................................63 8.2 DRUPAL ....................................................................................................64 8.2.1 Objectgeoriënteerde concepten in Drupal ..............................................64 8.2.2 Design Patterns in Drupal ....................................................................65 8.2.3 Voordelen van Drupal .........................................................................65 8.2.4 Nadelen van Drupal ............................................................................66 8.3 VERGELIJKING .............................................................................................66 8.4 CONCLUSIE ................................................................................................66

9

DE PREVIEWAPPLICATIE ............................................................................ 69 9.1 DOELSTELLING ............................................................................................69 9.2 ONDERZOEK ...............................................................................................69 9.3 HET PROTOTYPE ...........................................................................................70 9.4 IMPLEMENTATIE ...........................................................................................71 9.4.1 Invent_Design.mxml ..........................................................................71 9.4.2 Invent_Design.as ...............................................................................73 9.4.3 services-config.xml.............................................................................74 9.4.4 flexxml-service ..................................................................................75 9.5 UITBREIDINGEN ...........................................................................................76

10

SLOTBESCHOUWING ............................................................................... 77

10.1 10.2 10.3

WAT HEB IK GELEERD .................................................................................77 ENKELE MOEILIJKHEDEN ..............................................................................78 EEN CONCLUSIE ........................................................................................79

Johnny Rymenans

juni 2010



p 7/96

LIJST MET FIGUREN.......................................................................................... 81 LITERATUURLIJST ............................................................................................ 83 APPENDIX A: INSTALLATIE VAN EEN DRUPALSITE ........................................... 85 VOORBEREIDING ...................................................................................................85 INSTALLEREN .......................................................................................................86 APPENDIX B: EEN EIGEN DRUPAL5 MODULE. ................................................... 89 INV_KIESOBJECT.MODULE ........................................................................................89 INV_KIESOBJECT.INFO ............................................................................................91 INV_KIESOBJECT.INSTALL ........................................................................................92 APPENDIX C: VERGELIJKING JOOMLA! EN DRUPAL .......................................... 93

Johnny Rymenans

juni 2010


Johnny Rymenans


p 8/96

juni 2010



p 9/96

1 Woord vooraf Met deze masterproef wil ik mijn opleiding succesvol beëindigen. Invent Design is een Vlaams bedrijf dat recent is opgericht. Het bedrijf heeft als missie, “een commercieel platform te zijn binnen de internationale kunstmarkt”. Invent Design gaf me de mogelijkheid om dit platform voor hen te ontwerpen en te implementeren. Eén van de –onmisbare- middelen om de doelgroepen (kunstenaars enerzijds, klanten anderzijds) te bereiken en de vooropgestelde missie te realiseren is de inrichting van een website, m.a.w. een platform dat de ganse werking van het bedrijf toelaat. Onder het motto “Mijn site = mijn bedrijf” is het de bedoeling dat de site het ganse bedrijf wordt. Het enige wat een klant, ontwerper en zelfs een medewerker nodig heeft, is … een webbrowser. Als de klant gebruikmaakt van de browser krijgt hij toegang tot het aanbod van Invent Design. Ontwerpers kunnen hun kunstobjecten ter beschikking stellen en medewerkers kunnen alles in goede banen leiden. Het gebruik van Drupal, een Content Management System (CMS), was een belangrijk onderdeel van mijn masterproef. De keuze voor Drupal is gebaseerd op een kort onderzoek naar de mogelijkheden van dit CMS en de voorkeur die de zaakvoerder reeds had met betrekking tot dit CMS. De site werd opgebouwd door de mogelijkheden van Drupal te combineren met eigen modules om de functionaliteit van het CMS uit te breiden en zo aan de specifieke eisen van de opdrachtgever te voldoen. Dit project heeft me de kans geboden om kennis te maken met dit veelzijdige framework om kwaliteitsvolle en robuuste websites te bouwen. De thesistekst zal eerst een korte inleiding geven over Invent Design en het doel van deze masterproef. Verder wordt Drupal besproken en zal er aan de hand van een zelfgeschreven module inv_categorieen uitgelegd worden hoe men zelf modules kan schrijven voor Drupal. Daarna wordt de analyse van de site besproken en wordt er uitleg gegeven bij de modules die gebruikt werden bij de opbouw van de site. Hierop aansluitend worden de gedefinieerde content types en views toegelicht. Vervolgens wordt er een vergelijking gemaakt tussen Joomla en Drupal. Uiteindelijk wordt de previewapplicatie ontleed. De thesistekst wordt afgesloten met een slotbeschouwing over de masterproef en zijn verloop. Tenslotte wil ik graag enkele mensen bedanken voor hun hulp, steun en vertrouwen die ze in me hebben gesteld. Vooreerst wens ik de zaakvoerder, Jean Van der Biest, te danken voor het vertrouwen dat hij me heeft geschonken, voor de kans die hij me heeft aangeboden en de talrijke contacten die we hebben gehad. Verder hoop ik dat we in de toekomst onze samenwerking kunnen voortzetten. Verder wil ik mijn interne promotor, de heer Geert Van hoogenbemt, danken voor zijn hulp en richtlijnen bij de uitvoering van de masterproef, voor de tips die hij gegeven heeft toen ik mijn scriptie schreef en voor het uitgebreid masterproefvoorstel.

Johnny Rymenans

juni 2010



p 10/96

Ook wil ik een woord van dank richten aan mijn ouders, die me de kans hebben gegeven om verder te studeren en de studies van industrieel ingenieur aan te vatten. Hoewel we niet altijd dezelfde mening zijn toegedaan, weet ik dat ze het beste met me voorhebben en me ook steunen in de keuzes die ik maak. Ook aan mijn vrienden wil ik een woord van dank richten. In moeilijke tijden kon ik altijd op hun steun en raad rekenen. De gesprekken en discussies die we hebben gevoerd, hebben een niet te onderschatten hulp geboden om de frustraties het hoofd te bieden wanneer er weer eens een bug niet direct opgelost geraakte. Hiervoor mijn oprechte dank. Aangezien het project tot stand is gekomen door gebruik te maken van het CMS Drupal, acht ik een woord van dank aan Dries Buytaert, oprichter van Drupal en projectleider, op zijn plaats. Ook nu nog is hij de drijvende kracht achter de ontwikkeling van Drupal. Zijn visie heeft Drupal gemaakt tot wat het nu is. Het succes dat hij hiermee oogst mag dan ook dienen tot voorbeeld. Tenslotte nog een speciaal woord van dank aan mijn vriendin Tine. Zij heeft me altijd bijgestaan in moeilijke momenten. Haar geduld en luisterend oor waren onmisbaar in deze belangrijke periode. Zonder haar steun was deze masterproef wellicht niet geworden wat ze nu is. Tine heeft de teksten nagelezen, correcties aangebracht, voorstellen tot wijziging gedaan en me bijgestaan om de tekst zo duidelijk mogelijk te formuleren.

Johnny Rymenans

juni 2010



p 11/96

2 Voorstelling van Invent Design 2.1 Situatieschets Een designer is een kunstenaar die zich bezighoudt met zijn kunst. Voor hem is het niet evident om zijn kunstwerken te verkopen. Dit soort vaardigheid maakt immers niet altijd deel uit van de competenties van de kunstenaar. Design heeft als doel te behagen, maar in tegenstelling tot kunst heeft design ook nog een zekere functionaliteit. Designmeubelen -het segment waar Invent Design zich vooral op richt- behoren tot een zone die zich bevindt tussen de kunst en de gebruiksobjecten. Deze objecten lenen zich niet tot massaproductie. In tegenstelling tot een kunstobject echter hebben ze wel het doel om gebruikt te worden. Invent Design wil een leemte in de markt vullen. Het wil een platform aanbieden dat potentiële klanten in contact brengt met de kunstenaars. Jean Van der Biest, bedrijfsleider van Invent Design, formuleert het als volgt: “(Het opzet van) Invent Design is een commercieel platform (oprichten) binnen de internationale kunstmarkt, voor meubel- en interieur-objecten van designers uit het Vlaamse Gewest die door hun concept en intrinsieke waarde meer zijn dan louter een mooi ogend gebruiksobject. Daardoor zijn het kunstobjecten die nauwelijks voor serieproductie vatbaar zijn. Zeg maar de haute couture van het design. Door tal van inspanningen wil Invent Design een strategische meerwaarde creëren zowel voor de klant als voor de kunstenaar. Om garant te kunnen staan voor de waarden die zij uitdraagt zal Invent-Design ook instaan voor het organiseren van de selectie, productie, distributie en remuneratie. Zo is onder meer Duurzaam en Ethisch Ondernemen een belangrijk aspect bij het maken van strategische keuzes.”

Invent Design richt zich vooral op de meer gegoede liefhebber van hedendaagse kunst en designmeubels. Daarnaast wil men na verloop van tijd ook die concepten voor een groter publiek ter beschikking stellen onder de vorm van o.a. merchandising artikelen, schaalmodellen, …

Johnny Rymenans

juni 2010



p 12/96

2.2 Hoe past deze masterproef in dit project Het opzet van de zaakvoerder was een online bedrijf op te bouwen. Het doel van deze masterproef was dan ook om een framework op te zetten dat het mogelijk maakt om de objecten van een kunstenaar beschikbaar te maken voor potentiële kopers. Het middel bij uitstek is een website. De kunstenaars kunnen hun objecten indienen vergezeld van een beschrijving, specificaties en andere nuttige informatie. Potentiële kopers kunnen door middel van een soort webshop de ingediende objecten bekijken en uiteraard aankopen. Daarenboven moest de website ook zo opgebouwd worden dat de zaakvoerder of zijn medewerkers gemakkelijk content kunnen toevoegen zonder te moeten programmeren. Hierdoor werd er gekozen om gebruik te maken van een Content Management System, Drupal in dit geval. Het voordeel van een dergelijk CMS is dat het modulair uitbreidbaar is en dat alles wat men nodig heeft om eenvoudige content toe te voegen reeds inherent aanwezig is. Wanneer de wensen iets uitgebreider of complexer zijn, dient er wel een module geschreven of aangepast te worden. Het uiteindelijke doel van de masterproef was dat een framework zou worden opgezet zodat een gebruiker (een klant, kunstenaar, beheerder, …) enkel en alleen een browser nodig heeft. Alle handelingen moeten via deze browser gebeuren: het bedrijf beheren, kunstobjecten modereren, facturen opstellen, e-mails verzenden content toevoegen, … Dit sluit overigens perfect aan bij de trend die recent steeds meer opgang maakt van allerlei diensten aan te bieden als online services, ook wel Software as a Service genoemd of afgekort SaaS. Aangezien dat er aan de topklanten een extra dienst -het aanbieden van een previewwordt aangeboden, dient hier onderzoek naar gedaan te worden. Als resultaat van dit onderzoek wordt een werkend proof of concept verwacht, namelijk de previewapplicatie.

Johnny Rymenans

juni 2010



p 13/96

3 Drupal Aangezien de volledige masterproef opgebouwd wordt met behulp van Drupal, wordt dit open-source web content management framework kort toegelicht. De boeken Pro Drupal Development – zowel de first als second edition – worden door Drupal developers als onmisbare lectuur beschouwd. Deze werken werden dan ook uitgebreid geraadpleegd voor deze toelichting. Drupal wordt gebruikt om websites te bouwen. Het is zeer modulair opgebouwd, uitbreidbaar, houdt zich aan standaarden en streeft naar goede code, ook onder meer qua beveiliging. Wanneer men Drupal downloadt, krijgt men de basis core-functionaliteit ter beschikking. Wenst men meer functionaliteit, dan kan deze verkregen worden door de installatie van extra modules. Dit kunnen zowel eigen geschreven modules zijn als contributed modules die men kan downloaden van http://drupal.org. Het is de bedoeling dat Drupal wordt aangepast aan de eigen noden door het overschrijven van de core door middel van modules, en niet door het aanpassen van de source-code van core zelf, die men wel ter beschikking heeft. Modules kunnen die code overschrijven door het implementeren van hooks, dewelke door Drupal worden aangeroepen. Drupal gebruikt hiertoe het Inversion of Controle design pattern om deze code dan op het juiste moment aan te roepen. Naast een toegewijd team van programmeurs dat instaat voor de beveiliging van de Drupal core is er ook nog de Drupal Association die niet alleen bijdraagt tot de verbetering van de website infrastructuur, maar ook evenementen en samenkomsten organiseert. Verder is er nog de uitgebreide community die bestaat uit gebruikers, programmeurs, site beheerders, … . De community is ook een belangrijke factor die bijdraagt tot de verbetering en het succes van Drupal.

3.1 De technology stack

Figuur 1: Technologiestack van Drupal (Pro Drupal Development (VanDyk & Westgate, 2007))

Johnny Rymenans

juni 2010



p 14/96

Drupal wil degelijk functioneren op goedkope hosting én voor grote gedistribueerde sites. Daarom werd er gekozen voor de meest gebruikte technologieën en wordt er ook veel gewerkt om zo gestroomlijnd mogelijk code te schrijven. Figuur 1 toont de technologiestack waar Drupal zich op baseert. Drupal is platformonafhankelijk op voorwaarde dat PHP ondersteund wordt. Verder wordt er gebruikgemaakt van een data-abstraction layer. Op die manier ondersteunt Drupal ook andere databases als de standaard MySQL of PostgreSQL ondersteunt. Drupal zelf -en alle modules- zijn volledig geschreven in PHP.

3.2 De Core Figuur 2 toont een aantal functionaliteiten van de core (vet), een aantal aanvullende modules (niet vet) en de eigen geschreven modules (de module in stippellijn).

Figuur 2: Drupal Core en aanvullende modules (Pro Drupal Development (VanDyk & Westgate, 2007))

Core is, zoals de naam aangeeft, de kern van het content management system. Deze modules worden onderhouden door een beperkte groep programmeurs, zij moeten ervoor zorgen dat bugs en beveiligingsproblemen worden opgelost. Wanneer er belangrijke beveiligingsupdates worden doorgevoerd wordt er een nieuwe versie van Drupal uitgebracht. Wanneer men extra functionaliteit aan de Drupal installatie wil toevoegen, kan men dit doen door het aanschakelen van extra modules.

Johnny Rymenans

juni 2010



p 15/96

3.3 Modules in Drupal Zoals reeds werd aangehaald, voegen modules functionaliteit toe aan Drupal door het implementeren van hooks. (...)"The Template Method pattern leads to an inversion of control known as the 'Hollywood Principle,' or, 'Don't call us; we'll call you.' "(...) (John Vlissides, 1996)

Het systeem van modules in Drupal is gebaseerd op het concept van hooks. Drupal gebruikt het Inversion of Controle design pattern om deze hooks op het gepaste moment op te roepen. Een hook is een PHP functie bv: foo_bar(). Hierin verwijst “foo” naar de naam van de betreffende module (de bestandsnaam is dus ook “foo.module”) en “bar” verwijst dan naar de hook die men wil overschrijven. Elke hook heeft een welbepaalde parameterset en een specifieke teruggeefwaarde. Om Drupal uit te breiden zal een module dus één (of meerdere) hooks moeten overschrijven. Wanneer Drupal een tussenkomst nodig heeft van modules, dan bepaalt Drupal welke modules deze hook implementeren en zal het dan ook die hook oproepen in alle modules die deze hook implementeren. De beschikbare hooks kan men terugvinden in de application programming interface (API) van Drupal. Deze API is beschikbaar gesteld op http://api.drupal.org. Hier kan men voor elke versie van Drupal de interface voor een hook terugvinden. De betekenis van een hook wordt uitgelegd, de betekenis van de parameters die de hook verwacht wordt gegeven en er wordt meestal ook een voorbeeld van een implementatie gegeven. Deze voorbeelden zijn vaak de implementatie zoals die gebruikt wordt in één van de core modules. Om dit te illustreren, wordt naar het codefragment in Appendix B verwezen. Het betreft hier een kleine en eenvoudige module om een object te kiezen. Er wordt een dropdownlist getoond en de keuze van het object wordt weggeschreven in de databank. De PHP-code wordt opgeslagen in een bestand met extensie .module (de
juni 2010



p 16/96

zal een module voor Drupal6 worden gebruikt in de codefragmenten. De keuze om de code van de Drupal5 module toch toe te voegen in de Appendix, werd ingegeven om aan te tonen dat er een aantal verschillen zijn tussen Drupal5 en Drupal6. Deze verschillen in onder andere de interface zorgen ervoor dat de modules niet uitwisselbaar zijn tussen de versies van Drupal. In een later hoofdstuk zal ook dieper ingegaan worden op de keuze om over te schakelen naar Drupal6.

3.4 Het concept: node In Drupal, heeft elk stuk inhoud een content type. Wanneer men content wil toevoegen aan de site, dient men een keuze te maken tot welk content type die inhoud behoort. Bij een standaard Drupal installatie bestaat die keuze uit een Page, Story, Blog, ... . Men kan de keuzemogelijkheden uitbreiden met eigen content types, zoals bv: Kunstobject, Gejureerd Object, Bestelling, ... Al deze content types verschillen van elkaar op één of andere manier, toch delen ze allen een aantal dezelfde eigenschappen. Alle content types zijn namelijk afgeleid van één basis type waarnaar gerefereerd wordt als een node. Zo heeft elk content type een titel, een auteur, een datum waarop ze zijn aangemaakt, en kunnen de revisions opgeslagen worden. Drupal behandelt alle content types, hoe verschillend ze ook mogen zijn, dus als nodes. Deze manier om content te benaderen zorgt ervoor dat Drupal zo flexibel en uitbreidbaar is.

3.5 De mappenstructuur van Drupal Wanneer men de recentste versie van Drupal downloadt van http://drupal.org, dan ontvangt men een bestand met extensie ".tar.gz". Wanneer dit bestand is uitgepakt wordt de mappenstructuur uit Figuur 3 verkregen. Voor meer informatie in verband met de installatie van Drupal wordt er naar Appendix A verwezen. De map "modules" bevat de core-modules van de Drupal installatie. Wanneer men contributed modules, of eigen geschreven modules wil toevoegen aan de Drupal installatie, dan dient men deze te plaatsen in mappen onder de "sites -> all ->modules" map. Deze conventie wordt gehanteerd opdat een update van Drupal, bv: Drupal6.15 naar Drupal6.16, geen probleem zou geven wanneer men van de "sites -> all >modules" map een backup heeft genomen. In Figuur 4, op pagina 18, wordt de inhoud van deze map getoond voor de Invent Design site. Deze map bevat een heel aantal gecontribueerde modules, het aantal kan snel oplopen wanneer er een aantal modules gebruikt worden die dependencies (afhankelijkheden) hebben. De belangrijkste modules zijn Content Construction Kit (CCK) en Views. In Drupal7 behoort de Field API (CCK) tot Core, wat het belang van CCK aantoont. Verder zijn er Johnny Rymenans

juni 2010



p 17/96

nog de modules amfphp en services die nodig zijn voor de previewapplicatie, ubercart (eigenlijk een framework) voor het ecommerce gedeelte, ... Naast de contributed modules zijn er tenslotte ook nog de eigen geschreven modules, zoals daar zijn, inv_categorieen, invent_features, inventdesign_views, inv_finalise_jurering, flexxml_service, x_mimemail en inv_finalise_object. Naast de zelf geschreven modules is er nog een contributed module aangepast, namelijk customnodereference_url, die een aanpassing is van de nodereference_url module. Als laatste is er ook nog de module x_contact_option. Deze laatste module -een module die niet tot de contributed modules behoort- werd aangepast omdat de originele code een fout bevatte. In een later hoofdstuk zal er dieper ingegaan worden op de gebruikte en geschreven modules.

Figuur 3: Mappenstructuur Drupal6

Johnny Rymenans

juni 2010



p 18/96

Figuur 4: Contributed & eigen modules voor Invent Design

Johnny Rymenans

juni 2010



p 19/96

4 Het schrijven van een module Zoals reeds werd vermeld kan men door het schrijven van modules, extra functionaliteit toevoegen aan Drupal. Men kan door middel van het implementeren van hooks ook bestaande functionaliteit aanpassen. In principe kan men die functionaliteit rechtstreeks in de Core wijzigen, aangezien men de broncode ter beschikking heeft. Dit wordt echter ten stelligste afgeraden. Het aanpassen van de Core kan niet alleen bugs en security problemen veroorzaken, het leidt bovendien tot code en een site die niet te onderhouden valt. Elke keer wanneer Drupal update naar een nieuwe versie, moet men die aanpassingen opnieuw doen. Bovendien is het best mogelijk dat de aanpassing niet meer werkt omwille van de wijzigingen die werden aangebracht door de update. De code van een module moet voldoen aan een aantal standaarden en afspraken. Deze afspraken kan men vinden op http://drupal.org/coding-standards (Coding standards). Verder is het ook aangewezen om http://api.drupal.org (Drupal API) ten allen tijde ter beschikking te hebben. Iedere module wordt in een eigen map opgeslagen. Er wordt aangeraden om een module op te slaan in de /sites/all/modules directory. De modules directory moet men zelf creëren. In deze directory creëert men een nieuwe map met de naam van de module. De namen van de files moeten voldoen aan de standaard afspraken namelijk: <modulenaam>.module, <modulenaam>.install en <modulenaam>.info, waarbij <modulenaam> wordt vervangen door de naam van de module. Indien men de module wil verspreiden, dan kan men een README.txt bestand toevoegen. De uitleg die volgt zal worden geïllustreerd met code van de inv_categorieen module. Deze zelfgeschreven module is één van de custom modules, geschreven voor Invent Design. In de /sites/all/modules directory wordt een nieuwe map aangemaakt, in dit geval inv_categorieen. In deze map maakt men drie bestanden aan, genaamd inv_categorieen.module, inv_categorieen.install en inv_categorieen.info.

4.1 inv_categorieen.info Het .info bestand bevat info over de inv_categorieen module die Drupal nodig heeft. Dit bestand wordt geschreven in het .ini formaat, een eenvoudige standaard voor PHP configuratiefiles (meer informatie over dit formaat kan men vinden op http://php.net/parse_ini_file). ; $Id$ name = inv_categorieen description = Module die de juryleden de kans geeft om een categorie toe te voegen. Elk jurylid heeft zijn eigen vocabulair om in zijn juryobjecten een kunstobject tot een categorie toe te wijzen. core = 6.x package = Invent Design

De eerste regel is slechts een placeholder voor de Concurrent Version System server(CVS server) van Drupal. De name en description zijn vanzelfsprekend, de naam van de Johnny Rymenans

juni 2010



p 20/96

module en de beschrijving van de module en zijn mogelijkheden. De regel core geeft aan voor welke versie van Drupal deze module bedoeld is. De laatste regel, package, geeft aan tot welk pakket de module behoort. Indien niets wordt ingegeven komt de module bij de groep Other terecht. Een directief dat ook gebruikt wordt is het dependencies[] directief. Het geeft aan van welke andere modules deze module afhankelijk is. Indien een module gebruik maakt van functies van PHP die niet door alle versies van PHP ondersteund worden, omdat ze pas in een latere versie zijn toegevoegd, dan kan het php directief gebruikt worden.

4.2 inv_categorieen.module Vervolgens bespreken we de .module file. Dit is de file die de implementatie van de hooks bevat. Er wordt gebruik gemaakt van PHP om de hooks te implementeren. In de voorbeeldmodule worden volgende hooks geïmplementeerd: hook_menu(), hook_form(), hook_form_submit() en hook_perm(). De .module file begint met sluit tag geplaatst zou worden, dan zouden de whitecharacters op het einde van de file ook afgedrukt worden, wat problemen oplevert wanneer deze whitecharacters verstuurd worden voordat de HTTP-headers verzonden zouden zijn. Het volgend codefragment zorgt ervoor dat er een menu-link wordt aangemaakt met als titel Voeg categorie toe. Wanneer op deze link geklikt wordt, zal er een functie opgeroepen worden (een callback) namelijk drupal_get_form, deze functie krijgt als argument de form ID, inv_categorieen_form. Op deze manier is bepaald welk formulier door Drupal opgebouwd moet worden. Verder wordt er ook aangegeven welk permissions men nodig heeft om dit formulier aan te mogen roepen. Het type MENU_NORMAL_ITEM geeft gewoon aan dat de link in de menustructuur wordt getoond. t('Voeg categorie toe'), 'page callback' => 'drupal_get_form', 'page arguments' => array('inv_categorieen_form'), 'access arguments' => array('add categorie'), 'type' => MENU_NORMAL_ITEM, ); return $items; }

De functie inv_categorieen_form() definieerd hoe het formulier er zal uitzien. In Drupal wordt een formulier voorgesteld als een geneste boomstructuur, een array van arrays. Aangezien we een gebruiker de mogelijkheid willen geven om persoonlijke categorieën toe te voegen, tonen we eerst welke categorieën de persoon reeds heeft opgeslagen in de databank. Om de categorieën van een gebruiker te kunnen opzoeken in de databank geven we eerst aan dat we de globale variabele $user willen gebruiken. Deze variabele Johnny Rymenans

juni 2010



p 21/96

geeft toegang tot het object dat de huidige gebruiker voorstelt. Er wordt nu een query opgesteld die deze gegevens uit de databank haalt, en in de while lus worden de categorieën aan elkaar geplakt gescheiden door een ",". Deze string wordt getoond in het element van type item, wat gewoon een display only field is.

Verder wordt er nog een invoerveld gedefinieerd met opschrift Voeg categorie toe. Tenslotte wordt het formulier vervolledigd met een submit button. function inv_categorieen_form() { global $user; $form = array(); $lijstje = ""; $my_res = db_query("SELECT categorie FROM {juryobject_categorieen} WHERE jurylid_id=%d ORDER BY categorie ASC", $user->uid); while( $my_li = db_fetch_array($my_res) ){ $lijstje .= $my_li['categorie'] . ", "; } $form['huidige_categorieen'] = array( '#type' => 'item', '#title' => t('Uw huidige categorien'), '#value' => check_plain($lijstje), ); $form['voeg_categorie_toe'] = array( '#type'=> 'textfield', '#title' => t('Voeg een categorie toe'), '#required' => TRUE, '#description' => t('Voor de leesbaarheid wordt het afgeraden van tekens zoals < en > en & te gebruiken, deze worden namelijk encoded.'), ); $form['submit'] = array( '#type' => 'submit', '#value' => t('Voeg toe') ); return $form; }

In de submit hook wordt gewoon de door de gebruiker ingevoerde tekst opgeslagen door de databank. Er wordt wel gecheckt of de invoer van de gebruiker speciale tekens bevat, indien dit het geval is, dan worden deze gecodeerd. Verder wordt ook nagegaan of de string wel een geldige UTF-8 string is, dit ter preventie tegen cross site scripting attacks. Er wordt ook gebruik gemaakt van placeholders in de query. De db_query() functie zal hier dan rekening mee houden dat de inhoud van de variabele overeenstemt met het verwachte type van de placeholder. function inv_categorieen_form_submit(&$form, &$form_state) { global $user; $cat = check_plain($form_state['values']['voeg_categorie_toe']); db_query("INSERT INTO {juryobject_categorieen} (jurylid_id, categorie) VALUES (%d, '%s')", $user->uid, $cat); }

Tenslotte implementeren we nog de hook_perm(). Dit is de functie die teruggeeft welke permissions de module definieert. Deze kunnen dan gecheckt worden met de functie user_access().

Johnny Rymenans

juni 2010



p 22/96

function inv_categorieen_perm() { return array('add categorie'); }

In deze module werd er ook rekening gehouden met de mogelijkheid tot vertaling. Door de strings die op het scherm worden getoond in de translation functie "t()" te plaatsen, werd ervoor gezorgd dat de string kan vervangen worden door een vertaling. Hiervoor dient wel de Content translation module aangeschakeld te zijn, en dient de taal die men wenst te gebruiken ondersteund te zijn. Tot slot vermelden we nog dat een functie die alleen als hulp dient voor de huidige module, bij afspraak voorafgegaan wordt door een "_". Dit geeft aan dat de functie niet buiten deze module dient gebruikt te worden.

4.3 inv_categorieen.install Eén van de vernieuwingen van Drupal 6 is de Schema API. Wanneer men de .install van de voorbeeldmodule in Appendix B vergelijkt met inv_categorieen.install kan men het verschil snel opmerken. In Drupal 5 werd de creatie van een tabel in de databank gedaan door het schrijven van de SQL. Dit betekent dat men rekening moest houden met het type databank, vandaar de switch-case. Nu is dit niet meer het geval, dankzij de Schema API hoeft men geen rekening meer te houden met het databankdialect. Een Drupal schema definitie is een arraystructuur die één of meerdere tabellen voorstelt, tezamen met hun keys en indices. In hook_schema() wordt de structuur van de tabel(len) gedefinieerd die door de module gedeclareerd worden. Door het implementeren van de hook_install() en hook_uninstall() kunnen de tabellen dan makkelijk worden gecreëerd of gedropt. t('Tabel die categorieen per jurylid bijhoudt'), 'fields' => array( 'jurylid_id' => array( 'description' => t('Het uid van het jurylid dat deze categorie heeft toegevoegd.'), 'type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE, ), 'categorie' => array( 'description' => t('De categorie die het jurylid heeft toegevoegd.'), 'type' => 'varchar', 'length' => '80', 'not null' => TRUE, ), ), 'primary key' => array('jurylid_id', 'categorie'), ); return $schema; }

Johnny Rymenans

juni 2010



p 23/96

function inv_categorieen_install() { // Create my tables. drupal_install_schema('inv_categorieen'); } function inv_categorieen_uninstall() { // Drop my tables. drupal_uninstall_schema('inv_categorieen');

De bovenstaande code creëert de tabel die in Figuur 5 wordt voorgesteld.

Figuur 5: De juryobject_categorieen tabel

De code die gegenereerd wordt komt ongeveer overeen met volgende SQL-code:

CREATE TABLE IF NOT EXISTS `juryobject_categorieen` ( `jurylid_id` int(10) unsigned NOT NULL, `categorie` varchar(80) NOT NULL, PRIMARY KEY (`jurylid_id`,`categorie`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

4.4 Het resultaat van de deze module Figuur 6 toont het formulier dat de gebruiker van de module te zien krijgt. Uiteraard kan dit resultaat er anders uitzien naar gelang het theme dat gebruikt wordt op de site. In het screenshot is te zien dat de gebruiker reeds drie categorieën heeft, namelijk: na de aanpassing, testcategorie_1 en testcategorie_2. De gebruiker is een nieuwe categorie genaamd Nieuwe categorie aan het toevoegen.

Figuur 6: Het voeg categorie toe formulier

Johnny Rymenans

juni 2010


Johnny Rymenans


p 24/96

juni 2010



p 25/96

5 Analyse, opbouw en implementatie van de site 5.1 Indeling in rollen Rollen en de daarbij horende permissies worden in Drupal gebruikt als toegangscontrole van de content (inhoud, informatie) van de site. De benodigde rollen voor Invent Design zijn: Admin Medewerker Jurylid Topklant Auteur Merchandising (standaard) Leverancier De rollen van Admin en Medewerker zijn rollen met uitgebreide privileges die hen in staat moeten stellen om de site te onderhouden. De rol van Jurylid wordt toegekend aan mensen die uitgenodigd zijn door de zaakvoerder omdat zij een zekere kennis moeten hebben om (kunst-) objecten te beoordelen. Deze rol vereist een toelating van de admin. Topklanten en Juryleden kunnen zich, net als de drie laatste rollen, zelf op de site registreren, maar zullen pas na een extra evaluatie van de admin hun rol toegewezen krijgen. Deze gebruikers zullen dus, zolang hun aanvraag in behandeling is, de standaardrol van Merchandising toebedeeld krijgen. Om de behandeling van de aanvraag tot een Topklant-account zo snel mogelijk te laten gebeuren zal er automatisch een e-mail gestuurd worden naar de admin. De laatste drie rollen zijn een mogelijke rol die men zichzelf toekent bij registratie op de site tijdens de aanmaak van een gebruikersprofiel. Defaultwaarde is "merchandising". Er werd gevraagd om bij de initiële opstart van de site een e-mail te versturen bij elke registratie, dit tot zolang dit realistisch is voor de ontvanger ervan. Het doel is op de hoogte te blijven van wie er zoal een account aanmaakt of tracht aan te maken en voor welke rol: merchandising, auteur of leverancier. Benodigde modules: Auto-assign-role module “een mail module” In het vervolg van de analyse gaan we verder in op deze rollen en het nut ervan. Johnny Rymenans

juni 2010



p 26/96

5.1.1 Auteur Deze rol is bedoeld voor de auteur of kunstenaar die zijn (kunst)object wil aanbieden, en daardoor wenst gebruik te maken van de diensten van het bedrijf Invent Design. Auteurs hebben de mogelijkheid om de gegevens van hun object in te geven in een formulier, hierbij hebben ze ook de mogelijkheid om een aantal foto’s toe te voegen. Zolang een auteur zijn object(en) niet als afgesloten aanvinkt kan hij nog wijzigingen aanbrengen. Wanneer een object wordt afgesloten, zal het aan de juryleden aangeboden worden ter quotering. Wanneer de zaakvoerder besluit om het object te vertegenwoordigen, steunend op het advies van de juryleden, zal het object uiteindelijk ook aan de topklanten aangeboden worden. Zodra de auteur een object als afgesloten heeft aangeduid wordt het voorgelegd aan de admin (melding per e-mail). Tot zolang kan de auteur het object enkel nog verwijderen en een nieuw object aanmaken met gewijzigde gegevens. Daartoe kan hij het bewuste object met zijn gegevens kopiëren en de wijzigingen aanbrengen. Na akkoord van de admin kan de auteur geen enkele wijziging meer aanbrengen aan de gegevens van het object vermits het object vanaf dan aangeboden wordt aan de juryleden en verder in procedure gaat. De auteur kan evenwel zijn ingeleverde en afgesloten objecten nog steeds bekijken en desgewenst er een kopie van maken zoals hoger aangegeven.

5.1.2 Jurering Juryleden zijn gebruikers die door de zaakvoerder zijn uitgenodigd om de door de auteurs ingediende (kunst-)objecten te beoordelen en te quoteren omwille van hun expertise ter zake. De site moet voor de juryleden een bruikbaar werktuig zijn om hun taak zo makkelijk mogelijk te maken. Elk jurylid heeft afzonderlijk de mogelijkheid om aan de objecten een volgnummer toe te kennen dat enkel voor hemzelf gekend is. De quotering is een getal van 1 – 10 en wordt als volgt verdeeld: 11 = Default : het object werd nog niet gequoteerd . 0 = Verworpen: het object voldoet niet aan de criteria van het jurylid. [1 - 10] = quotering Aan de hand van deze quoteringen kan het jurylid de objecten bekijken en ordenen. Een jurylid krijgt de mogelijkheid om een object te voorzien van persoonlijke commentaar en publieke commentaar. Verder kan het jurylid voor zichzelf een object aan een bepaalde categorie toewijzen, met andere woorden de objecten indelen in categorieën. Opmerking: Juryleden moeten voor zichzelf categorieën kunnen aanmaken, deze faciliteit is wel van lagere prioriteit.

Johnny Rymenans

juni 2010



p 27/96

5.1.3 Topklanten Deze rol wordt door de admin toegekend aan een gebruiker en geeft hem de mogelijkheid om de objecten te bekijken op een exclusieve wijze. Hij krijgt een catalogus te zien van deze topstukken en kan een bestelling plaatsen. Hij kan enkel een kopie van een object kopen op bestelling. Wanneer een topklant besluit een object te bestellen, komt hij op een pagina terecht die hem de procedure voor verdere afhandeling van de verkoopsprocedure uitlegt. Dit garandeert dat de klant de tijd en toewijding krijgt die zijn aankoop verdient. Als de klant akkoord gaat met de procedure, ontvangen hij en de zaakvoerder een bevestiging per e-mail. Het verdere verloop van de verkoop wordt door de zaakvoerder persoonlijk afgehandeld met die klant. Indien de onderhandelingen uiteindelijk resulteren in een aankoop, kan de klant de realisatie van zijn aankoop opvolgen via de site. De leveranciers wordt gevraagd om op geregelde tijdstippen de status aan te geven van de objecten waar zij voor instaan. Wanneer er een bestelling wordt geplaatst zal er een nieuw object worden aangemaakt in de databank. In dit object worden een aantal gegevens opgeslagen: Verwijzing naar het typeobject (moederobject) Verwijzing naar de koper (verwijst naar zijn user) Verwijzing naar de leverancier(s) Besteldatum Te leveren datum Geleverde datum Verkoopprijs Voorschot Status: Verkocht, In behandeling, Geannuleerd Volgnummer: Het betreft hier een beperkte oplage en dit nummer identificeert dan om welk object het gaat. Verwijzing naar het logboek van het productieverloop van het object

5.1.4 Merchandising Dit is de rol die standaard aan elke gebruiker wordt toegekend. Het geeft gebruikers toegang tot de afdeling merchandising. Dit luik zal opgebouwd worden als een webshop met catalogus en winkelwagentje. Dit is ook de rol die juryleden en topklanten initieel zullen hebben zolang hun aanvraag tot hun uiteindelijke rol in behandeling is. Benodigde modules: Het Ubercart framework kan hiervoor gebruikt worden.

Johnny Rymenans

juni 2010



p 28/96

5.1.5 Leverancier Deze rol is bedoeld voor leveranciers die zullen aangesproken worden om de kunstobjecten te produceren. Het is de bedoeling dat elke leverancier de zaakvoerder en de koper op de hoogte houdt over de status van de objecten waar zij voor instaan. Dit bevordert de transparantie van het verkoopproces en het vertrouwen van de klant. Dit luik moet daar mee voor zorgen. Van zodra een object besteld wordt zal er een pagina met logboek gecreëerd worden voor dat object, waartoe de leveranciers die voor dat object verantwoordelijk zijn, toegang krijgen. Het is hun verantwoordelijkheid om op geregelde tijdstippen een commentaar toe te voegen aan het logboek van dat object. Deze commentaar dient een korte beschrijving te geven die de status van het object in het productieproces moet duidelijk maken. Dit logboek is zichtbaar voor de leverancier en topklant (koper) in kwestie, maar ook voor de medewerkers en de admin. Een entry in het logboek zal opgeslagen worden met een datum. Verder kan er op deze entry ook gereageerd worden door de andere betrokkenen. Er is ook de mogelijkheid om de zaakvoerder te contacteren via dit formulier, de informatie die dan uitgewisseld wordt, zal niet publiek gemaakt worden.

5.2 Schema’s 5.2.1 Pagina-aanvragen Bij elke pagina-aanvraag ondergaat Drupal een bootstrap-procedure. Drupal moet een aantal fasen doorlopen die het framework in staat stellen om de pagina, die een gebruiker aangevraagd heeft, aan te kunnen bieden. De eerste fase is het initialiseren van de configuratie array. Vervolgens komt de early page cache fase. Deze fase is van belang als er een grote mate van schaalbaarheid wordt vereist. Daarna wordt er bepaald met welke databank er wordt gewerkt. Het is in deze fase dat de connectie met die databank wordt aangemaakt die gebruikt zal worden voor de queries. Na deze fase wordt de toegang gecontroleerd van het IP en de Host van de gebruiker. Dan wordt de sessie geïnitialiseerd. In de late cache fase wordt bepaald of een pagina uit de cache wordt geladen of opnieuw wordt opgebouwd. Vervolgens wordt de taal bepaald. In de volgende fase wordt het mogelijk om gebruiksvriendelijke URL’s op te bouwen. Uiteindelijk laadt Drupal nog een aantal veel gebruikte bibliotheken. Wanneer de laatste details zijn afgehandeld en de modules geladen zijn, wordt de init_hook() afgevuurd. Drupal kan nu nagaan of de callback die de gebruiker heeft aangevraagd, bestaat. Als de gebruiker de vereiste permissions heeft zal die callback uitgevoerd worden. Deze callback zal de benodigde gegevens nu uit de databank halen en de gegevensstructuur aanvullen. Het is het theming framework dat de HTML zal opstellen aan de hand van de Johnny Rymenans

juni 2010



p 29/96

datastructuur die in voorgaande fases werd opgebouwd. Uiteindelijk zal die gegenereerde HTML door de browser aan de gebruiker worden weergegeven.

5.2.2 Inloggen In Figuur 7, op pagina 31, wordt schematisch voorgesteld wat er gebeurt wanneer een gebruiker wil inloggen op de site. Een gebruiker zal een login pagina aanvragen en Drupal zal de bootstrap procedure doorlopen. Wanneer de login pagina opgebouwd is, zal de gebruiker zijn login naam en paswoord kunnen ingeven. De gegevens die door de gebruiker werden verstrekt, worden gevalideerd. Wanneer de gegevens ongeldig blijken, zal de login pagina weergegeven worden, in het andere geval is de gebruiker succesvol ingelogd. Aan elk gebruikersaccount is een rol toegewezen, deze rol bepaalt welke rechten een gebruiker heeft. De look en mogelijkheden van de site zijn ook afhankelijk van de rol waartoe een gebruiker behoort.

5.2.3 Voorbeeld1: de merchandising rol In Figuur 8, op pagina 32, wordt het schema voorgesteld voor een gebruiker met de merchandising rol, die tevens de standaard rol is. De gebruiker zal een catalogus te zien krijgen die alle merchandising artikelen zal tonen die Invent Design aanbiedt. Wanneer men een interessant artikel heeft gevonden kan men dit toevoegen aan het winkelkarretje. De aankoopprocedure wordt dan verder afgehandeld met behulp van bestaande gangbare betalingsprocedures.

5.2.4 Voorbeeld2: de auteursrol In Figuur 9, op pagina 33, wordt het schema voor het indienen van een kunstobject door een auteur (of kunstenaar) voorgesteld. Bij het opslaan van een object worden foto’s van het object naar de server gestuurd. Dit gebeurt door gebruik te maken van de upload-module.

Johnny Rymenans

juni 2010



p 30/96

5.2.5 Voorbeeld3: de topklant rol In Figuur 10, op pagina 34, toont het schema dat de topklanten het voorrecht hebben om gebruik te maken van een previewapplicatie. Deze faciliteit heeft als doel dat de topklant een foto van zijn interieur kan laden om na te gaan of een kunstobject wel of niet in zijn interieur past. De foto’s van die objecten staan opgeslagen op de server. Door middel van een services module en een zelfgeschreven service kan de previewapplicatie deze foto’s laden. Op het onderwerp van deze applicatie zal nog verder ingegaan worden.

Johnny Rymenans

juni 2010



p 31/96

Figuur 7: Inloggen van een gebruiker

Johnny Rymenans

juni 2010



p 32/96

Figuur 8: Voorbeeld Merchandising rol

Johnny Rymenans

juni 2010



p 33/96

Figuur 9: Voorbeeld Auteursrol

Johnny Rymenans

juni 2010



p 34/96

Figuur 10: Voorbeeld Topklant rol

Johnny Rymenans

juni 2010



p 35/96

Figuur 11: De previewapplicatie

Johnny Rymenans

juni 2010


Johnny Rymenans


p 36/96

juni 2010



p 37/96

6 De gebruikte modules Wanneer de analyse van de site gebeurd is, kan er gezocht worden naar de modules die nodig zijn om de functionaliteit aan te bieden die nodig is om de analyse te implementeren. De zoektocht naar de juiste modules is een proces dat met de nodige zorg dient uitgevoerd te worden. Het is een vaak voorkomend probleem is dat men al snel een overvloed aan modules gaat toevoegen aan de site. Er dient opgemerkt te worden dat het toevoegen van modules vaak gepaard gaat met een verlies aan performantie. Hoe meer modules er zijn toegevoegd, hoe meer werk een site zal moeten verrichten om een pagina te laden. Aangezien er duizenden modules zijn om uit te kiezen, is het dus niet zo verwonderlijk dat men vaak door de bomen het bos niet meer ziet. Een belangrijke tip die men kan gebruiken om gericht naar modules te zoeken is om volgende pagina te raadplegen: http://drupal.org/project/usage. Deze pagina geeft aan welke modules het meest gebruikt worden. Deze pagina kan handig zijn om de modules te identificeren die men zelf nodig heeft. Een bijkomend voordeel van deze modules is het feit dat ze beter getest en gedebugged zijn. Doordat ze zo vaak gebruikt worden, komen bugs namelijk sneller aan het licht en worden ze dan ook sneller opgelost. Wanneer er uiteindelijk nog functionaliteit nodig is, die men niet in contributed modules kan vinden, dan kan men zelf deze functionaliteit in de vorm van een module schrijven. De reden waarom bepaalde functionaliteit niet gevonden wordt in de immense verzameling van contributed modules, is meestal omdat ze (te) specifiek is voor de site in kwestie. In wat volgt, worden een aantal van de belangrijke modules kort toegelicht, wordt er een uitleg gegeven voor de aanpassing van nodereference_url module en wordt er uiteindelijk ook een toelichting gegeven bij de zelfgeschreven modules.

6.1 Contributed modules Zoals reeds eerder werd vermeld, zijn er duizenden contributed modules. De meeste van deze modules voegen functionaliteit toe aan de site, maar er zijn ook een aantal modules die functionaliteit toevoegen voor de ontwikkelaar van de site. Tot deze tweede groep van modules horen modules als de Devel module, de Administration menu module, de Schema module, de Coder module, ... ook deze laatste modules worden kort toegelicht in dit hoofdstuk. In dit hoofdstuk worden veelgebruikte modules besproken, waaronder een groot aantal van de modules die voor deze masterproef gebruikt werden en de modules die gebruikt werden om de ontwikkeling van het platform te vergemakkelijken. Sommige van de gebruikte contributed modules hebben afhankelijkheden (dependencies) van andere contributed modules, deze modules werden dan ook aangeschakeld, maar hier zal niet Johnny Rymenans

juni 2010



p 38/96

dieper op worden ingegaan. Verder zijn er ook een heel aantal modules die werden uitgeprobeerd omdat ze de benodigde functionaliteit leken te bevatten, maar die uiteindelijk niet werden gebruikt omdat ze ofwel niet compatibel bleken met andere modules, ofwel omdat er andere problemen werden ondervonden. Ook deze modules worden hier niet verder besproken.

6.1.1 Functionaliteit toevoegen voor de site •

Content Construction Kit (CCK) Eén van de belangrijkste en meest gebruikte contributed modules. In Drupal7 is de Field API (CCK) zelfs één van de core modules. Deze module laat toe eigen content types te maken. Dit gebeurt door een nieuw content type te definiëren en er daarna velden aan toe te voegen die men vervolgens kan instellen. Deze velden kan men makkelijk verplaatsen en groeperen. Op http://drupal.org kunnen een overvloed aan "plugin-modules" gevonden worden die extra velden toevoegen die via CCK kunnen gebruikt worden. Een aantal handige velden zijn het Link veld, FileField, Node Reference URL Widget, ... In hoofdstuk 7 worden de content types die voor deze masterproef werden gecreëerd, toegelicht.

•

Views Met de Views module kan men lijsten en tabellen maken van content types zonder zelf SQL-queries te moeten schrijven. Aan de hand van de instellingen van filters, argumenten en velden worden deze queries in de achtergrond door de module zelf opgebouwd. Er is ook de mogelijkheid om de resultaten direct te zien in de Live preview onderaan de pagina waarin de view wordt gedefinieerd. Deze module en CCK zijn een perfecte combinatie. In het hoofdstuk over content types zal ook uitleg gegeven worden bij de ermee verbonden views.

•

Imagefield en Imagecache Imagefield is een module die een upload veld voor foto's toevoegt aan CCK, deze foto's kunnen vervolgens als veld toegevoegd worden aan content types. Views kan deze afbeeldingen dan weer gebruiken in zijn lijsten. Met Imagecache kan men een aantal presets definiëren die men kan gebruiken om bijvoorbeeld thumbnails, gestandaardiseerde formaten voor foto's en dergelijke te creëren.

Johnny Rymenans

juni 2010


•


p 39/96

Pathauto Deze module zorgt ervoor dat er automatisch "mooie" URL’s -aliassen- worden gevormd. De aliassen worden gevormd aan de hand van een "patroon" systeem dat onder controle van de administrator staat.

•

Modules die extra velden aan CCK toevoegen Naast het reeds besproken Imagefield, zijn er nog honderden velden die men aan CCK kan toevoegen. De velden die in deze masterproef zijn gebruikt zijn: Addresses, Link, Node Reference URL Widget, CCK Private Fields, Computed Field, Date en FileField. De meeste van die velden geven goed aan welke functionaliteit ze toevoegen. Zo geeft Addresses een veld dat toelaat adressen toe te voegen, die men per land kan customizen. Link biedt de mogelijkheid om een URL toe te voegen als veld. De Node Reference URL Widget daarentegen is iets minder duidelijk. Dit veld laat toe om een link naar een bepaalde node toe te voegen, waarbij de link automatisch gevormd wordt door gegevens die bekomen worden vanuit de URL. Op deze manier wordt er een relatie tussen de twee nodes gelegd. De CCK Private Fields module laat toe om bepaalde velden privaat, hidden of public te maken voor bepaalde rollen. Computed Fields laten toe om automatisch ingevuld te worden aan de hand van gegevens en PHP code, het Date field biedt de mogelijkheid om een datum toe te voegen als veld, deze module -en zijn mogelijkheden- zijn zéér uitgebreid. Tenslotte biedt het FileField de mogelijkheid om bestanden bij een content type te uploaden en toe te voegen.

•

Services en AMFPHP Services is een gestandaardiseerde API voor ontwikkelaars die toelaat om services te ontwikkelen. Met een service bedoelt men een methode -of collectie van methodes- die door remote applications worden aangeroepen. In het geval van Invent Design is de remote application de previewapplicatie -een in Adobe Flex geschreven applicatie-. Deze applicatie roept de zelfgeschreven flexxml_service aan om een XML file op te stellen en aan te bieden, deze service wordt later uitgebreider besproken. De AMFPHP module biedt AMFPHP ondersteuning aan de services. AMFPHP is de gratis open-source PHP implementatie van het Action Message Format (AMF). AMFPHP implementeert het AMF protocol dat toelaat dat de client-application -de previewapplicatie- kan communiceren met PHP class objects op de server. Deze twee modules zorgen ervoor dat de previewapplicatie naadloos in de Drupal site kon worden geïntegreerd.

Johnny Rymenans

juni 2010


•


p 40/96

Greybox en Lightbox2 Iedereen kent het effect dat vaak gebruikt wordt op websites, waarbij wanneer men op de thumbnail klikt van een foto die men wil bekijken, die foto bovenop de huidige webpagina wordt getoond. Deze twee modules bieden een gelijkaardige functionaliteit aan, maar hebben een verschil in gebruik. De Lightbox2 module kan gebruikt worden om foto's te tonen, hoewel er heel wat meer mogelijkheden zijn. De Greybox module wordt vooral gebruikt om websites te tonen als popup boven de huidige website. Voor Invent Design werd deze module gebruikt om de previewapplicatie als een popup te tonen.

•

Rules Deze module geeft administrators de mogelijkheid om automatisch bepaalde acties te laten uitvoeren wanneer bepaalde events optreden. Zo'n event zou kunnen zijn "een gebruiker heeft zich geregistreerd op de site". Een actie die hieraan kan worden verbonden is bv: "Zend een e-mail naar de administrator van de site".

•

Workflow De Workflow module werkt aan de hand van staten. Wanneer er van de ene status naar een andere wordt overgegaan, kan men acties aan die overgang verbinden. Zo kan men een "volgorde van bewerkingen" toevoegen. Het voorbeeld dat op de projectpagina wordt gegeven is het volgende: Aan de Story node type wordt een workflow toegekend die de staten Draft, Review en Published heeft. Aan de overgang van Draft naar Review wordt een actie "zend e-mail" gekoppeld, vervolgens kan men dan aan de overgang Review naar Published de actie toevoegen die een node ook "Published" zet, wat als gevolg heeft dat ze op de site zichtbaar zal worden.

•

Nodeaccess en Content Access Beide nodes hebben als functie om de toegang tot content te controleren. Nodeaccess is een module die view, edit en delete toelatingen biedt voor nodes. Gebruikers die het grant node permissions recht hebben, krijgen dan een extra tab waardoor ze per gebruiker of per rol de toegang tot die node kunnen bepalen. De Content Access module laat toe om de rechten per rol en per auteur te bepalen.

Johnny Rymenans

juni 2010


•


p 41/96

Autoassignrole Deze module biedt de mogelijkheid om, wanneer er een nieuwe account wordt aangemaakt, automatisch een rol aan die gebruiker toe te kennen. Verder is er de mogelijkheid om gebruikers bij registratie te laten kiezen tot welke rol ze willen behoren. Uiteindelijk is het zelfs mogelijk om aan een gebruiker een rol toe te wijzen die gebaseerd is op een specifiek pad. Wanneer deze module gebruikt wordt in combinatie met de Content Profile module, kunnen zelfs content types fungeren als registratiepagina's.

•

Ubercart Dit is de populairste e-commerce suite voor Drupal. Deze suite maakt het mogelijk om een webshop te creëren en te beheren. Men kan producten en een catalogus aanmaken. Alles aan de front end kan geconfigureerd worden met de standaard Drupal mogelijkheden. Alles wat een e-commerce site nodig heeft, vind men terug bij Ubercart. Het biedt een catalogus, winkelkarretje, betalingsmogelijkheden, facturen, ... Gebruikers kunnen hun orders bekijken in de My Account page. Er wordt ook automatisch een account aangemaakt wanneer een Anonymous gebruiker een aankoop doet. De beheerder van de site kan de orders bekijken, zijn klanten beheren, producten toevoegen en beheren, enz.

•

Wysiwyg Dit is een module die het makkelijker maakt om client side editors in Drupal te integreren. Voorbeelden van zo'n client side editors zijn: CKEditor, FCKeditor, TinyMCE, NicEdit, ... Een client side editor biedt de mogelijkheid om bijvoorbeeld een HTML TextArea een Word of Wordpad achtig uitzicht te geven, zodat men tekst kan opmaken door op buttons te klikken. Dit gebeurt allemaal in de browser, client side.

•

Token Een token is een stukje tekst dat als placeholder fungeert. Dit betekent dat wanneer men een e-mail opbouwt die een aantal tokens bevat, de waarde van die tokens zal worden gesubstitueerd door de eigenlijke waarde. De Token module biedt een API aan voor het gebruik van zulke placeholders. In Drupal6 kan men, als die functionaliteit wordt aangeschakeld, zelfs acties laten uitvoeren die gebruik maken van de substitutie van de waarde van die placeholder.

Johnny Rymenans

juni 2010



p 42/96

6.1.2 Functionaliteit voor de ontwikkelaar •

Administration menu Deze module biedt een administratieve interface aan die onafhankelijk is van het thema. Deze module integreert de mogelijkheden van de Devel module perfect. Verder zorgt het menu ervoor dat alle configuratiemogelijkheden rechtstreeks toegankelijk zijn. Ter illustratie verwijzen we naar Figuur 12.

Figuur 12: Administration menu •

Devel Deze module geeft extra functionaliteit voor developers. Zo kan men het Devel block -geïllustreerd in Figuur 13activeren. Bovendien krijgt men de mogelijkheid om tal van statistieken op te vragen in verband met queries: welke queries er allemaal uitgevoerd worden om een pagina te tonen, de tijd dat deze queries nodig hebben om uitgevoerd te worden, welke queries vaak opgeroepen worden, enz. Al deze gegevens kunnen de ontwerper helpen om te ontdekken waar de performantie van een site kan worden verbeterd. Verder is er de mogelijkheid om: debug informatie uit te printen, nodes uit te printen zodat kan nagegaan worden of alle eigenschappen wel correct zijn ingevuld, etc. De Devel module is een onmisbare module voor ontwerpers, maar kan ook voor administrators een belangrijk hulpmiddel zijn.

•

Figuur 13: Devel block

Schema Deze module controleert of de tabellen in de databank van de site nog steeds overeenstemmen met de tabellen zoals ze gedefinieerd werden in de <module>.install files.

Johnny Rymenans

juni 2010



p 43/96

Indien dit niet meer het geval is, kan dit aan de hand van deze module opgelost worden. Bovendien kan men ook van tabellen die handmatig ingevoerd werden Schema API datastructuren aanmaken. •

Coder Deze module kan nagaan of een (zelfgeschreven) module aan de standaarden voldoet die door de developers van Drupal werden opgesteld. De coding standards kan men terugvinden op http://drupal.org/coding-standards. Gebruikmakend van deze module kan een ontwerper die zijn module ter beschikking wil stellen als contributed module, zijn module checken alvorens ze te uploaden. Buiten de coding standards worden ook een aantal best practices gecheckt. Dankzij deze module kunnen de maintainers van Drupal en de contributed modules efficiënter werken. Het voordeel is dat er nu een zekere uniformiteit is in de code van modules en ook dat een heel aantal vaak voorkomende problemen reeds gevonden worden door de Coder module, zodat de maintainers zich kunnen toeleggen op echte problemen.

•

Features Deze module laat toe om een collectie van features te beheren. De Features module biedt de mogelijkheid om deze features dan te exporteren en te bundelen in een module. Deze module werd gebruikt om alle aangemaakte content types in één module samen te zetten.

•

Advanced help De Advanced help module laat toe om hulpfiles op te slaan buiten de modules, in gewone .html files. Deze hulpfiles kunnen getoond worden in een pop-up of gewoon als een pagina. Het systeem is volledig geïndexeerd en gekoppeld met het zoeksysteem van Drupal, wat toelaat te zoeken op kernwoorden. De Views module heeft een zeer uitgebreide hoeveelheid helpfiles die door middel van deze module kunnen getoond worden. Op zichzelf doet de module niet veel, het is een module die dient ter ondersteuning van andere modules.

6.1.3 Tips voor de keuze van modules Het vinden van de modules die de functionaliteit bevatten die men zoekt is een tijdrovende bezigheid. Er zijn duizenden contributed modules om uit te kiezen. Zeer vaak zijn er tal van modules die gelijkaardige functionaliteit aanbieden. Hoe bepaalt men dan welke module men gaat gebruiken? Johnny Rymenans

juni 2010



p 44/96

Wanneer men uit die lijst een aantal modules heeft gekozen, gaat men naar de projectpagina van die module. Daar staat bij de meeste modules een duidelijke beschrijving van wat de module allemaal aanbiedt. Vaak staat er ook bij van welke modules deze module allemaal afhankelijk is. Soms worden gelijkaardige modules vermeld. Het volgende waar men op moet letten is de versie van Drupal waar de module voor geschreven is. Het is namelijk zo dat modules die voor Drupal5 geschreven zijn, niet compatibel zijn met Drupal6. Er wordt ook aangeraden van de Recommended releases te gebruiken. Vaak zijn er ook development releases beschikbaar, maar deze modules zijn nog niet volledig afgewerkt en hebben bijgevolg een grotere kans dat ze nog bugs bevatten. Indien er een module is die men "absoluut" nodig denkt te hebben, dan kunnen de development versies mogelijks soelaas brengen. Het is in dat geval wel aangeraden van enige kennis van programmeren te hebben om eventueel zelf mogelijke bugs op te lossen, of patches toe te passen wanneer ze worden uitgebracht. Een andere interessante site is http://drupalmodules.com. Op deze site kan men zeer veel modules en hun reviews terugvinden. Deze reviews kunnen helpen bij het bepalen van de kwaliteit van een module.

6.2 Zelfgeschreven modules 6.2.1 Eigen geschreven modules •

inv_finalise_object Een kunstobject -dit is een content type dat een werkelijk kunstobject vertegenwoordigt- kan maar aan de juryleden worden aangeboden wanneer de kunstenaar het object heeft gefinaliseerd. Dit wil zeggen dat de auteur zijn object als afgewerkt beschouwd en geen wijzigingen meer zal aanbrengen. Deze module ontneemt de auteur de rechten om zijn eigen kunstobject aan te passen. Bij het finaliseren van een object verklaart de auteur ook dat hij de exploitatierechten en dergelijke toekent aan Invent Design.

•

inv_finalise_jurering Een jureringsobject -dit is een content type- kan ook gefinaliseerd worden. Wanneer een beoordeling niet meer gewijzigd zal worden, finaliseert het jurylid zijn beoordeling.

Johnny Rymenans

juni 2010



p 45/96

De module ontneemt dan het jurylid de rechten om die beoordeling aan te passen en geeft op die manier aan dat de beoordeling finaal is. De administrator kan hier dan rekening mee houden bij de uiteindelijke beslissing of Invent Design een object wel of niet zal vertegenwoordigen -aanbiedt aan topklanten-. •

inv_categorieen Deze module laat een jurylid toe om gepersonaliseerde categorieën in de databank toe te voegen. Het jurylid kan op die manier kunstobjecten -eigenlijk zijn jurering van een bepaald kunstobject- aan een categorie toevoegen. Wanneer een jurylid al zijn beoordelingen van kunstwerken die tot een bepaalde categorie behoren, wil bekijken, dan kan hij op die categorieën filteren. In de view die gemaakt is, wordt deze filter namelijk exposed zodat de juryleden hem kunnen manipuleren.

•

flexxml_service Deze service wordt aangeroepen door de previewapplicatie. De previewapplicatie toont de foto's van kunstobjecten in een datagrid zodat een topklant ze kan aanduiden om in zijn interieur te tonen. Deze foto's staan opgeslagen op de server van Invent Design. De locatie en andere gegevens van die foto's zijn opgeslagen in de databank. De flexxml_service haalt de benodigde gegevens uit de databank van Drupal en bouwt een geldige XML-file op, deze wordt dan teruggestuurd als antwoord op de aanvraag van de previewapplicatie zodat deze alle gegevens heeft om de foto's te downloaden en te tonen. Op deze manier zal de previewapplicatie altijd de foto's tonen die in de databank staan opgeslagen. Dus als er nieuwe foto's worden opgeslagen, zal de previewapplicatie deze foto's tonen, zonder dat er iets gewijzigd dient te worden aan de applicatie.

•

x_mimemail Deze minimodule zorgt ervoor dat op de Mijn Account pagina de settings van de mimemail module niet meer worden gevraagd/getoond. Aangezien de module nergens de mogelijkheid geeft om te beletten dat die instelling wordt getoond, werd hier een module voor geschreven. Mimemail is eigenlijk een module die door andere modules wordt gebruikt om HTML e-mails te kunnen versturen.

•

x_contact_option Ook een zeer beperkte module die ervoor moet zorgen dat er op de Mijn Account pagina een instelling niet wordt aangeboden aan de gebruikers. Hier is het de Contact module die niet de mogelijkheid bood om dit niet te tonen.

Johnny Rymenans

juni 2010



p 46/96

De Contact module wordt gebruikt om een sitewide contactformulier aan te bieden om de beheerder van de site te bereiken, zonder dat men het e-mailadres moet kennen. Wanneer men deze module -een module die behoort tot Coreaanschakelt, krijgt men er meteen de mogelijkheid bij om gebruikers via zo'n contact formulier met elkaar e-mails te laten uitwisselen, zonder dat men elkaars e-mailadres nodig heeft. Dit is een functionaliteit die Invent Design niet wenst aan te bieden. Deze module is geen contributed module, maar werd gepost op het Drupal forum. Er zat echter nog een fout in: er werd namelijk gebruik gemaakt van een onbestaande key van een array. Deze fout werd dan aangepast en er werd een functie toegevoegd opdat de code correct zou werken.

6.2.2 Modules van geëxporteerde code •

inventdesign_views De Views module heeft een deelmodule die de mogelijkheid biedt om views -dus lijsten of tabellen- die men heeft aangemaakt, te exporteren. De mogelijkheid tot Bulk export werd gebruikt om alle views die werden aangemaakt te exporteren. Deze code werd dan in een module gestopt, zodat door het aanschakelen van deze module, alle views die voor Invent Design werden gedefinieerd worden toegevoegd aan de site en aangeschakeld.

•

invent_features Gebruik makend van de Features module, werden alle content types geëxporteerd naar een features module. Er werd voor gezorgd dat alle dependencies van de content types werden aangegeven. Deze dependencies zijn vooral de "plugin modules" van CCK. Aangezien heel wat verschillende soorten velden gebruikt werden bij de constructie (of definitie) van de verschillende content types was de Features module een zeer waardevol hulpmiddel.

6.2.3 Aangepaste contributed module •

customnodereference_url De Node Reference URL Widget module werd ontdekt tijdens de zoektocht naar een oplossing voor een probleem dat optrad bij het schrijven van een module. De module moest om het mogelijk maken om een Jureringsobject te creëren en deze jurering of beoordeling te verbinden met het kunstwerk waarop ze van toepassing is. Verder mocht er per jurylid maar één beoordeling per kunstobject zijn, dus wanneer een jurylid een object reeds had beoordeeld, dan moest de link naar die beoordeling wijzen.

Johnny Rymenans

juni 2010



p 47/96

De Node Reference URL Widget module bevatte een (groot) deel van de functionaliteit die nodig was en met een paar aanpassingen aan de code voldeed de module aan alle vereisten. De originele module maakt het mogelijk om een referentie te maken naar een node, gebruik makend van informatie -de nid (node id)- die verschaft wordt via de URL. Op die manier was het gedeelte dat de link tussen de twee objecten moest verzorgen reeds beschikbaar. Het enige wat nu nog diende aangepast te worden was de mogelijkheid om de naam van de link aan te passen van Jureer naar Edit Jurering als er reeds een beoordeling was die nog niet gefinaliseerd was. Indien er een beoordeling aanwezig is die wel gefinaliseerd werd, dan zal de link View Jurering tonen.

Johnny Rymenans

juni 2010


Johnny Rymenans


p 48/96

juni 2010



p 49/96

7 Content Types en Views Het belang van Content Construction Kit (CCK) en Views werd al meermaals aangehaald, in dit hoofdstuk wordt dieper ingegaan op het gebruik van CCK en Content Types in deze masterproef. Er werden een aantal content types en views opgesteld voor de site en deze zijn toegespitst op bepaalde rollen. In wat volgt zal worden uitgelegd welke content types en views er worden gebruikt en zelf zijn gedefinieerd, voor welke rollen ze nut hebben en wat hun waarde is voor de site.

7.1 De gedefinieerde content types Elke webpagina -zoals welkomstpagina, veel gestelde vragen, ...- is van het content type Page, dit is één van de meest fundamentele types die dan ook door core wordt aangeleverd. Het biedt de mogelijkheid om een pagina aan te maken met een titel en een body. In deze masterproef wordt dit content type alleen gebruikt door een admin, maar dit kan later uitgebreid worden naar de medewerkers. Bij de beschrijving van de content types zal opvallen dat sommige content types bij meerdere rollen worden vermeld. Het betreft dezelfde content types, alleen hebben ze een andere functionaliteit naar gelang de rol waarin ze worden gebruikt. Zo zal een kunstobject alleen voor een auteur en een admin volledig zichtbaar zijn. Topklanten, juryleden en leveranciers krijgen alleen die velden te zien die voor hen van toepassing zijn. Dit wordt mogelijk gemaakt door de access permissions per veld te definiëren.

7.1.1 Voor Auteurs o

o

Kunstobject: Dit is het content type dat auteurs volledig moeten invullen. Het stelt een abstracte voorstelling voor van het object dat ze willen aanbieden. Het bevat een uitgebreide beschrijving van het object. Juryleden zullen het aangeboden object beoordelen aan de hand van de informatie die verstrekt wordt via dit content type. Uiteindelijk zal een admin een beslissing nemen om het object al dan niet te vertegenwoordigen, waarna het aan topklanten wordt aangeboden. Afgekeurde Objecten: Auteurs komen via dit content type te weten waarom dat kunstobject afgekeurd werd.

Johnny Rymenans

juni 2010



p 50/96

7.1.2 Voor Juryleden o o

Kunstobject: Aan de hand van de gegevens van dit object zullen juryleden een beoordeling aan de admin aanbieden. Gejureerd Object: Het content type dat deze beoordeling voorstelt, is het Gejureerd Object. Dit object bevat gegevens die gebruikt worden door het jurylid om een rangschikking voor zichzelf op te bouwen, de mogelijkheid tot het indelen van een object tot een persoonlijke categorie, het aanbieden van een quotering en uiteraard commentaren, zowel publieke als persoonlijke.

7.1.3 Voor Topklanten o

o

o

o

Bestelling: Via dit content type kan een klant de zaakvoerder op de hoogte stellen van zijn interesse tot het aankopen van een kunstobject. De zaakvoerder zal via dit content type ontdekken welk kunstobject de koper wil, en zal hem dan contacteren voor de verdere afhandeling van de verkoopprocedure. Besteld Object: Wanneer de verkoop een feit is, zal de admin een Besteld Object creëren. Er worden een aantal gegevens ingevoerd zoals; over welk object het gaat, wie de koper is, wie de leverancier is, de aankoopdatum, te leveren datum, ... Bovendien biedt dit object de mogelijkheid voor topklanten om de status van hun aankoop te volgen en leveranciers kunnen de status van dat object updaten. Flextooltje: Dit content type wordt alleen gebruikt om de previewapplicatie aan te kunnen bieden en ervoor te zorgen dat alleen iemand van de rol topklant toegang tot deze flex applicatie heeft. Kunstobject: Het kunstobject dat door een auteur werd ingediend en dat goedgekeurd werd door de admin, kan door een topklant bekeken en aangekocht worden. De topklant krijgt alle voor hem relevante informatie betreffende het object te zien. Gebaseerd op de aangeboden informatie kan de klant besluiten om een aankoop te doen.

7.1.4 Voor Merchandising o

o

Product: Dit content type wordt door ubercart aangeboden. Via dit content type kan men merchandising artikelen aanmaken die in de webshop aan klanten kunnen aangeboden worden. Bevestiging Aankoop: Wanneer een merchandising klant een aankoop toevoegt aan zijn winkelkarretje en besluit om de inhoud van het karretje te kopen, krijgt hij een factuur en een e-mail die hij moet bevestigen. Pas wanneer deze bevestiging gebeurd is, krijgt de koper de rekeninggegevens van de zaakvoerder. Wanneer de zaakvoerder geverifieerd heeft dat de aankoop betaald werd, zal hij de aangekochte artikelen laten bezorgen bij de klant.

Johnny Rymenans

juni 2010



p 51/96

7.1.5 Voor Leveranciers o

o

Besteld Object: Wanneer een admin een Besteld Object heeft aangemaakt, dan kan de leverancier die voor de productie van dat object wordt aangesteld dit specifieke object bekijken. Alleen de velden die voor hem van toepassing zijn, worden ter beschikking gesteld. Het is bij dit object dat hij de status moet updaten. Hij wordt verzocht om periodiek een update te geven door het toevoegen van commentaar. Kunstobject: Een leverancier kan de kunstobjecten waar hij voor instaat bekijken. Hij krijgt dan alle velden te zien die voor hem van toepassing zijn, zoals de beschrijving, afmetingen en dergelijke. Velden die betrekking hebben op prijzen, zoals verkoopprijs, aankoopprijs en dergelijke, ziet een leverancier niet.

7.1.6 Voor Admin o

o

o

o o

Afgekeurde Objecten: Wanneer een admin een kunstobject afkeurt, dient hij zijn beslissing te onderbouwen met een argumentering. Deze opbouwende kritiek dient dan als feedback naar de auteur van het kunstobject. Besteld Object: Wanneer de admin op de hoogte gebracht is van een aankoop door een topklant, zal hij een Besteld Object aanmaken. Het is dit object waar de koper (topklant) de status van zijn aankoop kan blijven volgen. Bij de aanmaak van dit Besteld object wordt er ook een leverancier (of leveranciers) aangesteld, zij hebben ook toegang tot dit welbepaalde Besteld Object. Alleen de gebruiker die het object heeft aangekocht, de aangestelde leverancier(s) en de admin hebben toegang tot die node -met node wordt dat welbepaalde object bedoeld-. Gejureerd Object: De admin heeft het recht om alle jureringen te bekijken. Gebruik makend van de opmerkingen en quoteringen van de juryleden, kan de admin dan een beslissing nemen om een object al dan niet af te keuren. Kunstobject: Een admin kan alles van alle kunstobjecten bekijken en wijzigen. Een admin kan bovendien een object goedkeuren of afkeuren. Page: Aangezien de admin instaat voor het onderhouden van de site, heeft hij de rechten om webpagina's toe te voegen aan de site.

Een admin heeft uiteraard de mogelijkheid om alle content types aan te passen en te bekijken. Ter illustratie wordt het Afgekeurde Objecten content type getoond. Er is doelbewust gekozen voor dit eenvoudige content type. Figuur 14 toont de velden die gebruikt worden voor dit content type, Figuur 15 toont het formulier dat de admin moet invullen wanneer hij een object heeft afgekeurd. In Figuur 16 wordt de full view van het content type getoond.

Johnny Rymenans

juni 2010



p 52/96

Figuur 14: De velden en types van het Afgekeurde Objecten content type

Figuur 15: Afgekeurde Objecten formulier

Figuur 16: Afgekeurde Objecten full view

7.2 De gedefinieerde views Views worden gebruikt om lijstjes en tabellen op te stellen. Men kan via de user interface queries opbouwen zonder zelf SQL te schrijven, de query wordt door views opgebouwd aan de hand van de voorwaarden die de gebruiker stelt. Voor een illustratie verwijzen we naar Figuur 17. Voor deze masterproef werden een aantal views opgesteld voor de verschillende rollen. In wat volgt zullen deze views kort toegelicht worden. Verder is er ook nog een view die door ubercart wordt gebruikt om de producten voor te stellen aan de merchandising klanten. Wanneer de site uitbreidt zullen er ongetwijfeld nog meerdere views opgebouwd moeten worden om de functionaliteit aan de gebruikers aan te bieden die ze nodig hebben. Een view geeft een lijst weer van objecten, maar deze lijst kan verschillen naar gelang de gebruiker die de lijst opvraagt. Deze verschillen kunnen afhangen van de rol, maar in sommige gevallen kan dit zelfs verschillen voor gebruikers binnen dezelfde rol, zoals bv de bestelde_objecten view.

Johnny Rymenans

juni 2010



p 53/96

Figuur 17: Voorbeeld van de view UI

De query die hoort bij de instellingen van bovenstaande figuur is de volgende:

SELECT node.nid AS nid, node.type AS node_type, node.vid AS node_vid, node_data_field_goedgekeurd.field_objectnaam_value AS node_data_field_goedgekeurd_field_objectnaam_value, node_data_field_goedgekeurd.field_beschrijving_object_value AS node_data_field_goedgekeurd_field_beschrijving_object_value, node_data_field_goedgekeurd.field_beschrijving_object_format AS node_data_field_goedgekeurd_field_beschrijving_object_format, node_data_field_deverkoopprijs.field_deverkoopprijs_value AS node_data_field_deverkoopprijs_field_deverkoopprijs_value FROM node node LEFT JOIN content_field_verstuurfoto node_data_field_verstuurfoto ON node.vid = node_data_field_verstuurfoto.vid AND node_data_field_verstuurfoto.delta = 0 INNER JOIN files files_node_data_field_verstuurfoto ON node_data_field_verstuurfoto.field_verstuurfoto_fid = files_node_data_field_verstuurfoto.fid LEFT JOIN content_type_kunstobject node_data_field_goedgekeurd ON node.vid = node_data_field_goedgekeurd.vid LEFT JOIN content_field_deverkoopprijs node_data_field_deverkoopprijs ON node.vid = node_data_field_deverkoopprijs.vid WHERE (node.type in ('kunstobject')) AND ((node_data_field_goedgekeurd.field_goedgekeurd_value) = ('Goedgekeurd')) AND ((node_data_field_goedgekeurd.field_afgewezen_value) != ('Afgewezen')) ORDER BY node_data_field_goedgekeurd_field_objectnaam_value ASC

Johnny Rymenans

juni 2010



p 54/96

7.2.1 Voor Auteurs o

o

o

auteurs_objecten_lijst: Dit is een tabel die alle objecten van de ingelogde gebruiker - de auteur - oplijst. Ze hebben, via een paar exposed filters de mogelijkheid om de resultatenlijst te verfijnen. auteur_objectoordeel_lijst: Via deze view kunnen auteurs bekijken wat de argumentering was voor het afwijzen van hun kunstobject. Dit is een vorm van feedback die wordt aangeboden om de auteur constructieve kritiek aan te bieden. auteurs_objectfoto_grid: Dit is een gallerij van de kunstobjecten van de ingelogde auteur. Het toont een grid van thumbnails van hun kunstobjecten.

7.2.2 Voor Juryleden o

o

jury_quoteringen_lijst: Een lijst van alle beoordelingen die de ingelogde gebruiker - het jurylid - heeft geveld. Dankzij enkele exposed filters kan de lijst verfijnd worden. kunstobjecten_teJureren: Dit is een samengestelde view. De hoofdview geeft een lijst van alle kunstobjecten die gefinaliseerd zijn door de auteur. Wanneer een object gefinaliseerd is, kan het niet meer gewijzigd worden en wordt het automatisch in de lijst getoond. De lijst die aan de hoofdview werd bijgevoegd, is een lijst van hun eigen beoordelingen tot dan toe. Dit kan een jurylid helpen bij de keuze welk object nog te beoordelen, of om een kort idee te vormen over de reeds gevelde oordelen om zo een consequente manier van oordelen te kunnen aanhouden.

7.2.3 Voor Topklanten o o

Catalogus: Deze view toont aan de topklanten alle kunstobjecten die door de admin zijn goedgekeurd, en die dus kunnen gekocht worden. bestelde_objecten: Een topklant krijgt met deze view, al zijn eigen bestelde objecten te zien.

7.2.4 Voor Merchandising o

uc_products: De view voor de merchandising rol zoals die in ubercart wordt gedefinieerd. Deze view van ubercart werd, gebruik makend van de instellingen die worden ter beschikking gesteld, aangepast aan de noden van de webshop van Invent Design.

Johnny Rymenans

juni 2010



p 55/96

7.2.5 Voor Leveranciers o

bestelde_objecten: Een leverancier krijgt met deze view een lijst van alle bestelde objecten te zien waar hij verantwoordelijk voor is

.

7.2.6 Voor Admin o

o

admin_bekijk_jureringen: Deze view biedt een admin de mogelijkheid om alle jureringen van alle juryleden te bekijken. Er werden ook een aantal filters exposed, wat wil zeggen dat de admin de mogelijkheid heeft om de lijst te verfijnen. bestelde_objecten: Een admin krijgt met deze lijst alle bestelde objecten te zien.

7.3 Verduidelijking van de workflow van de site Om de workflow van de site te verduidelijken, zal er per rol een korte beschrijving gegeven worden. Deze beschrijving zal aangeven hoe men een bepaald resultaat bereikt en wat er mag verwacht worden wanneer een bepaalde handeling wordt uitgevoerd.

7.3.1 Vanuit het standpunt van een Auteur

Figuur 18: Tools van een Auteur

Het block Mijn tools bevat vijf tools. Wanneer de auteur kiest voor Voeg kunstobject toe, wordt er een formulier getoond. De auteur wordt verzocht om dit formulier zo volledig en duidelijk mogelijk in te vullen. Het formulier is zo opgesteld dat het duidelijk is wat er van de auteur verlangd wordt, er zijn slechts een paar verplichte velden. De verplichte velden worden aangeduid met een sterretje '*'. Wanneer een verplicht veld niet wordt ingevuld, zal er een foutmelding getoond worden.

Wanneer hij het object bewaart, kan hij het nog steeds aanvullen of wijzigen. Het is pas vanaf de moment dat de auteur het object finalised, dat het aan de juryleden wordt aangeboden. Met het finaliseren gaat de auteur ook akkoord met de (juridische) voorwaarden die hij moet goedkeuren wanneer hij wil dat het object door Invent Design wordt vertegenwoordigd. Het finaliseren gebeurt door op de finaliseer link te klikken onderaan het getoonde kunstobject.

Johnny Rymenans

juni 2010



p 56/96

Wanneer een object gefinaliseerd is, worden de (schrijf)rechten van de auteur voor dat kunstobject onttrokken, zodat hij het niet meer kan wijzigen tijdens de jurering, of wanneer het object aan topklanten wordt aangeboden. De auteur merkt dit omdat hij geen edit tab meer heeft bij dat object. De drie volgende tools zijn straight forward. Wanneer de auteur op Jouw kunstobjecten klikt, krijgt hij een grid te zien met de eerste thumbnail van elk van zijn kunstwerken, kiest hij voor Jouw objectenlijst, dan krijgt hij een tabel te zien van al zijn objecten. De auteur krijgt dan per object een paar velden te zien zoals een thumbnail, de naam van het kunstwerk, of het al of niet gefinaliseerd is, een korte beschrijving, of het object al of niet afgewezen is en een link naar de full view van het object. Wanneer hij kiest voor Beoordelingslijst, krijgt de auteur een tabel met de kunstwerken die werden afgekeurd. Hij kan er dan de argumentering van bekijken.

7.3.2 Vanuit het standpunt van een Jurylid Voor de rol van jurylid zijn er drie tools ter beschikking: Te beoordelen lijst, Voeg categorie toe en Jouw beoordelingslijst. Wanneer een auteur zijn object finaliseert,wordt dit kunstobject automatisch getoond in de lijst van de te beoordelen kunstobjecten. De juryleden krijgen via de Te beoordelen lijst een tabel te zien die alle gefinaliseerde objecten toont die nog niet zijn afgekeurd, Figuur 19: Tools van een Jurylid noch goedgekeurd. Deze view toont een thumbnail, objectnaam en een beschrijving van het kunstobject. Wanneer het jurylid op de objectnaam klikt, krijgt hij een full view van het kunstobject te zien, althans die velden die voor een jurylid van belang zijn. Wanneer het jurylid de full view van het kunstobject ziet, kan hij op de link Jureer klikken om een Gejureerd Object aan te maken. Bij de beoordeling van een kunstobject, dus wanneer het jurylid een Gejureerd Object creëert of aanpast, kan hij dit kunstobject in een gepersonaliseerde Categorie indelen. Zo'n categorieën aanmaken doet hij via de Voeg categorie toe link. Het jurylid krijgt het formulier vanuit Figuur 6, op pagina 23, te zien. Nadat hij een categorie toegevoegd heeft, kan hij dat kiezen uit de dropdownlist wanneer hij een Gejureerd Object aanpast of creëert. De derde tool dat een jurylid kan hanteren is het opvragen van een lijst van al zijn beoordelingen. De tabel toont het rangnummer, de thumbnail, de naam van het beoordeelde object, de score die het jurylid eraan heeft gegeven, of het object wel of niet gefinaliseerd is en een link om de beoordeling te bekijken. In de view worden ook mogelijkheden geboden om de zoekresultaten van de tabel te verfijnen.

Johnny Rymenans

juni 2010



p 57/96

7.3.3 Vanuit het standpunt van een Topklant

Figuur 20: Tools van een Topklant

Een topklant heeft drie tools. Hij heeft de Catalogus view, de Lijst van bestellingen view en hij kan de previewapplicatie gebruiken. De Catalogus laat de klant toe om een kunstobject te kiezen. De getoonde tabel geeft een thumbnail die vergroot kan worden wanneer men deze aanklikt. Daarnaast is er ook een kolom met de objectnaam. Indien men op deze objectnaam klikt, wordt de full view van het kunstobject getoond. Verder krijgt de topklant in deze view nog de verkoopprijs te zien en een link om het object te bestellen.

Wanneer hij besluit om een bestelling te plaatsen, wordt de klant omgeleid naar de pagina met de bestelinformatie. Deze pagina zal de procedure die door Invent Design wordt gehanteerd, uitleggen. De Topklant heeft nu de mogelijkheid om een aanvraag te doen. Dit gebeurt door het invullen van een kort formulier. Wanneer dit formulier ingevuld is, wordt de zaakvoerder via e-mail op de hoogte gesteld en kan hij de topklant contacteren om het verdere verloop van de verkoop persoonlijk af te handelen. Wanneer de verkoop afgerond is, maakt de admin een Besteld Object aan. Via de Lijst van bestellingen kan de topklant de status van zijn aankoop volgen. De leverancier die aangesteld is om het product te produceren verbindt zich ertoe om op regelmatige tijdstippen de status van de bestelling te updaten. Hij plaatst hiertoe een commentaar bij het Bestelde Object. De klant kan ook commentaar toevoegen, waarop de leverancier kan reageren. Deze interactie draagt bij tot de betrokkenheid van de partijen, het is transparant en zal bijgevolg het vertrouwen van de topklant in Invent Design versterken. Tenslotte heeft de topklant, als enige rol behalve uiteraard de admin, de mogelijkheid om de previewapplicatie te gebruiken. Voor meer uitleg betreffende deze aangeboden dienst, wordt verwezen naar hoofdstuk 9.

7.3.4 Vanuit het standpunt van een Merchandiser Een merchandiser heeft geen tools tot zijn beschikking, maar hij heeft wel de mogelijkheid om een Catalog te bekijken. Deze view bevat de catalogus van de merchandising die via de webshop wordt verkocht. Wanneer een merchandiser een artikel aan zijn winkelkarretje toevoegt, krijgt hij de mogelijkheid om verder te surfen of om zijn bestelling te vervolledigen. Figuur 21: Merchandiser Catalog

Johnny Rymenans

Kiest hij voor het afwerken van zijn bestelling, dan wordt hem een samenvatting van de factuur getoond. Gaat hij akkoord, dan krijgt hij via e-mail een factuur opgestuurd.

juni 2010



p 58/96

De koper krijgt ook een e-mail toegestuurd die een link bevat die hij moet bevestigen. Pas wanneer de aankoop wordt bevestigd, wordt de zaakvoerder op de hoogte gesteld dat er een aankoop wordt gedaan en krijgt de koper de betaalgegevens van de zaakvoerder doorgestuurd. Wanneer de zaakvoerder heeft geverifieerd dat hij betaald is, wordt het product opgestuurd naar de klant.

7.3.5 Vanuit het standpunt van een Leverancier Een leverancier heeft slechts één tool nodig. Deze tool is een lijst van de bestellingen waar hij voor verantwoordelijk is.

Figuur 22: Leverancier tools

Wanneer hij dan de status van één van die objecten wil wijzigen, kiest hij dat object uit de lijst en voegt hij een commentaar toe. De commentaar bevat dan een tekstuele uitleg van de vorderingen in verband met de productie van dat kunstobject. Indien de koper een vraag stelt, kan hij hier op antwoorden.

7.3.6 Vanuit het standpunt van een Admin Hier zouden we zeer kort in kunnen zijn. Een admin kan "Alles" bekijken en aanpassen indien nodig. De admin kan via de Jureringen alle beoordelingen van de juryleden bekijken. Vervolgens kan de admin een kunstobject goedkeuren of afkeuren. Wanneer een kunstobject wordt goedgekeurd wordt het direct zichtbaar in de Catalogus voor topklanten. Wanneer hij een kunstobject echter afkeurt, wordt het kunstobject unpublished. Wanneer een stuk content unpublished wordt, dan is het alleen nog zichtbaar voor de eigenaar van het stuk content, de auteur van dat kunstobject, en voor een admin. Wanneer een admin het kunstwerk afkeurt, wordt hij omgeleid naar een formulier waar hij de reden op kan geven waarom Invent Design het kunstobject niet zal vertegenwoordigen. De auteur wordt Figuur 23: Admin tools

Johnny Rymenans

automatisch via e-mail op de hoogte gebracht dat zijn kunstobject niet wordt vertegenwoordigd. Hij kan de beslissing bekijken via zijn Beoordelingslijst.

juni 2010



p 59/96

Zoals reeds vermeld, zal de admin een Besteld Object aanmaken wanneer er een kunstobject werd verkocht. Daarnaast kan de admin ook artikelen toevoegen aan de webshop via de Voeg product toe link. Uiteindelijk kan de admin ook webpagina's toevoegen aan de site, de content van de site managen, gebruikers toevoegen en managen, ... kortom alles wat hij moet kunnen om de ganse site -het ganse bedrijf - te beheren.

7.4 Acties en Triggers bevorderen Workflow In bovenstaande tekst werd er meermaals verwezen naar gebeurtenissen die optreden wanneer er aan bepaalde voorwaarden wordt voldaan. Zo worden gebruikers soms automatisch via een e-mail op de hoogte gebracht van een gebeurtenis. Wanneer een admin een voorwerp afkeurt - dit doet hij door een checkbox aan te vinken- krijgt de auteur automatisch een e-mail toegestuurd. Wanneer een topklant een aanvraag doet om een kunstobject te bestellen, wordt de admin op de hoogte gebracht. Al deze automatische acties worden uitgevoerd ten gevolgen van een bepaalde gebeurtenis. Hiervoor zorgen de Rules en de Workflow module. Ter illustratie worden twee voorbeelden aangegeven: o

o

Wanneer een admin een object afkeurt, wordt er een e-mail gestuurd, maar bovendien wordt er ook nog extra PHP code uitgevoerd om het object unpublished te maken, om een aantal voorwaarden waaraan moet voldaan zijn na te gaan en bovendien wordt er ook nog een Afgekeurd Object aangemaakt en dergelijke meer. Wanneer een topklant een aanvraag doet om een object te bestellen, wordt niet alleen de admin op de hoogte gesteld, maar wordt er door extra PHP code eerst een node programmatorisch aangemaakt waarbij alle nodige eigenschappen worden ingesteld.

Johnny Rymenans

juni 2010


Johnny Rymenans


p 60/96

juni 2010



p 61/96

8 Een korte vergelijking tussen Joomla! en Drupal In dit hoofdstuk wordt er een korte vergelijking gemaakt tussen twee zeer populaire open source Content Management Systemen. Er zal zeer kort ingegaan worden op het objectgeoriënteerde framework van Joomla!. Daarnaast wordt er kort ingegaan op de redenen voor de beslissing van Drupal om niet objectgeoriënteerd te werken.

8.1 Joomla! Aangezien de tijd voor een diepgaand onderzoek te beperkt was, wordt hier slechts een beperkt overzicht gegeven van dit CMS. Voor de vergelijking werd Joomla 1.5.18 geïnstalleerd. De functionaliteit die Joomla out of the box aanbiedt werd getest. Daarna werd nagegaan wat de meest voorkomende voordelen zijn die gebruikers van Joomla aanhalen. De voordelen die overeenkwamen met de eigen indruk worden kort toegelicht.

8.1.1 Het Framework Om de vergelijking met Drupal - dat in hoofdstuk 3 reeds uitgebreid aan bod kwam- te kunnen kaderen, wordt er eerst een korte beschrijving gegeven van het framework van Joomla!. De informatie is gebaseerd op de documentatie die men kan raadplegen op http://docs.joomla.org/Framework.

Figuur 24: De Joomla architectuur Johnny Rymenans

juni 2010



p 62/96

Zoals in Figuur 24 duidelijk wordt aangegeven, wordt Joomla! 1.5 opgebouwd als een drie lagen systeem. •

•

•

De Extension layer: Bevat de uitbreidingen van het framework en de toepassingen. o Modules: Flexibele lichtgewicht uitbreidingen die gebruikt worden voor de opbouw van een pagina. o Components: Een uitbreiding. Componenten verschillen van andere uitbreidingen, zoals Modules en Plugins, omdat ze aanzienlijke hoeveelheden data kunnen opslaan in de databank van Joomla!. Die gegevens kunnen bijvoorbeeld de content van een pagina zijn, de manier waarop die content moet weergegeven worden, ... o Templates: Dit type van uitbreidingen wordt gebruikt om het uitzicht van een site te veranderen. Er zijn twee types van templates, namelijk: frontend templates: Worden gebruikt voor de gebruikers van de site. backend templates: Worden gebruikt voor de interface van de administrator De Application layer o Deze laag bevat toepassingen die de JApplication klasse van het framework uitbreiden. Momenteel worden er vier applicaties aangeboden in de Joomla! distributie. JInstallation: De toepassing die Joomla! installeert op de webserver. JAdministrator: De backend van Joomla! JSite: Frontend van Joomla! XML-RPC: Ondersteund remote administratie van de website. De Framework layer o Het framework bevat een aantal verschillende packages. Deze packages bevatten de basis classes waaruit het framework is opgebouwd. o De libraries zijn de bibliotheken die nodig zijn voor het framework en die kunnen gebruikt worden door schrijvers van third-party developers bij de ontwikkeling van uitbreidingen. o De plugins breiden de functionaliteit van het framework uit.

Het Joomla! framework is opgebouwd, gebruik makend van object oriented design patterns. Deze strategie zorgt ervoor dat de Joomla! core makkelijk uitbreidbaar is en tevens goed te onderhouden. Bovendien zorgt deze werkwijze ervoor dat third party developers kunnen gebruik maken van de rijke en makkelijk toegankelijke functionaliteiten die het framework hen biedt.

Johnny Rymenans

juni 2010



p 63/96

8.1.2 Voordelen van Joomla! Een aantal van de voordelen die vaak aangehaald worden ter verdediging van Joomla! en die overeenkomen met de eigen indrukken, zijn de volgende: o

o

o

o

o

De distributie komt gebundeld met een makkelijke installer. De installatieprocedure is zo makkelijk dat, aan de hand van de uitleg die geboden wordt, in principe zowat iedereen er in zal slagen om deze tot een goed einde te brengen. Er is een duidelijk verschil tussen de Frontend en de Backend. Deze twee zijn duidelijk van elkaar gescheiden. Bovendien is de Backend - het gedeelte voor de administrator - gebruiksvriendelijker opgebouwd dan in Drupal het geval is. Er is standaard een duidelijke WYSIWYG editor aanwezig, die toelaat voor gebruikers om makkelijk teksten, foto's, multimediabestanden toe te voegen aan hun content. Er is een makkelijkere leercurve om het CMS te gebruiken. Dit betekent dat er een grotere groep van gebruikers het CMS zal kunnen gebruiken, ook al hebben ze geen programmeerachtergrond. Er zijn zeer veel templates (gratis) ter beschikking om een mooi ogende site te produceren.

8.1.3 Nadelen van Joomla! Een aantal van de nadelen die vaak aangehaald worden wanneer men Joomla! vergelijkt met Drupal zijn de volgende: o

o o

o

De mogelijkheden tot het bepalen van de toegang. Er zijn namelijk slechts drie gebruikers groepen standaard. Dit beperkt de mogelijkheden aanzienlijk, ten opzichte van Drupal. Er wordt standaard geen multisite mogelijkheid, de mogelijkheid om meerdere sites op te zetten die van dezelfde Drupal installatie gebruik maken, aangeboden. Er zijn wel enorm veel uitbreidingen, maar die werken niet noodzakelijk allemaal samen. Er zijn vaker compatibiliteitsproblemen. Verder kunnen modules soms aanpassingen doen die ervoor zorgen dat zelfs na het verwijderen van de module, niet alle wijzigingen ongedaan gemaakt kunnen worden. Standaard zijn er minder mogelijkheden in verband met categorieën. Zo zijn er slechts twee niveaus namelijk sections en categories. Een stuk content kan behoren tot slechts één categorie. Een section kan meerdere categorieën bevatten en een categorie kan meerdere stukken content bevatten.

Bij Joomla! zijn er ontzaglijk veel modules. Voor elk probleem zijn er een veelheid van modules die deze functionaliteit aanbieden. Om de kwaliteit van een module te kunnen inschatten moet men vertrouwen op een soort van review en rating systeem.

Johnny Rymenans

juni 2010



p 64/96

8.2 Drupal Voor een uitgebreide uiteenzetting over de opbouw van Drupal wordt verwezen naar hoofdstuk 3. In wat volgt wordt er meer ingegaan vanuit een object georiënteerde invalshoek. Drupal krijgt regelmatig kritiek op het feit dat het niet object georiënteerd is, waardoor de leercurve steiler wordt omdat de werking van Drupal niet direct duidelijk is. Jonathan Chaffer, een Drupal Core Developer, heeft een uitgebreide tekst geschreven hierover. In wat volgt wordt hier kort op ingegaan. De tekst is te vinden op http://drupal.org/node/547518. De beslissing die gemaakt werd om Drupal niet objectgeoriënteerd te maken, heeft meerdere redenen. Eén van de redenen is een historische. Drupal is geschreven in PHP4. PHP4 had amper ondersteuning voor objectgeoriënteerde constructies. Deze zijn pas verder uitgewerkt vanaf PHP5. In Drupal heeft men een aantal Object Oriented Programming (OOP) aspecten die PHP nog niet ondersteunde geïmplementeerd. In Drupal 7 zijn er een aantal modules die het PHP klassen systeem gebruiken, hoewel de core structuur van Drupal nog niet aangepast is, wordt er wel steeds meer richting objectgeoriënteerde werkwijze geëvolueerd.

8.2.1 Objectgeoriënteerde concepten in Drupal In wat volgt wordt een korte toelichting gegeven bij een aantal objectgeoriënteerde concepten en hoe ze in Drupal werden uitgewerkt. o

o

o

o

o

Objects: Nodes kunnen gezien worden als objecten. De methoden die erop kunnen toegepast worden, zijn gedefinieerd in de node.module. De datastructuur wordt echter niet in een class gedefinieerd, maar in de databank. Abstraction: Het hooks systeem is de basis voor Drupal's interface abstraction. De oproepende methode hoeft niets te weten over de module die de hook implementeert om nuttig werk te verrichten. Encapsulation: Drupal is afhankelijk van afspraken om encapsulation te verzorgen. In Drupal wordt er afgesproken dat alle functies, die een enkele namespace delen, prefixen gebruiken. Private functies worden voorafgegaan door een underscore "". Polymorphism: Nodes zijn polymorfisch in de klassieke zin. Men kan een node zien als een object waar andere types van zijn afgeleid. Het eigenlijke resultaat van de afhandeling hangt dan af van het type node dat aan de functie wordt doorgegeven. Inheritance: Modules hebben een selectie van alle mogelijke hooks in Drupal. De modules overschrijven en implementeren dan enkel die hooks die nodig zijn.

Johnny Rymenans

juni 2010



p 65/96

8.2.2 Design Patterns in Drupal Drupal bevat een heel aantal van de Design Patterns die door de Gang of Four werden verzameld. o

o

o

o

o

Decorator: Er zijn een aantal node hooks -hook_node_load(), hook_node_view(), etc- die ervoor zorgen dat een gewone module het gedrag van alle nodes kan uitbreiden. Het is mogelijk om een veelheid aan gedragingen toe te voegen aan nodes zonder dat men nieuwe afgeleide klassen moet aanmaken. Drupal heeft dit geïmplementeerd met het hook system en node_invoke(). Observer: Er bestaat een Taxonomy module, deze heeft een hook_taxonomy_vocabulary_update(). Elke module die deze hook implementeert, registreert zich als observer van het vocabulary object. Bridge: De database abstraction layer is gebaseerd op het Bridge patroon. De modules worden geschreven, onafhankelijk van de keuze van de databank. Een databanklaag wordt dan geschreven conform de API die gedefinieerd is door de Bridge. Chain of responsibility: Het menu system volgt dit patroon. Wanneer er een pagina wordt aanvraagd, wordt er gekeken of er een module is die de aanvraag behandelt. Als een menu item het request niet kan behandelen wordt het hoger in de chain gegooid, tot er een module gevonden wordt die de aanvraag afhandelt, die de toegang verbiedt of tot de chain ten einde is. Command: Het hooks system gebruikt dit patroon zodat modules niet elke hook moeten definieren.

8.2.3 Voordelen van Drupal o o

o

o

Drupal is zéér flexibel, uitbreidbaar en schaalbaar. Dit is dan ook de reden dat vele grotere bedrijven kiezen voor dit CMS. Er is een grote controle over de aangeboden code. Core en de contributed modules worden door een groep van bekwame maintainers onderhouden. Er wordt toezicht gehouden op de veiligheid van modules en er wordt op gelet dat de coding standards worden nageleefd om de uniformiteit te behouden. Er wordt zeer veel aandacht besteed aan de APIs. Dit zorgt er ook voor dat er minder compatibiliteitsproblemen zijn tussen modules. Er komt wel een nadeel bij kijken, namelijk dat er geen backwards compatibiliteit word aangeboden tussen verschillende versies (vb Drupal5 ten opzichte van Drupal6). Doordat er voor belangrijke contributed modules steeds gekeken wordt hoe die nuttig en generisch genoeg kunnen gemaakt worden voor de ganse community, zijn er misschien wel minder contributed modules beschikbaar dan bij Joomla!, maar dit komt de kwaliteit van de code ten goede aangezien er minder vaak goede programmeurs aan parallelle, gelijkaardige projecten werken.

Johnny Rymenans

juni 2010



p 66/96

8.2.4 Nadelen van Drupal Een aantal van de nadelen van Drupal die men vaak hoort wanneer men CMS'en vergelijkt zijn: o o

o

De leercurve van Drupal is (te) steil: Vooral voor de niet-developers is dit een reden die vaak de doorslag geeft. Drupal wordt als niet gebruiksvriendelijk genoeg gezien. Men vermeldt er dan ook vaak bij dat Drupal eerder voor en door developers wordt geschreven. Designers en niet-developers die een site willen opzetten raken dan ook vaak overweldigd door de mogelijkheden en de niet altijd even intuïtieve terminologie. Er is standaard geen WYSIWYG editor aanwezig. Hoewel Drupal het ondersteunt, en via contributed modules een uitgebreid aanbod biedt, wordt het als een struikelblok gezien dat deze functionaliteit er niet out-of-the-box inzit. Gebrek aan een eenvoudige manier om foto's en andere mediaformaten makkelijk in de content te plaatsen. Er zijn een zeer grote hoeveelheid oplossingen hiervoor te vinden onder de contributed modules, maar vaak dient men meerdere modules te activeren hiervoor. Zo is er geen out-of-the-box gallery. Zo'n gallery opbouwen gaat perfect, al dient men hier een paar modules voor te combineren. De frontend en de backend zijn niet gescheiden. Dit zorgt bij velen voor verwarring. Het gebrek aan professionele themes. Er wordt Drupal sites vaak verweten dat ze teveel op elkaar lijken. Er zijn dan ook veel minder themes beschikbaar voor Drupal dan voor Joomla!. Drupal sites die niet Drupalish lijken zijn vaak op maat gemaakt van een welbepaalde klant, waardoor het niet nuttig is ze gratis aan de community aan te bieden.

8.3 Vergelijking Aangezien de tijd voor een eigen diepgaand onderzoek naar deze twee Content Management Systemen ontbrak, wil ik verwijzen naar een uitgebreide vergelijking die terug te vinden is in Appendix C: Figuur 29, Figuur 30 en Figuur 31. Deze vergelijking kan teruggevonden worden op http://www.alledia.com/blog/general-cms-issues/joomlaand-drupal-version-2/

8.4 Conclusie De versies die hier werden gebruikt in de vergelijking zijn Joomla! 1.5 en Drupal 6. Beide systemen zullen binnenkort een volgende versie publiceren. Drupal heeft op het moment van dit schrijven net Drupal 7.0-alpha4 voor testdoeleinden uitgebracht, Joomla! bracht Joomla! 1.6 Beta 2 uit. Het lijkt erop dat beide systemen werken aan een aantal

Johnny Rymenans

juni 2010



p 67/96

belangrijke features waarin de concurrent sterker staat. Zo werkt Drupal aan het verbeteren van de gebruiksvriendelijkheid voor gebruikers, terwijl Joomla! duidelijk werk maakt van een uitgebreider Access Control System. Beide Content Management Systemen zijn zeer goed en voldoen aan zowat alle vereisten waaraan een CMS moet voldoen. Wanneer de site niet zo complex is en betrekkelijk snel moet ontwikkelt worden, geniet Joomla! wellicht de voorkeur. Indien men echter een zeer uitbreidbaar systeem nodig heeft dat zeer schaalbaar moet zijn, dan kan men misschien eerder denken aan Drupal.

Johnny Rymenans

juni 2010


Johnny Rymenans


p 68/96

juni 2010



p 69/96

9 De previewapplicatie 9.1 Doelstelling Invent Design wil aan de topklanten als dienst een preview aanbieden. Deze dienst houdt in dat men, gebruik makend van de previewapplicatie, een foto van zijn interieur kan laden waarin men een kunstobject kan plaatsen. Op deze manier kan de koper er zich een beter beeld van vormen of een kunstobject al dan niet in zijn interieur past. De klant krijgt een aantal mogelijkheden om het object te bewerken en zal uiteindelijk ook de kans krijgen om de samengestelde foto, eventueel tegen betaling, zelf af te drukken. Een belangrijke voorwaarde waaraan de applicatie moet voldoen is dat het op een internetbrowser moet werken en bovendien voor de gebruiker zeer makkelijk in gebruik is. Zo is een intuïtieve gebruikersinterface (GUI) van groot belang. Het resultaat is een werkend proof of concept.

9.2 Onderzoek De eerste taak was nagaan of er reeds een applicatie bestaat die de functionaliteit aanbiedt die de zaakvoerder voor ogen heeft, met als extra voorwaarde dat het vanuit een internetbrowser moet werken. Na uitgebreid zoekwerk op het Internet werden er geen applicaties gevonden. Er werden tal van programma's gevonden die u toelaten om een interieur te ontwerpen, maar onze zoektocht heeft geen resultaat opgeleverd dat aan onze eisen voldeed. De volgende stap was het zoeken naar een technologie om zelf een applicatie te implementeren die wel aan de vooropgestelde eisen voldoet. Het moest een technologie zijn die het mogelijk maakt om een grafische user interface (GUI) op te bouwen die kan ingebed worden in een website. Uiteindelijk is de keuze gevallen op Adobe Flex, een gratis opensource framework. Met Adobe Flex is het mogelijk om Rich Internet Applications (RIA's) te bouwen. Een RIA is een interactieve internetapplicatie die voor de gebruiker lijkt op een desktopprogramma, alleen draait het in een internetbrowser. Het voordeel van zo'n RIA is dat het platform onafhankelijk is. De gegevens van de kunstobjecten zitten in de database van Drupal. Dit betekent dat de previewapplicatie zal moeten communiceren met het content management system. Dankzij de Services module, ondersteund door AMFPHP, wordt dit mogelijk gemaakt.

Johnny Rymenans

juni 2010



p 70/96

9.3 Het prototype In het proof of concept werd de nadruk gelegd op het opbouwen van een werkend prototype. Er is gekozen voor het schrijven van een prototype met beperkte functionaliteit, ten voordele van de robuustheid. In het prototype is het mogelijk om een foto te laden van het interieur. Dit doet men door met de muis op de default foto te klikken waarna een vertrouwde filebrowser opent en men de foto van zijn interieur kan laden. Deze foto -die op de harde schijf of andere lokale plaats staat opgeslagen- zal dan getoond worden in plaats van de default foto. Hierna kiest men een object, waarna men een lijst van thumbnails te zien krijgt van dat object. Wanneer men één van de thumbnails aanduidt, wordt hij getoond in het interieur. De gebruiker heeft ook de mogelijkheid om via de "Vorige" en "Volgende" knoppen door de objecten te bladeren. De knop "Screen Shot" neemt een momentopname van de huidige samenstelling.

Figuur 25: Screenshot van de previewapplicatie Voor het prototype werd gekozen om slechts één object in het interieur te tonen. Dit object wordt in het centrum van de foto geplaatst, dus de gebruiker dient ervoor te zorgen dat de foto van zijn interieur als centrum de plaats heeft waar het object zal moeten getoond worden. Deze beperkingen zullen uiteraard weggewerkt worden in de uiteindelijke applicatie. Johnny Rymenans

juni 2010



p 71/96

9.4 Implementatie De applicatie bestaat uit twee delen: • •

Een RIA die aan de gebruiker wordt aangeboden. Een service die door Drupal wordt aangeboden aan de RIA.

De RIA is geschreven in Flex, de service in php. De RIA wordt opgebouwd in drie bestanden, namelijk: Invent_Design.mxml, Invent_Design.as en services-config.xml. Het bestand Invent_Design.mxml is een op XML gebaseerd bestand dat de code bevat voor de opbouw van de lay-out. Dit MXML bestand kan ook scripts bevatten, maar wanneer er complexere programmalogica wordt geschreven, is het aangewezen om deze te schrijven in een apart AS bestand. De client logic wordt geschreven in de objectgeoriënteerde programmeertaal ActionScript 3.0. Het services-config.xml bestand bevat de configuratie gegevens, doorgaans zijn dit beveiligingsdefinities, channel definities en de instellingen met betrekking tot logfunctionaliteit die een service kan gebruiken. Ter illustratie van de inhoud en opbouw van deze bestanden worden een aantal extracten kort toegelicht.

9.4.1 Invent_Design.mxml In het volgende extract wordt geillustreerd hoe een deel van de GUI van de RIA wordt opgebouwd.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" applicationComplete="init();" width="792" height="593"> <mx:Script source="Invent_Design.as" />

De volledige lay-out van de applicatie bevindt zich tussen de <mx:Application> en tags. In deze applicatie wordt de lay-out op absolute manier gepositioneerd. Wanneer applicatie geladen is zal de init() functie opgeroepen worden. In de init() functie wordt er een xml-file geladen die door Drupal wordt opgebouwd.

Er wordt ook aangegeven dat de programmalogica zich in een extern bestand bevindt, namelijk Invent_Design.as.

<mx:RemoteObject showBusyCursor="true" destination="amfphp" source="flexxml" id="my_xml"> <mx:method name="xml" result="onXmlResult(event)" fault="onFault(event)" /> <mx:RemoteObject showBusyCursor="true" destination="amfphp" source="system" id="system"> <mx:method name="connect" result="onSystemConnect(event)" fault="onFault(event)" />

Johnny Rymenans

juni 2010



p 72/96

Hier worden twee services opgeroepen, een zelfgeschreven flexxml-service en een system-service. Via de system-service wordt de gebruiker - de topklant dewelke is ingelogd op de site - en een sessionID bekomen. Deze gegevens zijn nodig om de flexxml-service aan te roepen.

<mx:Panel id="titelPaneel" x="5" y="5" width="780" height="90" layout="absolute"> <mx:Image x="71" y="0" width="87" height="45" source="asset/logo.png" scaleContent="true" autoLoad="true"/> <mx:Label id="titel" text="Invent Design - Montage-tool" height="45" fontSize="21" textAlign="center" width="655" x="95" y="0"/>

Er wordt een paneel opgebouwd met het logo van Invent Design en de titel van de applicatie. Dit logo is een afbeelding die in de applicatie is gecompileerd. In het volgende fragment wordt het paneel opgebouwd dat de gebruiker in staat stelt een object te kiezen. De ComboBox en de DataGrid worden opgevuld met gegevens uit de xml-file. De DataGrid is één van de meer complexe lay-out onderdelen en toont de thumbnails van het gekozen object met behulp van een itemRenderer. De DataGrid heeft de mogelijkheid om grote hoeveelheden data te tonen, maar standaard wordt deze data weergegeven als eenvoudige tekst. Door het gebruik van itemRenderers krijgt men de mogelijkheid om deze inhoud aan te passen. De itemRenderer werd gebruikt om thumbnails aan de gebruiker aan te bieden in plaats van tekst. De thumbnails die getoond worden, worden van de Drupalsite gedownload.

<mx:Panel id="keuzePaneel" x="5" y="103" width="227" height="482" layout="absolute" title="Kies uw object"> <mx:ComboBox id="keuzeCombo" x="10" y="10" width="119" change="disableButton();"> <mx:Button x="137" y="10" id="kies" label="Kies" click="kiesObject();"/> <mx:DataGrid x="10" y="40" width="192" height="378" id="objectGrid" click="zetObjectImage();" > <mx:columns> <mx:DataGridColumn headerText="Preview" dataField="img" sortable="false"> <mx:itemRenderer> <mx:Component> <mx:VBox verticalScrollPolicy="off" horizontalScrollPolicy="off"> <mx:Image source="{data.img}" width="100%" height="100" horizontalAlign="center"/> <mx:Label text="{data.des}" textAlign="center"/>

Wanneer er op een thumbnail wordt geklikt, wordt de zetObjectImage() functie aangeroepen die ervoor zorgt dat de gekozen afbeelding in het interieur wordt geplaatst.

Johnny Rymenans

juni 2010



p 73/96

9.4.2 Invent_Design.as In dit (zéér verkort) fragment van de Invent_Design.as file wordt geïllustreerd hoe men in de objectgeoriënteerde programmeertaal ActionScript3.0 bibliotheken importeert, hoe men constanten en variabelen declareert en hoe een functie kan geschreven worden.

import mx.controls.Alert; import mx.graphics.codec.JPEGEncoder; import mx.rpc.events.FaultEvent; import mx.rpc.events.ResultEvent; private static const OBJ_WIDTH:uint = 200; private static const OBJ_HEIGHT:uint = 200;

Een variabele wordt gedeclareerd met een access specifier (public, private, protected), het keyword var, een naam en het type van deze variabele wordt aangegeven na een ":". De metatag [bindable] bij de variabele theXMLFile zorgt ervoor dat er achter de schermen code wordt uitgevoerd door Flex die nodig is opdat het data object gebonden kan worden wanneer het verandert.

private var fileRefList:FileReference; [Bindable] private var theXMLFile:XMLList;

Een functie wordt gedeclareerd met een access specifier (public, private, protected), het keyword function, een functienaam, eventueel gevolgd door een aantal argumenten, gevolgd door een ":" waarna de teruggeefwaarde wordt aangegeven. De system-service bevat een functie: connect. Deze functie wordt in de onSystemConnect functie aangeroepen. De sessionID die door de connect functie wordt teruggezonden, wordt samen met de gegevens die door de hashKey functie worden berekend, gebruikt om de xml functie van de flexxml-service aan te roepen. De berekende gegevens en de sessionID zijn nodig om de aanvraag te kunnen authenticeren. De xml functie bouwt op haar beurt een geldige xml-file met gegevens uit de databank van Drupal. De bekomen xml-file wordt gebruikt om de componenten van de RIA op te vullen.

public function onSystemConnect(event:ResultEvent):void { sessionID = event.result.sessid; currentUser = event.result.user.name; var hashedArray:Array = hashKey("flexxml.xml"); my_xml.xml(hashedArray[0], hashedArray[1], hashedArray[2], hashedArray[3], sessionID); }

Johnny Rymenans

juni 2010



p 74/96

De hashKey functie berekent een Hash en geeft een Array terug. Er zijn twee manieren om een Array te creëren: • •

via de constructorfunctie: var array:Array = new Array(); via de literal notation [].

In dit geval wordt de tweede methode gebruikt om de Array terug te geven.

public function hashKey(serviceMethod:String):Array { var captureTime:String = (Math.round((new Date().getTime())/1000)).toString(); var captureRandom:String = randomString(10); var hashString:String = captureTime + ";"; hashString += apiDomain + ";"; hashString += captureRandom +";"; hashString += serviceMethod; return [HMAC.hash(apiKey,hashString,SHA256),apiDomain,captureTime,captureRandom]; }

9.4.3 services-config.xml Dit bestand geeft aan dat AMFPHP gebruikt wordt, dit is de gratis open-source PHP implementatie van het Action Message Format (AMF). AMFPHP implementeert het AMF protocol dat toelaat dat de client-application (de previewapplicatie) kan communiceren met PHP class objects op de server.

<services-config> <services> <service id="sabreamf-flashremoting-service" class="flex.messaging.services.RemotingService" messageTypes="flex.messaging.messages.RemotingMessage"> <destination id="amfphp"> <properties> <source>* <endpoint uri="/services/amfphp" class="flex.messaging.endpoints.AMFEndpoint"/>

Johnny Rymenans

juni 2010



p 75/96

9.4.4 flexxml-service Deze service is als een drupal module geïmplementeerd in PHP. De service bouwt een geldige XML-file op die zijn gegevens haalt uit de databank van de drupal installatie. De kernfunctie -in termen van Drupal spreken we van een hook- van deze module is de flexxml_service_xml().

function flexxml_service_xml() { //Start de output voor XML $uitvoer = ""; $uitvoer .= ""; $specialchar = array("&",">","<"); //speciale characters $specialcharReplace = array("&",">","<"); //vervanging $object = db_query("SELECT DISTINCT(objectnaam) FROM {flexxml_service}"); $objecten = array(); while( $naam = db_fetch_object($object) ){ $objecten[] = $naam->objectnaam; } //haal voor elk object al zijn fotos op foreach( $objecten as $object ) { $uitvoer .= ""; } $uitvoer .= ""; $xmlFileName = "sites/default/files/test2.xml"; $xmlFileHandle = fopen($xmlFileName, 'w') or die("can't open file"); fwrite($xmlFileHandle, $uitvoer); fclose($xmlFileHandle); return $uitvoer; }

Stel dat in de databank twee objecten opgeslagen zitten, waarbij voor het ene object (kasten) twee fotos en voor het object stoelen slechts één foto is opgeslagen, dan zou de output van deze functie als volgt kunnen zijn:

Johnny Rymenans

juni 2010



p 76/96

Naast deze hook bevat de module nog een aantal andere hooks die nodig zijn voor de rechten, de menu, het aan- en uitschakelen van de service, enz...

9.5 Uitbreidingen Zoals reeds een aantal keren werd aangegeven is de previewapplicatie in zijn huidige vorm een concept, een prototype. De uiteindelijke applicatie zal veel meer functionaliteit bezitten, een aantal ideeën die wellicht verder uitgewerkt gaan worden zijn de mogelijkheid tot het aanpassen van de foto's en het aantal objecten dat toegevoegd kan worden. Zo zal het mogelijk worden om de foto van het gekozen kunstwerk te vergroten, verkleinen en verplaatsen. Momenteel wordt de applicatie beperkt tot het invoegen van slechts één kunstobject. Dit zal uitgebreid worden met een drag and drop functionaliteit zodat het mogelijk wordt om objecten te verplaatsen en dus ook de kans biedt om meerdere kunstobjecten in één interieur te plaatsen. Hiertoe zal het XML formaat licht aangepast moeten worden zodat er coördinaten kunnen opgeslagen worden en een identificatie van de ingevoegde kunstobjecten. Er zijn nog tal van mogelijke uitbreidingen die de previewapplicatie rijker en interessanter kunnen maken. Verder werd er, hoewel er wel met gebruiksvriendelijkheid rekening werd gehouden, in dit concept niet veel aandacht besteed aan de look. Flex biedt zeer veel mogelijkheden om deze applicatie mooier te maken, alles wat men reeds van Flash verwacht, kan ook toegepast worden in Flex. Ten slotte, zou het met minimale moeite mogelijk moeten zijn om van deze applicatie een desktop applicatie te maken, gebruik makend van het Adobe AIR framework.

Johnny Rymenans

juni 2010



p 77/96

10 Slotbeschouwing Het commercieel webplatform -de versie die voor de masterproef wordt ingediend- is het resultaat van een kleine vier maanden werk. Dit houdt in de analyse van het project, studie- en opzoekingswerk in verband met Drupal6 en modules, studie- en opzoekingswerk in verband met Flex voor de previewapplicatie, het definiëren van de content types, de views, het schrijven van de eigen modules, het definiëren van acties ter bevordering van de workflow en uiteindelijk het online brengen met de nodige configuratie. Dit alles gebeurde, terwijl er ook gewerkt werd aan de thesistekst. De aandachtige lezer is het wellicht opgevallen dat in bovenstaande paragraaf werd gesproken over een versie. Het is namelijk zo dat ik deze masterproef reeds geruime tijd geleden heb aangevat en dat ondertussen de technologie niet stilstaat. Drupal is hier geen uitzondering op. De veranderingen van Drupal, de gewijzigde specificaties voor Invent Design, gecombineerd met een paar moeilijkheden, hebben tot de beslissing geleid om het deel van het webplatform dat ik reeds had gemaakt, volledig te herschrijven. In wat volgt ga ik een overzicht maken van wat ik geleerd heb, de moeilijkheden die zijn opgetreden en er worden een paar beslissingen kort toegelicht. Uiteindelijk rond ik de thesistekst af met een conclusie.

10.1

Wat heb ik geleerd

Wanneer men een groter project opvat, is planning een zeer belangrijke fase. De planning en analyse dienen grondig en volledig te gebeuren, anders verhoogt het risico dat het project zal mislukken. Het maken van duidelijke afspraken en het afbakenen van de uit te werken functionaliteiten hangt hier nauw mee samen. Zonder duidelijke afspraken loopt een project het risico in tijdsnood te komen. Drupal is een zeer uitbreidbaar en flexibel framework, maar met de mogelijkheden stijgt ook de complexiteit, wat de leercurve steiler maakt. Het feit dat het framework niet objectgeoriënteerd is, maakt het er niet makkelijker op, aangezien het een andere manier van denken vergt. Maar eens men de terminologie en de werking van Drupal meer begint te begrijpen, opent het een ontzettend ruime waaier van mogelijkheden. Werken aan een echt project met echte opdrachtgevers verschilt in zeer grote mate van de opgaven van een labo, waar alles in een gecontroleerde omgeving gebeurt. Wanneer men in de "realiteit" beslissingen neemt, zijn hier gevolgen aan verbonden die niet altijd te voorzien waren. Zo zijn er functionaliteiten die het ene framework aanbiedt, maar een ander (nog) niet; dan moet er afgewogen worden welk framework de grootste lading aan benodigde functionaliteiten dekt. Er moeten keuzes gemaakt worden en gevolgen ingeschat. Dit leert ook een grotere mate van zelfstandigheid aan. Uiteindelijk heb ik spijtig genoeg ondervonden hoe belangrijk het is om back-ups te maken. Hoewel ik genoeg back-ups maakte, heeft de harde schijf waarop ze opgeslagen stonden het begeven. Het periodiek online opslaan van de back-ups heeft niet kunnen voorkomen dat ik een grote hoeveelheid data heb verloren, waaronder de analyses, Johnny Rymenans

juni 2010



p 78/96

stukken thesistekst, code van modules, etc. Met de mogelijkheid van falende hardware had ik tot dan, nooit rekening gehouden. Een andere belangrijke les die ik heb geleerd, is dat wanneer er zich een probleem voordoet en men zijn eigen code tot op het bot heeft getest, de fout misschien niet bij de eigen code ligt. Soms bevat code die geschreven en gecontroleerd is door ervaren programmeurs ook nog fouten. Toen werkende code, na het uitvoeren van security updates van Drupal en andere contributed modules, plots niet meer werkte, bleek de oorzaak een bug te zijn die geïntroduceerd was door die updates. Deze bug veroorzaakte ook in heel wat contributed modules problemen zodat ze snel aan het licht kwam en bijgevolg snel werd opgelost door de core maintainers van Drupal.

10.2

Enkele moeilijkheden

De opgetreden moeilijkheden hangen nauw samen met de dingen die ik geleerd heb. In verband met de planning heb ik doelgericht het woordje volledig erbij gevoegd. Bij de implementatie van de eerste versie - deze in Drupal5 - heb ik eerst een analyse opgesteld. Hierin werd bepaald dat er vijf gescheiden zuilen zouden worden opgesteld. Hoewel de specificaties van sommige van die zuilen nog niet gekend waren, had ik besloten om te werken met een analyse per zuil zodat ik reeds kon beginnen met de implementatie van de gekende zuilen terwijl de zaakvoerder uitwerkte wat het resultaat van de overige zuilen moest worden. In het begin liep alles zoals gehoopt, de problemen begonnen pas wanneer ik begon met de implementatie van de zuil van de juryleden. Deze zuil gebruikt de data die via een andere zuil wordt ingegeven. Alleen bleken er een aantal beslissingen incompatibel te zijn, hoewel de keuzes in theorie geen probleem zouden opleveren. De lijmcode die geschreven moest worden, voegde heel wat redundante informatie in de databank toe en moest bepaalde gegevens op de server nogmaals op een andere manier opslaan. Hoewel deze methode zou werken, kon ik deze werkwijze moeilijk verdedigen. Ondertussen was Drupal6 de nieuwe standaard geworden en werd er reeds gewerkt aan Drupal7. Dit is van belang aangezien Drupal officieel maar ondersteuning biedt voor de twee recentste stabiele versies. Dit zou betekenen dat niet lang nadat de masterproef zou afgerond worden, er geen security updates meer zouden worden geleverd voor Drupal5, de versie waar de masterproef in geschreven zou zijn. Security updates zijn toch wel van belang voor een commercieel webplatform. Toen zaakvoerder had aangegeven dat zijn idee over de site was geëvolueerd, heb ik de weloverwogen beslissing genomen om over te stappen op Drupal6 en de site van nul terug op te bouwen. Dit was één van de beste beslissingen die ik heb gemaakt. Door terug van nul te beginnen had ik de mogelijkheid om bovenstaande problemen te voorkomen. De kwaliteit van het uiteindelijke resultaat is er bijgevolg aanzienlijk op vooruit gegaan. Verder heb ik me ook meer aan de "Drupal way of doing things" gehouden. Door gebruik te maken van de dingen die ik geleerd had van mijn eerste poging heb ik een aantal moeilijkheden kunnen voorkomen, onder andere door het Johnny Rymenans

juni 2010



p 79/96

gebruik van CCK en Views . Deze twee complementaire modules besparen developers ook veel tijd. Wanneer er namelijk aan de queries iets veranderd moet worden maakt men ofwel een nieuwe view aan ofwel past men die via de UI even aan. Wanneer men eigen modules maakt die lijsten weergeven, dan moet men de SQL van de module gaan wijzigen.

10.3

Een conclusie

Eén van de belangrijkste keuzes die ik heb gemaakt was de overstap van Drupal5 naar Drupal6. De keuze om van nul terug te beginnen in plaats van een directe port te maken van wat ik al had gerealiseerd in Drupal5 was één van de beste beslissingen die ik heb genomen. Het resultaat is er ongetwijfeld beter door geworden. Verder is Drupal een framework dat mijn interesse voor webdevelopment heeft aangewakkerd, zodanig zelfs dat ik uitkijk naar de release van Drupal7. De Drupal 7.0alpha4 heb ik ondertussen al eens uitgeprobeerd en het belooft zeer interessant te worden. De samenwerking met Jean, de zaakvoerder van Invent Design, is zeer goed meegevallen, als er in de toekomst nog extra mogelijkheden moeten toegevoegd worden of aangepast, dan kan hij me altijd contacteren.

Johnny Rymenans

juni 2010


Johnny Rymenans


p 80/96

juni 2010



p 81/96

Lijst met figuren Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur

1: Technologiestack van Drupal (Pro Drupal Development (VanDyk & Westgate, 2007)) ..13 2: Drupal Core en aanvullende modules (Pro Drupal Development (VanDyk & Westgate, 2007)) ....14 3: Mappenstructuur Drupal6.........................................................................17 4: Contributed & eigen modules voor Invent Design ........................................18 5: De juryobject_categorieen tabel ...............................................................23 6: Het voeg categorie toe formulier...............................................................23 7: Inloggen van een gebruiker .....................................................................31 8: Voorbeeld Merchandising rol.....................................................................32 9: Voorbeeld Auteursrol ...............................................................................33 10: Voorbeeld Topklant rol ...........................................................................34 11: De previewapplicatie .............................................................................35 12: Administration menu .............................................................................42 13: Devel block ..........................................................................................42 14: De velden en types van het Afgekeurde Objecten content type ...................52 15: Afgekeurde Objecten formulier ...............................................................52 16: Afgekeurde Objecten full view ................................................................52 17: Voorbeeld van de view UI ......................................................................53 18: Tools van een Auteur.............................................................................55 19: Tools van een Jurylid .............................................................................56 20: Tools van een Topklant ..........................................................................57 21: Merchandiser Catalog ............................................................................57 22: Leverancier tools...................................................................................58 23: Admin tools ..........................................................................................58 24: De Joomla architectuur ..........................................................................61 25: Screenshot van de previewapplicatie .......................................................70 26: De databank aanmaken .........................................................................85 27: De foutmelding tijdens de installatieprocedure ..........................................86 28: Aanmaning om cron uit te voeren ...........................................................87 29: Vergelijkende tabel Drupal - Joomla - deel1 .............................................93 30: Vergelijkende tabel Drupal - Joomla - deel2 .............................................94 31: Vergelijkende tabel Drupal - Joomla - deel3 .............................................95

Johnny Rymenans

juni 2010


Johnny Rymenans


p 82/96

juni 2010



p 83/96

Literatuurlijst Joomla and Drupal - Which One is Right for You? Version 2. . Adobe Developer Connection. . Chaffer, jonathan. Drupal programming from an object-oriented perspective. . Coding standards. . Drupal API. . Drupal. . joomla! Documentation. . Modules. . PHP: parse_ini_file - manual. . Project usage overview. . Search, Rate, And Review Drupal Modules. . VanDyk, John K. Pro Drupal Development Second Edition. Apress, 2008. Vlissides, John. "Pattern Hatching" column for February '96 issue. February 1996. May 2010

. Westgate, John K. VanDyk and Matt. Pro Drupal Development. Apress, 2007.

Johnny Rymenans

juni 2010


Johnny Rymenans


p 84/96

juni 2010



p 85/96

Appendix A: Installatie van een drupalsite Drupal is een content management framework geschreven in PHP5. Het is platformonafhankelijk op voorwaarde dat PHP ondersteund wordt. Verder verwacht Drupal een databank, standaard zal Drupal MySQL of PostgreSQL als databank gebruiken, maar dankzij een data-abstraction layer zijn ook andere databanken mogelijk. Dit zijn de enige echte voorwaarden waaraan een host moet voldoen. In wat volgt lichten we stap voor stap toe wat men moet doen om een standaard drupal installatie tot een goed einde te brengen. Hierbij werd er gebruik gemaakt van XAMPP als lokale server.

Voorbereiding Voordat we met de eigenlijke installatie van Drupal kunnen beginnen moeten we eerst een aantal voorbereidingen treffen: 1. 2. 3. 4.

Download de recentste versie van Drupal van www.drupal.org Extract de tar.gz in de htdocs map van XAMPP Hernoem de map naar een duidelijke naam bv: inventdesign Maak een database aan, bv door middel van phpmyadmin

Figuur 26: De databank aanmaken 5. Ga in uw browser naar localhost/inventdesign/install.php Nu kunnen we beginnen met de eigenlijke installatie.

Johnny Rymenans

juni 2010



p 86/96

Installeren Vanaf Drupal6 is het installatieproces veel duidelijker en gebruiksvriendelijker gemaakt. De gebruiker wordt stap voor stap begeleid in het installatieproces. 1. Kies de taal 2. Je krijgt een "foutmelding" te zien:

Figuur 27: De foutmelding tijdens de installatieprocedure 3. Het is van groot belang dat men een kopie neemt van de file ./sites/default/default.settings.php en deze kopie hernoemt naar ./sites/default/settings.php. Het is van belang dat men een kopie maakt anders krijgt men fouten die niet meteen duidelijk aangeven wat het probeem is! 4. Zorg ervoor dat de file ./sites/default/settings.php writable is, drupal zal hier namelijk een aantal gegevens in wegschrijven, zoals de connectionstring naar de databank en dergelijke. klik op "try again". 5. Geef de database naam (dit is de naam van de database die in stap 4 van de voorbereiding werd aangemaakt), en geef ook de username voor de database en het bijhorende paswoord. Deze gegevens hebt u normaal gekregen van uw host. Indien u XAMPP gebruikt zal dit wellicht "root" zijn en paswoord gewoon leeglaten 6. Vervolgens worden u een aantal gegevens gevraagd betreffende de site die u wenst op te zetten. Alle velden die met een * worden aangeduid zijn verplicht. Belangrijk: Het aanmaken van een Aministrator account is van groot belang. Deze user heeft alle access en is de enige die een site die problemen heeft, kan herstellen! Zorg er dus voor dat je de gegevens die je daarvoor opgeeft niet vergeet! 7. Ga nu naar de site zelf. Johnny Rymenans

juni 2010



p 87/96

8. Het is aangeraden om nu naar Administer te gaan. Daar verschijnt de melding

Figuur 28: Aanmaning om cron uit te voeren volg die link. Daar kan je cron zelf laten runnen, of indien je het wil automatiseren, kan je cron jobs configureren. Normaal gezien, als alles in orde is met de site worden nu alleen groene vakjes getoond. Indien er iets fout liep bij de installatie zal dat hier in het rood aangeduid worden! Wanneer er kritische updates zijn van drupal zal dat ook hier aangegeven worden.

Nu heb je de meest elementaire basisinstallatie van een drupal site tot je beschikking. Je kan nu beginnen met het bouwen van je site. Meer dan waarschijnlijk zal je hiervoor beroep doen op contributed modules om je hier in bij te staan om diverse functionaliteiten aan je site toe te voegen.

Johnny Rymenans

juni 2010


Johnny Rymenans


p 88/96

juni 2010



p 89/96

Appendix B: Een eigen Drupal5 module. Inv_kiesObject.module

'inv_kiesObject', 'title' => t('kies object'), 'description' => t('If you want to add inv_kiesObject to your site.'), 'callback' => 'drupal_get_form', 'callback arguments' => array('inv_kiesObject_form', $page), 'access' => user_access('send inv_kiesObject') ); } return $items; } $objectenarray; /** * Define the form * Hier staat de code die de dropdownlist op het scherm brengt. Voor opmaakdoeleinden * wordt deze in een fieldset geplaatst. De list wordt opgevuld met de objecten die door .* de ingelogde gebruiker werden ingediend (de user is een ontwerper of admin * aangezien (momenteel) die rollen de rechten hebben die men nodig heeft om deze * module te gebruiken. De lijst wordt uit de databank opgehaald. */ function inv_kiesObject_form(&$node){ global $user; $type = node_get_types('type', $node); $form['inv_kiesObject'] = array( '#type' => 'fieldset', '#title' => t('Kies het object dat je wil indienen, of bekijken en bewerken'), '#collapsible' => FALSE, Johnny Rymenans

juni 2010



p 90/96

'#collapsed' => FALSE, ); if ( user_access('view inv_kiesObject') ) { $objecten = db_query("SELECT `naam` FROM ìnv_kunstobjecten`"); } else{ $objecten = db_query("SELECT `naam` FROM ìnv_kunstobjecten` WHERE òntwerper_id`=%d", $user->uid); } global $objectenarray; $objectenarray = array(t('[Nieuw object]')); while ($item = db_fetch_object($objecten)){ $objectenarray[] = t($item->naam); } $form['inv_kiesObject']['namen'] = array( '#type' => 'select', '#title' => t('objectnaam'), '#options' => $objectenarray, '#description' => t('Let op: de objectnaam is niet hoofdlettergevoelig.'), ); $form['inv_kiesObject']['submit'] = array( '#type' => 'submit', '#value' => 'Openen' ); return $form; } /** * Save the choice into the inv_kiesObject table of the database * Wanneer er op “Openen” geklikt werd, word deze functie opgeroepen (normaal kan er * nog een validatie functie opgeroepen worden, maar dat was hier niet van toepassing. * De keuze van de gebruiker wordt opgeslagen in een tabel in de databank, en de * gebruiker zal normaal automatisch doorverwezen worden naar het formulier dat de * gegevens van het gekozen object weergeeft. */ function inv_kiesObject_form_submit($form_id, $form_values) { global $user, $objectenarray; //checken of er al een entry is voor die ontwerper, en zo ja, updaten die entry $object = $form_values['namen']; $objecten_query = db_query("SELECT `kunstobjecten_id` FROM ìnv_kunstobjecten` WHERE `naam` LIKE '%s'",$objectenarray[$object]); $object_id = db_fetch_object($objecten_query); if( $objectenarray[$object] == t('[Nieuw object]') ) { db_query("DELETE FROM ìnv_kiesObject` WHERE òntwerper_id`=%d",$user->uid); } else { db_query("DELETE FROM ìnv_kiesObject` WHERE òntwerper_id`=%d", $user>uid); db_query("INSERT INTO {inv_kiesObject} (ontwerper_id, object_id) VALUES(%d, %d)", $user->uid, $object_id->kunstobjecten_id); }

Johnny Rymenans

juni 2010



p 91/96

drupal_set_message(t('Als de pagina niet automatisch herlaadt, ga dan naar hier.<meta http-equiv="refresh" content="0;URL=/drupal-5.7/inv_kunstobjecten" />')); } /** * Implementation of hook_perm(). * Hier defineer je de lijst van permissies. */ function inv_kiesObject_perm(){ return array('send inv_kiesObject', 'view inv_kiesObject'); } /** * Implementation of hook_access() * Hier check je of de gebruiker al dan niet de benodigde permissie heeft. */ function inv_kiesObject_access($op, $node){ global $user; if ($op == 'create'){ return user_access('send inv_kiesObject'); } else if ( $op == 'view'){ return user_access('view inv_kiesObject'); } }

Inv_kiesObject.info

; $Id$ name = Inv_kiesObject description = Allows users to choose which of their objects they want to see or edit. package = InventDesign version = "$Name$"

Johnny Rymenans

juni 2010



p 92/96

Inv_kiesObject.install

Johnny Rymenans

juni 2010



p 93/96

Appendix C: Vergelijking Joomla! en Drupal

Figuur 29: Vergelijkende tabel Drupal - Joomla - deel1 Johnny Rymenans

juni 2010



p 94/96

Figuur 30: Vergelijkende tabel Drupal - Joomla - deel2

Johnny Rymenans

juni 2010



p 95/96

Figuur 31: Vergelijkende tabel Drupal - Joomla - deel3

Johnny Rymenans

juni 2010


Johnny Rymenans


p 96/96

juni 2010

Ontwikkeling van een commercieel webplatform

Recommend Documents