CMS modules, hooks inbouwen?

[Blaise]

Ik ben bezig met een redelijk eenvoudig CMS voor particulieren en MKB, in PHP en SQL.

Een eerste versie was gesneuveld omdat ik niet goed had nagedacht over globale variabelen, caching en integratie van modules. Voor deze tweede versie heb ik nog nauwelijks echt gecode, het gaat dus vooral om problemen op papier en in mijn hoofd.

De situatie:

Alle pagina's komen uit op index.php. In mijn database, in een referentie tabel, houd ik bij welke module moet worden gebruikt bij welke url.

De modules hebben elk hun eigen map, met daarin een setup bestand, settings, benodigde klassen, functies, templates, etc. Met PHP lees ik de map met modulemappen uit.

Het probleem is dat sommige modules paginaonafhankelijk zijn (bijv. webstats). Mij lijkt het inbouwen van hooks een oplossing. Een module kan aangeven of deze altijd moet worden uitgevoerd op verschillende momenten in de opbouw van een pagina.

Drie momenten die mij handig lijken zijn:

1. Voordat aan de paginaopbouw wordt begonnen
2. Na de paginaopbouw maar voor de output
3. Na de output

Mijn vraag is of dit een nette en slimme oplossing is. Zijn er alternatieven, of dingen die ik over het hoofd zie?

Een andere kwestie is het combineren van modules. Ik kan me voorstellen dat als ik het CMS steeds verder uitbreid, er de mogelijkheid moet zijn om bepaalde modules te combineren. Bijvoorbeeld door het toevoegen van een poll toe aan een tekstpagina, of de mogelijkheid voor bezoekers om reacties toe te voegen aan een tekstpagina. De paginamodule (voor simpele tekstpagina's zonder interactie) moet dan andere modules laden.

Ik zit erover te denken van de paginamodule een "containermodule" te maken; een module waar je andere modules aan kan toevoegen. Modules kunnen dan aangeven of ze toegevoegd kunnen worden aan de containermodule. In de tabel van de paginamodule moet dan nog worden aangegeven welke submodules moeten worden geladen met welke content-ID, zodat in de backend een poll met ID 12 kan worden toegevoegd aan de container.

Is deze opbouw handig en future-proof? Of kan ik het beste gelijk van alle modules een containermodule maken? Het lijkt me overkill, maar soms is overkill beter dan jezelf vooraf al te beperken. En een CMS kan je oneindig groot maken, dus wellicht is het slim om nu een aantal grenzen te stellen (waar ik later ongetwijfeld spijt van ga krijgen )

Graag hoor ik hoe jullie erover denken.

[aex351]

En je maakt dit object georienteerd ? Want dan zou je bijvoorbeeld 1 module klas te kunnen hebben waarmee je die andere module klassen mee uitvoert. Bijvoorbeeld op een gegeven moment modulePrepare() in de module klas waarmee alle modules die je hebt toegevoegd aan die module klas op een één of andere manier naar keus opdrachten kan doorspelen. En dan wil je natuurlijk wel een aantal specifieke functies/methodes in zo'n klas hebben en dat doe je dan mbv interfaces.

[ Voor 13% gewijzigd door aex351 op 20-03-2007 01:32 ]

[JHS]

Ik zou het eerlijkgezegd enigzins raar vinden als een module x kan bepalen of hij wordt toegevoegd aan module y of niet . Ik zou die verantwoordelijkheid eerder bij module y leggen. Daarnaast zou je dan om die module heen een container-achtig iets kunnen leggen waarin je kan aangeven dat andere modules moeten worden uitgevoerd, voor- / nadat de normale module wordt uitgevoerd.

[Blaise]

En je maakt dit object georienteerd ? Want dan zou je bijvoorbeeld 1 module klas te kunnen hebben waarmee je die andere module klassen mee uitvoert. Bijvoorbeeld op een gegeven moment modulePrepare() in de module klas waarmee alle modules die je hebt toegevoegd aan die module klas op een één of andere manier naar keus opdrachten kan doorspelen. En dan wil je natuurlijk wel een aantal specifieke functies/methodes in zo'n klas hebben en dat doe je dan mbv interfaces.

Het is OO. Deze manier ga ik waarschijnlijk gebruiken, zat zelf ook al in die richting.

Wat is het nut van een Interface ten op zichte van gewoon standaard methods in een klasse? Is het voor de structuur en overzicht, zodat ik weet welke methods een klasse van een nieuwe module moet hebben, of heeft het nog andere functies?

Ik zou het eerlijkgezegd enigzins raar vinden als een module x kan bepalen of hij wordt toegevoegd aan module y of niet . Ik zou die verantwoordelijkheid eerder bij module y leggen.

Is het dan niet beter om de verantwoordelijkheid bij beiden te leggen? Een module moet weten of het submodules kan toevoegen èn of het zelf kan worden toegevoegd als submodule.

Daarnaast zou je dan om die module heen een container-achtig iets kunnen leggen waarin je kan aangeven dat andere modules moeten worden uitgevoerd, voor- / nadat de normale module wordt uitgevoerd.

Dat is inderdaad handig. Hier bedoel je toch wel vanuit module x? Anders moet ik per module dingen bijhouden en aanpassen buiten de module zelf, wat ik natuurlijk wil vermijden.