Een CMS aanwenden of op maat schrijven?

Voor je aan een project begint, dienen er talrijke assumpties gemaakt te worden. Wat zijn de vereisten? Welke ontwikkelingsmethode wordt er aangewend? Is het project haalbaar binnen tijd en budget? Is de infrastructuur beschikbaar? Bij het ontwikkelen van de IMBIT website werd al deze problematiek reeds behandeld. Een issue die echter meer tijd in beslag nam, is of wij zelf alle programmatuur op maat zouden schrijven oftewel een CMS, meer bepaald Drupal zouden aanwenden.

De IMBIT site moet eigenlijk een geïntegreerd platform vormen inclusief forum, kalender, nieuwsbrief en een blog. Bovendien moet dit alles SSO zijn en gebaseerd zijn op user-levels.

Redenen die werden aangehaald om gebruik te maken van een CMS zoals Drupal zijn de volgende.

  • Drupal is modulair opgebouwd; biedt modules aan om een forum te integreren en beschikt over een ingebouwd kalender systeem.
  • De vereiste dat er user-levels configureerbaar moeten zijn wordt ook mooi ingevuld.
  • Drupal is rijp: er staat een enorme actieve community achter. Alles is goed gedocumenteerd.
  • Het is eenvoudig te beheren: het kost geen moeite om zelf de presentatie laag vorm te geven (themes).

Nochtans is er besloten om gedeeltelijk op maat te schrijven. Voor het forum wensen we gebruik te maken van phpBB3, voor de blog WordPress. Verder hebben we onze gepersonaliseerde user table. Dit betekent dat registreren op de website hoort te gebeuren, evenals het single sign-on aanmelden.

Maar waarom dan geen Drupal of een andere CMS gebruiken? Laat het duidelijk zijn dat we het wiel niet willen heruitvinden. Een reden is rechtlijnig met het concept van Vendor lock-in, namelijk dat je afhankelijk bent van hun platform. Stel dat ze het hele concept over een andere boeg gooien. Gans nieuwe structuur en database model bijvoorbeeld. Tja, dan kan dat, misschien geen geld, maar wel veel moeite kosten. Alleen bij commerciële firma’s die Open Source producten zijn gaan aanbieden, zoals RedHat en MySQL of zelfs Movable Type, vormt dit op zich een minder ernstig gevaar. Bij zulke bedrijven is het vanuit commercieel oogpunt immers belangrijk dat oudere systemen compatibel zijn met nieuwere.

Keuzes dienen gemaakt te worden, en ook het op maat schrijven heeft zijn nadelen. Een nadeel dat je hebt bij het schrijven van je eigen code, is dat je het goed moet documenteren opdat volgende generaties developers begrijpen wat er precies gebeurt. Ook hier werd over nagedacht en daarom zal alle code volgens phpDocumentor gedocumenteerd worden. Een ander nadeel is dat we de taxonomie van de verschillende gebruikersrechten zelf gaan moeten implementeren. Dat is niet eenvoudig, maar het biedt wel de volle 100% controle en dat is, vooral op langere termijn, van cruciaal belang. Ook is het zo dat zowel WordPress als phpBB3 beschikken over voldoende functionaliteit, zodat deze geen upgrade meer nodig hebben. Op die manier kunnen wij eigenlijk volledig onafhankelijk en gecontroleerd opereren.

Leave a Reply

Your email address will not be published. Required fields are marked *