[alg] Gebruik van containers in een CMS*

[Verwijderd]

Ik ben een beetje de mogelijkheden aan het bekijken van structurering van content in een CMS. Een veel gebruikte methode is door het gebruik van 2 objecten nl. een pagina en een artikel en het artikel een child te maken van zijn parent, nl. pagina.

Je loopt alleen zo tegen het probleem aan dat een artikel loshangt van de layout. Vraag je een pagina op, dan worden hierbij artikelen opgevraagd met het parentid van de pagina maar hoe en waar deze artikelen op de pagina komen te staan dat wordt niet gedefinieerd.

Bij een portal zoals bijv. rtl4 echter heb je veel "content gebieden". Veelal worden deze gebieden in CMS systemen aangeduid met termen als "container" of "content display". Ik hoor echter veel geklaag over het feit dat redactie niets snapt van het principe "container". Als techneut weet je dat je een container gebruikt om een stukje content op een bepaalde plek in een pagina te zetten.

Wat zijn naast "containers" nog meer mogelijkheden om content binnen een pagina een plek toe te wijzen? Ik zou graag wat ervaringen en of technische ervaring willen weten op dit gebied. Ik heb zelf eens gezocht, maar een "container" schijnt een beetje gemeengoed te zijn geworden.

[alienfruit]

Ik houd me graag aanbevolen over de links die je hebt gevonden over die "content displays" en/of "containers". Alvast bedankt!!!

Overigens vind ik het gebruik van pagina/tijdschrift idee wat achterhaald, dus ik zou eigenlijk gaan voor het containers idee. (natuurlijk wel goed beschrijven/uitleggen aan de eindgebruiker) Omdat dit namelijk wat dynamischer is dan het pagina-wise gedoei.

Dat is namelijk wel leuk, alleen heb geen flauw idee hoe je dat het beste zou moeten opslaan in een database

[ Voor 75% gewijzigd door alienfruit op 06-04-2003 21:05 ]

[Verwijderd]

alienfruit schreef op 06 April 2003 @ 20:58:
Ik houd me graag aanbevolen over de links die je hebt gevonden over die "content displays" en/of "containers". Alvast bedankt!!!

Ik zou zeggen, bekijk de features van oa de grote CMS suppliers eens, en ze gaan allemaal uit van het container principe om content een positie binnen een pagina te geven. Ik ben dus benieuwd of er al mensen zijn die het anders hebben aangepakt.

[Verwijderd]

alienfruit schreef op 06 april 2003 @ 20:58:
Dat is namelijk wel leuk, alleen heb geen flauw idee hoe je dat het beste zou moeten opslaan in een database

Dat is niet het probleem. Een container hang je aan een pagina, een artikel hang je aan een container.

HomepageId = 1
ContainerId = 2, ParentId = 1
ArtikelId = 3, ParentId = 2
ArtikelId = 4, ParentId = 2
SubpageId = 5
ContainerId = 6, ParentID = 5
ArtikelId = 7, ParentId = 6

Zo moeilijk is een dbmodel dus niet.

[alienfruit]

Thanks Gordijnstok
Zie me reactie boven ook trouwens.

[EfBe]

Mijn CMS, CESys, gebruikt containers, daarbinnen items met een itemtype, en items bestaan uit elements met een elementtype. Pages bestaan niet echt als object in het systeem, alleen als referentiekader op welke page welke containers geplaatst zijn. Elements zijn de kleinste bouwstenen, en je moet dan denken aan 'image', table, string, bullitlist etc. Per Itemtype-Elementtype combinatie heb je een element editor XSL en een Item editor XSL. (die dus de item/element data omzetten in een html page die dienst doet als editor). Per container-itemtype-elementtype combinatie heb je een viewer XSL voor het element en voor het item. Je kunt dus een item in verschillende containers hangen en dan dus ook verschillende viewers geven. Containers zijn in feite gedeelten van pages waar 'content management functionaliteit' gewenst is. Je kunt containers ook aan meerdere pages toevoegen, bv een 'news headlines' container die newsitems bevat en ze toont als headlines'.

Een van de grote voordelen hiervan is: je hoeft content-onderdelen maar 1 keer in te geven, je kunt daarna die onderdelen plaatsen in de containers naar keuze (waar je dat soort items kunt toevoegen). Items zijn verder verbonden dmv categories, dus je kunt een category definieren en daarmee meerdere items groeperen.

Je hebt dus meta-definities nodig, itemtypes en elementtypes, en daarmee bouw je zeg maar definities voor items die de contenteditors gaan toevoegen. Super flexibel en nauwelijks meer werk dan de page/vaste layout met items benadering.

[ Voor 9% gewijzigd door EfBe op 06-04-2003 21:38 ]

[alienfruit]

Aah. Klinkt goed Efbe

Ik heb zelf al een simpele xml structuur bedacht hoe ik de content (tekst) op ga slaan in de database, niet een html waar in XML met eigen tags (als <mediatype>, <paragraph>, <bold>) e.d. zodat je dezelfde content ook gemakkelijk kunt gebruiken voor Vodafone Live! en/of voor het generen van PDF-bestanden.

Leuke is dat Office 2003 ook XML-ondersteuning heeft, kan de eindgebruiker gewoon de content in Word typen; zonder dat je met VBA macro's aan de slag moet.

[Verwijderd]

Lol.. ik ben vandaag ook gestart met een nieuw cms project... volledig gebaseerd op XML en DELPHI... ong zoiets als CESys... Ik was van plan om word in een soort ole container te laten draaien.. zodat dat allemaal bij elkaar in 1 delphi app zit... ik wil dus net als CESys een Builder en een Manager maken... moek nog ff over na denken... maar bij de manager .. ik ga even denken of ik het wel met WORD ga doen . omdat dat niet lekker werkt.... wanneer gebruikt een eindgebruiker nu b.v. tabellen oid? Ik denk dat ik het gewoon met plaintekst ga doen.. en dan gewoon met <bold> enz zoals alienfruit zei.

Dan gewoon intern dus <bold> gebruiken en als ik html output wil <bold> omzetten naar <B> ... bij pdf omzetten naar BOLD.. en bij gewone XML output nix mee doen..

Ik heb namelijk sinds kort de kracht van XML ontdekt

[Verwijderd]

EfBe schreef op 06 April 2003 @ 21:37:....hap...

Wat ik niet snap zijn die item-types..

die Bulletin, strng enz enz dingen.. kan je dat eens uitleggen.. ik snap het nut daar niet zo van?

[Verwijderd]

Het CeSys principe is me niet vreemd. Sterker nog, zonder afbraak te willen doen aan CeSys, is dit een principe dat eigenlijk door het grootste gedeelte generieke CMS systemen wordt gebruikt. Het is technisch gezien een solide methode om je data te groeperen.

Nadeel alleen is, dat mensen die met een dergelijke methodiek moeten werken het systeem gewoon niet snappen. Ze snappen het principe van containers niet.

[dusty]

Topic titel veranderd op verzoek van Gordijnstok.

[Verwijderd]

Verwijderd schreef op 06 April 2003 @ 22:18:
Het CeSys principe is me niet vreemd. Sterker nog, zonder afbraak te willen doen aan CeSys, is dit een principe dat eigenlijk door het grootste gedeelte generieke CMS systemen wordt gebruikt. Het is technisch gezien een solide methode om je data te groeperen.

Nadeel alleen is, dat mensen die met een dergelijke methodiek moeten werken het systeem gewoon niet snappen. Ze snappen het principe van containers niet.

hmm.. ik (en vele andere programmeurs) snappen dat gewoon niet: Waarom snappen de mensen het niet ... Dit kan toch mooi worden uitgelegd..

Zo van.. Thuis heb je ook 3 containers.. Eentje voor gft afval, eentje voor grijs afval, en eentje voor papier (niet iedereen).... Zo werkt het ook met containers.. In deze container (container 1 b.v.) plaats je alle nieuws berichten.. in container 2 plaats je een kleine inleiding, en in container 3 het hele bericht... dan moeten ze het toch wel een keer snappen..

ik zou echt niet weten op welke manier je dit beter kan aanpakken... (dus geen container systeem, maar iets anders, wat ze wel snappen)

offtopic:
Verder is dit wel leuk topic.... Hopelijk komen er wat meer replys

[EfBe]

Die containers snappen ze veelal wel hoor. Ze weten dat ze bv een 'nieuwsbericht' willen toevoegen, dat ze dan naar die page en de container 'nieuws' moeten gaan en daar een 'nieuwsitem' moeten toevoegen. Een goed CMS voegt dan dat item aan alle containers toe waar het item in moet komen, bv in de headers container bovenaan de page en bv ook een 'laatste nieuws' container op de frontpage. Maar je moet het contentbeheerders wel eerst uitleggen dat klopt, maar dat is bij alle mogelijke cms structuren zo. Veel contentbeheerders weten wel wat van internet maar soms weten ze niet eens wat een link is, ga dat dan maar uitleggen

ItemType is bv 'nieuwsitemmetplaatjetype'. Dat bestaat bv uit een string (kopje), textblock (body) en een image (plaatje bij nieuwsitem). Omdat je met elements werkt kun je als bouwer alle mogelijke itemtypes samenstellen, dat is het mooie van deze opzet.

Veel CMS'en gebruiken een dergelijke opzet, vandaar dat ik hem ook noemde. Je ziet dat items nog wel eens een andere naam hebben, bv 'articles', of dat er een abstractielaag bovenop items geplaatst is die article genoemd wordt en als unit fungeert die in containers geplaatst wordt. Dit laatste is eigenlijk te prefereren, dus als je een opzet overdenkt van een CMS, neem dat absoluut mee.

De transitie van container naar pagina is voor sommige mensen wat groot, maar ik heb zelf het gevoel dat de contentbeheerders daar minder moeite mee hebben dan developers, omdat developers door de jaren heen totaal op pagina's gefocussed zijn en contentbeheerders meer op content, en waar dat te plaatsen. Dit is ook de reden waarom sommige developers een CMS bouwen rondom de 'page'. Iets wat al gauw op gaat breken omdat je op een bepaalde page telkens wat anders toont, wat dan? (bv een artikelen page, waar je 1 artikel per keer toont). Containers bieden dan een uitkomst, een beetje 'pages' in een page.

[alienfruit]

Hoe sla je dit allemaal op Efbe?
Verschillende tabellen itemtype, container en pagina en die dan dmv. van een linktabel gekoppeld wordt

[EfBe]

elements hebben aparte tables (per elementtype), want per elementtype heb je meer of minder gegevens op te slaan (image vs string bv). Itemtype heeft aparte tabel, itemtype-elementtype (koppel tabel), Items hebben aparte tabel, Elements hebben aparte tabel, ItemElements (koppel tabel), containers aparte tabel, container-items tabel (koppel tabel), pages aparte tabel, pages-containers (koppel tabel). En nog een aantal voor de XSL templates etc. Zo moeilijk is het niet hoor. Redeneer gewoon wat aan een item hangt, dmv een ORM model, dan kom je vanzelf op een redelijk model voor een CMS.

[Verwijderd]

Kun je dan niet beter 2 tabellen aanmaken, nl. de elementen, en de properties. De properties geef je dan het id van het element mee.

[EfBe]

Zou kunnen, maar in de praktijk liggen die properties van een element redelijk vast, een plaatje zal altijd een zekere set properties bevatten en wordt nooit een string. Het nadeel van een tabel met properties die je weer moet interpreteren in code is dat je nogal wat extra code kwijt bent om bv alle data van een element uit de database te trekken (extra join plus interpret code hogerop in de tier-stack). Het is altijd een afweging tussen flexibiliteit en gemak. Hoe meer gemak hoe inflexibeler de code en vice versa.

[ Voor 13% gewijzigd door EfBe op 07-04-2003 13:31 ]

[alienfruit]

Aah.
Cool Efbe. Ik ben zelf nog druk bezig met het door worstelen van database systems boek van Thomas Connolly et al.

[ Voor 74% gewijzigd door alienfruit op 07-04-2003 13:31 ]

[Verwijderd]

Verwijderd schreef op 07 April 2003 @ 07:40:
[...]

hmm.. ik (en vele andere programmeurs) snappen dat gewoon niet: Waarom snappen de mensen het niet ... Dit kan toch mooi worden uitgelegd..

Zo van.. Thuis heb je ook 3 containers.. Eentje voor gft afval, eentje voor grijs afval, en eentje voor papier (niet iedereen).... Zo werkt het ook met containers.. In deze container (container 1 b.v.) plaats je alle nieuws berichten.. in container 2 plaats je een kleine inleiding, en in container 3 het hele bericht... dan moeten ze het toch wel een keer snappen..

ik zou echt niet weten op welke manier je dit beter kan aanpakken... (dus geen container systeem, maar iets anders, wat ze wel snappen)

Agree, maar waarom zou je de gebruiker iets van containers moeten laten snappen.
Zorg gewoon dat je systeem met containers werkt, en dat de gebruiker daar niets van merkt.

Dan heb je:
1: Een duidelijke opslagstructuur voor je data.
2: Een systeem dat gebruikers begrijpen.