[ALG] Modules van een CMS

hoeveel "modules" gebruikt een gemiddelde website nu eenmaal?

waarom zou je een forum eigenlijk op een of andere diepe url willen wegstoppen?

Reveller schreef op dinsdag 02 augustus 2005 @ 09:18:
Ik ben nu al een tijdje bezig met mijn eigen cms. In heb mezelf goed ingelezen, en heb ook veel open-source cms'en bekeken voordat ik zelf begon te bouwen.

In het begin denk je "alles moet zo flexibel mogelijk zijn". Maar gaandeweg heb ik bewust flexibiliteit ingeleverd voor gebruiksvriendelijkheid. En daar ben ik tevreden over.

Momenteel zit mijn cms zo in elkaar, dat je alle "modules" (weblog, forum, statistieken, gastenboek, etc.) op elke gewenste plek binnen de website kunt zetten. Je kunt het forum dus plaatsen op website.com/forum of bijvoorbeeld website.com/bedrijf/support/forum.

Een van de cms'en waar ik vooral wat betreft gebruiksvriendelijkheid een groot voorbeeld aan genomen heb, is Manila van het bedrijf Userland. Eigenlijk is hun product meer een weblog dan cms, maar het is vooral de intuitiviteit van het systeem dat ik wilde "kopieren".

Bij Userland zijn ze heel eenvoudig: alle extra modules zitten bij hen op vaste plaatsen: de statistieken op website.com/stats, het forum op /discuss, de surveys op /surveys, de search op /search. Op deze manier is dat weer iets waar de gebruiker niet naar om hoeft te kijken.

Nu begin ik er steeds meer voor te voelen om mijn cms in gebruiksvriendelijkheid aan te passen om ook de eventuele modules op vaste url's te zetten. De belangrijkste redenen hiervoor zijn:

• hoeveel "modules" gebruikt een gemiddelde website nu eenmaal?
• waarom zou je een forum eigenlijk op een of andere diepe url willen wegstoppen?

Mijn vragen aan jullie:

• wat is jouw mening hierover?
• welke "modules" ondersteunt jouw cms en zijn er modules die je logischerwijs niet in de root van de website kunt zetten?
• hoe werkt jouw cms op dit gebied?

Verwijderd schreef op dinsdag 02 augustus 2005 @ 09:59:
[...]


Wil niet vervelend zijn maar die modules die je gemaakt hebt zijn vrij standaar en worden door door professionele bedrijven cq klanten niet vaak meer gebruikt of zijn daar standaardfunctionaliteit. Eigenlijk zijn er dus nog geen echte modules. Maar als dit gewoon bedoeld is voor jan met de pet en een eigen website dan is dit een leuk projectje

Parcye schreef op dinsdag 02 augustus 2005 @ 10:05:
[...]


Hier kan ik het op geen enkele manier in vinden. Ik denk dat ruim 50% misschien zelfs 70% van de MKB zeer goed geholpen is met een 'jan met de pet' oplossing. Bedrijven die standaardfunctionaliteit niet gebruiken hebben daarom vaak een veel te dure oplossing waardoor een site nooit echt van de grond komt omdat ze het ervaren als slechte inverstering.

Als je met professionele bedrijven het grote segment bedoelt (philips, shell, kpn etc), is het inderdaad zo dat ze met maatwerk beter geholpen zijn

[ Voor 23% gewijzigd door Verwijderd op 02-08-2005 10:14 ]

Verwijderd schreef op dinsdag 02 augustus 2005 @ 10:07:
[...]


Kan wel zo zijn, maar dit bestaat al in honderden vormen...

Reveller schreef op dinsdag 02 augustus 2005 @ 09:18:

• waarom zou je een forum eigenlijk op een of andere diepe url willen wegstoppen?

TheDane schreef op dinsdag 02 augustus 2005 @ 10:13:
Ik snap je concept "Elke willekeurige plek binnen de website" icm met padnamen niet. Een padnaam is niet meer dan een "gebruiksvriendelijke" representatie, in dit geval om een pseudo structuur aan te geven binnen je site/cms.

Kijk eens naar Drupal, een modulair cms wat ook met eigengemaakte modules uit te breiden is.

Dit cms maakt gebruik van bepaalde nodes om naar modules binnen je site te navigeren, bijvoorbeeld site.org/?q=node/1 of site.org/?q=node/2

Daarnaast kun je deze nodes zelf namen geven waardoor je iets krijgt als: site.org/?q=archive of site.org/?q=mycontentitem

Zo geef je je users dus zelf de mogelijkheid om hun 'structuur' te bepalen en namen voor content te kiezen.

Reveller schreef op dinsdag 02 augustus 2005 @ 19:15:
[...]

Leuk idee, dank je! Verder ben ik het met je eens dat er al honderden cms'en zijn die jij ws. als net-niet ervaart (want: niet enterprise class). Maar zoals gezegd, 70% van de MKB bedrijven kan zeker met een Manila-achtige oplossing uit de voeten. Ik denk nog wel meer - onder andere de Erasmus Universiteit (RSM) heeft een tijd met succes op Manila gedraaid. En laat van alle bedrijven nu 95% onder het MKB vallen

En bij grotere bedrijven wordt ook nog steeds vaak met verschillende systemen naast elkaar gewerkt - voor het bedrijf van mijn vriendin (grote multinational in olie / steenkolen) heb ik een klein intranet neergezet voor alle nederlandse juristen van een bepaalde tak. Je hebt het dan over plm. 100 man en dat valt prima op te vangen met met een zelfgeknutseld php systeempje.

Terugkomend op Drupal - dat systeem is gebouwd vanuit een "alles-is-een-node"-visie. Met andere woorden: zowel weblog posts als "gewone" verhalen als bestanden als plaatjes als [etc] wordt in 1 tabel opgeslagen:

code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

`nid` int(10) unsigned NOT NULL auto_increment, `type` varchar(16) NOT NULL default '', `title` varchar(128) NOT NULL default '', `uid` int(10) NOT NULL default '0', `status` int(4) NOT NULL default '1', `created` int(11) NOT NULL default '0', `changed` int(11) NOT NULL default '0', `comment` int(2) NOT NULL default '0', `promote` int(2) NOT NULL default '0', `moderate` int(2) NOT NULL default '0', `teaser` longtext NOT NULL, `body` longtext NOT NULL, `revisions` longtext NOT NULL, `sticky` int(2) NOT NULL default '0', `format` int(4) NOT NULL default '0',

Opzich is het wel helder, maar ga je dan uiteindelijk niet een node in die tabel "proppen" en laat je extra properties weg die eigenlijk wel nodig zijn? Bij mij kun je een weblog-post aan een categorie toekennen. Je kent dat wel: "gepost op datum door die in categorie". Ik zie meteen al geen "category" kolom in Drupals node tabel staan. Die kan ik dan wel toevoegen, maar als ik in de node tabel bv. een verhaal opsla, wil ik die weer niet toe te kennen aan een categorie. Dan laat ik die kolom dus leeg. Er vallen dan wel gaten...

Ik ben blij dat iemand Drupal noemde, want na wat nadere beschouwing blijkt dat Manila ook zo werkt: het format van een "news", "story" of "image" post is hetzelfde. Zijn er meer mensen die op deze manier werken in plaats van voor elk content type een aparte tabel aan te leggen? Ik ben heel benieuwd!

[ Voor 11% gewijzigd door Verwijderd op 03-08-2005 22:00 ]

[ Voor 4% gewijzigd door Suepahfly op 03-08-2005 22:28 ]

Standaard regel voor URL: Deze mag NOOIT veranderen, omdat dat problemen kan meebrengen.

Reveller schreef op woensdag 03 augustus 2005 @ 17:33:
[...]

Ik heb nu een aparte tabel voor elke content type, bijvoorbeeld een tabel "stories":

code:

1 2 3 4 5 6

`sid` int(3) NOT NULL auto_increment, `title` varchar(200) NOT NULL default '', `body` longtext NOT NULL, `created` int(10) NOT NULL default '0', `changed` int(10) NOT NULL default '0', `uid` int(2) NOT NULL default '0',

een story is een pagina met daarop alleen tekst. Daarnaast heb ik bv. een tabel weblog_posts:

code:

1 2 3 4 5 6 7 8 9

`id` int(6) NOT NULL auto_increment, `title` varchar(200) NOT NULL default '', `url` varchar(255) NOT NULL default '', `body` longtext NOT NULL, `created` datetime NOT NULL default '0000-00-00 00:00:00', `t_created` int(10) NOT NULL default '0', `modified` timestamp(14) NOT NULL, `category` int(3) NOT NULL default '1', `uid` int(2) NOT NULL default '0',

Wat Drupal doet is 1 tabel "nodes" aanmaken, waarin je met "type" aangeeft of de node een "story" of een "weblog_post" is. Vervolgens kun je een reeks properties van zo'n node invullen: body, created, uid (user id), etc. Je maakt van je content types een soort eenheidsworst. Bij Drupal worden zelfs files en images in diezelfde nodes-tabel opgeslagen.

Mijn vraag is dus of dit een gangbare manier van werken is. Ik snap overigens niet precies wat je bedoelt met een overkoepelende DB? Niet-content tabellen zoals een settings-tabel en een user-tabel?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Nodes
nodeId nodeType ... etc
1      blogPost
2      story
3      plaatje
4      blogPost

BlogPosts
nodeId postContent ... etc
1      Blaat test spef melp
4      Test melp spef blaat

Plaatjes
nodeId plaatjeUrl ... etc
3      weetikveel/spef.jpg

Stories
nodeId storyContent ... etc 
2      Dit is een verhaal spef.

[ Voor 5% gewijzigd door Mithrandir op 04-08-2005 13:06 ]

[ Voor 70% gewijzigd door alienfruit op 04-08-2005 13:30 ]

Reveller schreef op donderdag 04 augustus 2005 @ 12:27:
[...]

Betekent dat ook dat jij gebruik maakt van een generieke tabel waar alle content in opgeslagen wordt? Wat zijn daarvan de voordelen? Ben je ook nadelen tegen gekomen (zoals: niet elk content type zal een property "category" hebben en die kolom is dan leeg - is dat niet slordig?)

[ Voor 15% gewijzigd door Verwijderd op 04-08-2005 13:46 ]

alienfruit schreef op donderdag 04 augustus 2005 @ 13:25:
Op die manier kan je dus nooit de URI wijzigen van bestaande systemen <g>
Als je URI niet kan wijzigen zit je dus met het probleem als je de site click2music.nl heb en URIs wilt wijzigen naar: www.click2music/artiest/christinaaguilera. Dat je dan een probleem omdat dus volgens jou niet mag cq kan. Onzin natuurlijk je moet een brug kunnen slaan tussen de nieuwe URIs en de oude URIs van de oude systemen.

[ Voor 9% gewijzigd door Verwijderd op 05-08-2005 00:28 ]

Reveller schreef op vrijdag 05 augustus 2005 @ 16:04:
Ben net eens in Drupal gedoken, en idd - niet-algemene velden staan in aparte tabellen.

Hel Gast, deze gast die even zijn hele CMS uit de doeken doet Ik ga het eens goed nalopen.

offtopic:
"Rij" = queue, niet que

[ Voor 49% gewijzigd door Verwijderd op 05-08-2005 16:16 ]