Beste,

Ik ben op dit moment bezig met een project waarbij modulair scripten een handige extra zou zijn, dit omdat bepaalde modules van de website pas in een later stadium gescript worden maar de templates wel al 100% in orde zijn.

Bij modules denk ik aan stukken PHP code die je aan/uit kunt schakelen middels een administratiepaneel om zo bepaalde gedeelten van je website (tijdelijk) uit te zetten. Ook het overzetten van programmatuur naar een andere site zou zo gemakkelijker gemaakt kunnen worden, doordat je (bijvoorbeeld) unieke modules uit kunt schakelen (en uiteraard ook de bijhorende classes niet hoeft up te loaden).

Echter, bij dit project zal veelvuldig gebruik worden gemaakt van de database, en naar alle waarschijnlijkheid zullen ook de tabellen flink vol staan na verloop van tijd, dus een snel systeem voor deze modules is een noodzaak. Ik heb in feite twee kleine opzetjes in mijn hoofd zitten, namelijk de volgende:

Opzet 1: variabelen in de config
In de config.inc.php zetten we een aantal variabelen die aangeven of een module aan/uit staat, dit bestand zou bijvoorbeeld zo kunnen uitzien:

PHP Code:

<?php

$modStatus['ledenlijst'] = 1;
$modStatus['profiel'] = 1;
$modStatus['nieuws'] = 0; // uitgeschakeld wegens werkzaamheden

?>

Aan de hand van een simpele controle van de waarde van deze vars worden modules aan en uitgeschakeld, echter is dit niet echt gebruikersvriendelijk gezien het feit dat je via de FTP het bestand moet updaten op het moment dat een module uitgezet wordt.

Opzet 2: Database gebruiken (aanpassen via online administratiepaneel)
Om dit op te lossen zat ik te denken aan een modulesysteem via een mySQL database. De opzet van de tabel:

modules
id int(4)
naam varchar(100)
beschrijving TEXT
status int(1)

Deze tabel laten we in de include.inc.php pagina, welke op elke pagina geladen wordt, uitlezen en voor elke record in de database laten we de variabele: $modStatus[naam], de waarde uit het veld 'status' krijgen.

Echter is mijn vraag nu, zal deze manier de db-load zodanig verhogen dat het een probleem wordt uiteindelijk bij een druk bezochte website? Er zullen toch flink wat records in deze tabel komen te staan aangezien elke pagina wordt opgedeeld in stukjes, zo heb je op de homepagina de volgende modules (voorbeelden):

Headlines
Nieuwsitems
Online leden

Wanneer we dan 50 paginas op de website hebben met elk zo'n 3/4 modules zitten we toch al snel op een record of 200 wat op elke pagina weer uitgelezen wordt.

Als ik moment een foute opzet heb gemaakt om modulair te werk te gaan hoor ik dit natuurlijk graag. Ik sta open voor commentaar, verbeteringen of compleet nieuwe ideeën :)

Alvast bedankt!

Of een combinatie hierin vinden natuurlijk.

Via de backend de gegevens aan kunnen passen, en dan middels PHP het bestand van methode 1 laten aanpassen.

In dat geval heb je enkel de load in de backend (niet merkbaar voor gebruikers) en het simpele gebruik van een include in de frontend.

Maar nogmaals, ideeen, verbeteringen e.d zijn welkom.

Dit is ook iets wat ik me al een hele tijd afvraag, maar ik was ook eender in de richting van een db aan het kijken. Want mensen zelf pagina's gaan laten aanpassen zint me niet zozeer, een config bij de install hoogstens, maar daar moet het dan bij blijven.

Verder stel ik me de vraag of die queries wel zo enorm zwaar gaan doorwegen...

Daar zat in ook al aan te denken, ik betwijfel of de load dermate wordt verhoofd door één enkele query toe te voegen. Een tabel tot 250 records moet toch nog op vrij hoge snelheid uit te lezen zijn wanneer je een goede server tot je beschikking hebt.

En één query bovenop 20 andere zou het verschil niet meer maken. Maar dan nog,.. de 3e optie (de combinatie van de twee methodes in de startpost) zou misschien sowieso het beste zijn als dit goed te realiseren is, het is niet de bedoeling natuurlijk dat je, wanneer je een error krijgt, het bestand leeggelaten wordt en geen enkele module meer geladen wordt op de website, dan moet je als bedrijf zijnde alsnog in gaan springen op een bepaald moment.

Mijn eigen persoonlijke voorkeur gaat dan toch uit naar het database systeem (methode 2).

Origineel gepost door Joshua de Gier

Mijn eigen persoonlijke voorkeur gaat dan toch uit naar het database systeem (methode 2).

Mits juiste controles kan dit wel een redelijk failproof systeem vormen. Bij het ontwikkelen voor anderen ga ik er altijd vanuit dat een aap in principe foutloos moet kunnen werken met het systeem (a la microsoft filosofie ;) ).

Maar denk dat je met de DB de veiligste en voor de users het simpelste systeem hebt.

Weet het wel zeker, heb afgelopen nacht wat onderzoek gedaan naar het verkleinen van de databaseload, het verminderen van het queries en het optimaliseren ervan en methodes om dit alles in een keer te realiseren.

één erg interessante methode voor mij was die om bepaalde paginas binnen je system automatisch te laten 'cachen' op je server. Dus de content als het ware opslaan in een statisch bestand en deze simpelweg includen waar dit nodig is. Voor bijvoorbeeld een index pagina met daarom 10 nieuws berichten is dit ideaal. Telkens als je een nieuwe bericht plaatst laat je de server het bestand opnieuw inladen (templateparser bijv.) en outputten als, ik noem maar wat, een .html bestand wat je vervolgens include.

Als controle kun je in je systeem een timestamp toevoegen bij je nieuwsbericht en een check-tabel met daarin de timestamp wanneer de page het laatste is geupdate. Wanneer deze 2 verschillen laat je de server de pagina alsnog een keer opnieuw cachen.

Maar deze methoden zijn eigenlijk enkel van toepassing als je echt veel dbload op je server hebt of wanneer je server erg traag verloopt. Zover ik las moeten paginas tot 100 queries nog erg vlug te handelen zijn, zelfs voor servers van een aantal generaties geleden :)

Als testje heb ik vanmiddag op een snelle server via PHPmyAdmin eens een query uitgevoerd die 45k rijen betrof (DELETE-query). Deze duurde minder dan één seconde (0,9xx) om uit te voeren. We kunnen er toch wel vanuit gaan dat wanneer je je queries goed optimaliseert (goede WHERE-clause en gebruik van LIMIT) dat je met gemak je queries binnen de seconde kunt laten uitvoeren op je pagina :)

Valt me overigens tegen dat er maar weinig reacties komen op dit onderwerp, wat toch een leuke feature is voor je eigen scripts om te gebruiken. Wat me dan weer wel opvalt is dat ik PMs krijg dat ik mezelf niet zo hoog moet inschatten kwa PHP als ik 'nieteens modulair kan scripten' ;)

lol, wat voor asociale mensen zijn dat nu weer :s? Als ze even interessant willen doen kunnen ze dat ook gerust hier hoor.

Modulair scripten wordt in php niet zo veel heel gebruikt, dat is meer iets voor de echte programmeertalen als Java, c++ en consoorten.

Trouwens Joshua, heb je toevallig een link waar je al die info hebt gehaald? Zou nice zijn.

Origineel gepost door Glenn Veugen

lol, wat voor asociale mensen zijn dat nu weer :s? Als ze even interessant willen doen kunnen ze dat ook gerust hier hoor.

Modulair scripten wordt in php niet zo veel heel gebruikt, dat is meer iets voor de echte programmeertalen als Java, c++ en consoorten.

Trouwens Joshua, heb je toevallig een link waar je al die info hebt gehaald? Zou nice zijn.

Mensen die snappen dat discussies aangaan in een topic zonde van 't forum is? Dat schreeuwen je collega's overigens wel continu. Ik zag dat Joshua zichzelf een 4.8/5 gaf voor PHP, maar heb hier toch de simpelste vragen van Joshua langs zien komen dat ik denk: "Klopt dat wel helemaal?". Daar maakte ik per PM een opmerking over, en Joshua heeft mij duidelijk gemaakt wat zijn kunsten zijn. Hiermee was de discussie afgesloten, dus opnieuw beginnen voegt imo geen waarde toe.

Wat me dan weer wel opvalt is dat ik PMs krijg dat ik mezelf niet zo hoog moet inschatten kwa PHP als ik 'nieteens modulair kan scripten' ;)

Zoals je het nu zegt heb ik het nooit verwoord volgens mij Joshua. ;) Ik vond dat die 4.8/5 enigszinds onterecht was, maar als jij vindt dat dat je niveau is moet je dat lekker laten staan (heb ik ook gezegd).
Weet niet of het aan mij ligt, maar 't komt allemaal redelijk aanvallend op mij over. Geen idee waar dat voor nodig is, want ik heb nooit de bedoeling gehad iemand de kwetsen / beledigen?

Martijn, volgens mij is zijn vraag niet echt PHP gericht maar MySQL gericht. Daarom kan Joshua jou PM toch ietswat aanvallend aanzien.

Een jaar geleden had ik het idee om ook een uitgebreide, modulaire CMS te ontwikkelen, ik had voor mezelf een documentje gemaakt met al mijn ideeën en "visies" dat zo'n 30 pagina's groot was. Toen ik er uiteindelijk aan begon had ik het té druk met andere projecten, een eigen CMS is natuurlijk leuk, maar je verdient er niets mee tijdens de ontwikkeling :)

In ieder geval, het cachen van pagina's naar HTML was ook iets wat bij in mijn document stond. Waarom? Omdat zeer veel druk bezochte websites dit doen zoals bijvoorbeeld NBA. Mijn idee was om enkel de CMS te gebruiken om data in een database te zetten. Je haalt als admin dus de inhoud van een pagina uit de database, en als je die aanpast past de CMS die aan in de database maar maakt ook een nieuw HTML bestand aan op basis van een template. Na er vele uren over te hebben nagedacht brengt dit echter wat nadelen met zich mee

• Nieuwe layout of aanpassing aan een sjabloon wil zeggen dat alle pagina's aangepast moeten worden (wat bij zeer grote websites waarschijnlijk een heel groot probleem is)
• Dynamische content in zo'n pagina's is ook niet evident. Neem bijvoorbeeld de laatste 10 nieuwsitems, hoe ga je die in een HTML document zetten? Als je als 5000 html pagina's hebt en die telkens aangepast moeten worden als er een nieuwsitem is toegevoegd gaat dit natuurlijk veel tijd kosten. Er zijn natuurlijk oplossingen om dit te doen maar dit leek me veel te omslachtig.
• Het neemt natuurlijk in het algemeen veel meer tijd in beslag om zo'n systeem in elkaar te steken dan een website waar de front-end rechtstreeks aan een database gekoppeld is.

Ik kwam dan ook tot besluit dan zo'n systeem misschien best op maat te maken was. Als ik ooit een klant tegenkom die echt een website wil die tienduizenden bezoekers per dag gaat trekken, dan gaat zo'n systeem van pas komen. Maar in het algemeen zal het allemaal zeker wel vlot blijven werken als je op een efficiënte manier rechtstreeks met de database werkt in de front-end.

Wanneer we dan 50 paginas op de website hebben met elk zo'n 3/4 modules zitten we toch al snel op een record of 200 wat op elke pagina weer uitgelezen wordt.

kun je dit wat verduidelijken want volgens mij maak je hier een denkfout of zet je het wat knullig neer.

Ja ik begreep m zelf al even niet meer :P

Als we nu in op elke pagina die we hebben 4 modules hebben steken die we aan of uit kunnen zetten via de database, en je hebt zo'n 50 paginas op je website dan zijn er 50*4 = 200 modules.

De querie om dat de moduleStatussen op te halen gaat dan door 200 records extra per pagina heen om ze telkens voor je uit de database te halen in de include.inc.php file.

Nu zal deze ene querie niets uitmaken of in elk geval geen merkbaar verschil voor de eindegebruiker opleveren. Maar wanneer je in het geheel denkt en je hebt echt veel queries op je pagina zou dit een query zijn die je op een andere methode zou kunnen doen (een include file met daarin de waardes bijv zoals ik al zei).

Maar ik weet ondertussen al dat dit via de database gewoon te doen is, zoveel queries verwacht ik toch niet op de website :)

is een module op een pagina echt verschillend?
bv laatste nieuws module,

als ik die op home zet of op contact pagina, dat is toch 1 module?


dus dan heb je wel 200 mogelijkheden, maar geen 200 records per per pagina :)


sterker nog:

table: modulecoupling
rows: modcoupling_id, module_id, page_id

gooi er even wat PK's en FK's op en dat gaat echt snel hoor :)

stel je hebt 4 modules op 1 pagina:

queries:
1) content ed ophalen voor page_id
2) join met modulecoupling, module_table

3) etc ) alle queries die voor een module nodig zijn.

Kijk,.. naar zoiets was ik aan het zoeken. Normaal ben ik altijd de eerste wat met een koppeltabel komt en nu vergat ik het gewoon :D Dat beperkt de resultaten met een LIMIT inderdaad tot max 5 records.

Dat er in totaal geen 200 modules zijn is ook waar, uiteraard zullen bepaalde boxes op meerdere paginas geladen worden, die hoeven dan sowieso ook niet dubbel in de database :)