[PHP] OOP advies nodig

[Verwijderd]

Ik wil een best uitgebreid forum gaan schrijven in PHP. Ik wil erg op de snelheid van de scripts gaan letten. Nu vraag ik me af in hoevere Object Georienteerd programmeren ten koste gaat van de snelheid.

Ik heb wat opensource forums bekeken, maar deze zijn geen van allen OOP gemaakt. Is dit omdat OOP het zoveel trager maakt? Ik kan zoieso geen grote open source applicaties vinden die voor veel gebruikers geschikt zijn en ook nog eens OOP zijn. Is dit forum bijvoorbeeld OO geprogrammeerd?

Kortom, ik zou wat advies en ervaringen willen horen van wat mensen die grotere php applicaties met behulp van OOP hebben geschreven.

[Maxonic]

Een test bij het GPL forum XMB heeft eens uitgewezen dat een OOP forum zo'n 12% langzamer was dan hetzelfde forum dat niet OOP is opgezet. In hoeverre deze cijfers de werkelijke achteruitgang vertegenwoordigen is niet te zeggen. Ook was dat nog een PHP versie terug en de laatste tijd is PHP flink aan de weg aan het timmeren op OOP gebied. Echter, als je een goed forum wilt opzetten is OOP in deze tijd bijna wel een musthave. (en dan heb ik het over een echt goed forum dat je met modules uit kan breiden, waar je de BB-Parser zo kan vervangen enz.)
Het KAN het forum een stuk compacter maken == minder code te parsen == sneller.
Echter moet je goed op het cachen van diverse akties leten. Het is wel heelleuk om van iedere post/user een object te maken maar of het effectief is in de zin van het programma is een tweede.
Zelf ben ik ook al 3 jaar met een (naar mijn mening) zeer innovatief forum bezig en ik heb er spijt van dat ik niet van het begin af aan alles OOP heb opgesteld.
De toekomst zit er volgens mij ook in PHP in dus ik zou het gewoon doen.

[ACM]

Dit forum is idd dmv OO opgezet.

't Nadeel van OO in php is dat het nog niet helemaal goed uitgewerkt is, itt java of python.
Echter wordt de snelheid vooral bepaald door de mate waarin queries uitgevoerd en afgehandeld kunnen worden en in mindere mate van de executietijd van de software zelf.

Met het sneller worden van cpu's wordt het ook minder relevant om de snelheid als primair doel te hebben, je kan beter onderhoudbaarheid en eenvoud van programmeren als doel aanhouden en dan de snelheid in je achterhoofd houden

Maar ja, over het algemeen zal een OO-versie van een project wat slomer zijn in pure executietijd dan een non-OO-versie.
Zelf bouw ik vrijwel alles dmv OO in php, simpelweg omdat het daardoor allemaal wat aantrekkelijker onder te verdelen is en de functionaliteit wat mooier uitgesplitst kan worden.

[Verwijderd]

Met het sneller worden van cpu's wordt het ook minder relevant om de snelheid als primair doel te hebben, je kan beter onderhoudbaarheid en eenvoud van programmeren als doel aanhouden en dan de snelheid in je achterhoofd houden

Dat is idd een goed argument om voor OO te kiezen. :-)

[Apache]

Het idee was om mijn eindwerk van vorig jaar, wat ook een forum was volledig in OO te bouwen, maar na wat benchmarks merkte ik dat pass by reference in PHP serieuze performance hits bleek in te houden dus is er een soort van hybrid versie ontstaan.

Als je nu begint te ontwikkelen zou ik meteen voor PHP5 gaan omdat OOP daarin gewoon werkt zoals hij in andere talen werkt en je dus ook geen rare constructies moet gaan bouwen. T'is zeker stabiel genoeg om nu al in te developpen, af en toe loop je tegen wat bugs maar die kan je dan meteen reporten zodat de final van PHP5 ook meteen minder bugs bevat.

[whoami]

Zoals ACM al zei, zal je vooral op je queries moeten letten. Een forum moet nl. vooral data uit de DB halen, erin steken, etc....

Als een database slecht opgezet is, of je verkeerde indexen legt, kan dat een serieuze performance-hit veroorzaken; één die veel groter zal blijken te zijn dan de performance die je verliest met een OO opgezet systeem. (OO heeft dan wel een aantal voordelen die imho zwaar opwegen tov het eventuele performance verlies).

Ter illustratie: ik was vandaag bezig een query te schrijven die data uit verschillende tables haalde. Een van de tabellen bevat zo'n 500.000 records.
Die query duurde 17 sec. Da's natuurlijk veel te lang. Ik had de indexen eens bekeken, en er lag een composite index op die tabel op (veld1, veld2).
Door die index te veranderen naar (veld2, veld1), duurde m'n query ipv 17sec 0.02 seconden.

[chem]

Waar je in PHP vooral winst uit haalt, is slim omgaan met strings, arrays en andere oh-zo-makkelijke features. Zo is het concatten van 2 strings sneller door een output buffer te maken, de boel 2x te echo'en, de outputbuffer te sluiten en de inhoud in de nieuwe string te zetten. Dat is sneller dan $string = $string1 . $string2;

Ook array merge's, by reference passing etc. zijn zaken waar je goed op moet letten.

Dit even naast het OOP verhaal

[Maxonic]

Dit topic laat een vraag bij mij rijzen...
Bestaat er een boek/webpage waar je echt effectief php/mysql kan leren.
Wat zijn zo'n beetje de basisprinciepes?
Ik denk dat ik de zaak wel redelijk snap maar uit de honderden manieren die je kan gebruiken voor een bepaald stukje code kies ik er altijd maar op de bonne fooi eentje...
Ook denk ik dat er wel meerdere mensen zijn die een beetje aanhobbyen maar door gebrek aan die kennis niet efficiënt coden.

[Grijze Vos]

PHP is nogal een 'iedereen-kan-het-leren' taaltje Max. Ik denk niet dat er echt serieuze ondernemingen zijn gedaan door mensen om 'netjes' te programmeren, en daar een website over op te zetten. (Kan me natuurlijk vergissen.)

[Verwijderd]

chem schreef op 16 September 2003 @ 13:52:
Waar je in PHP vooral winst uit haalt, is slim omgaan met strings, arrays en andere oh-zo-makkelijke features. Zo is het concatten van 2 strings sneller door een output buffer te maken, de boel 2x te echo'en, de outputbuffer te sluiten en de inhoud in de nieuwe string te zetten. Dat is sneller dan $string = $string1 . $string2;

Ook array merge's, by reference passing etc. zijn zaken waar je goed op moet letten.

Dit even naast het OOP verhaal

Bedoel je hier het gebruik van sprintf? Anders snap ik je verhaal niet helemaal...

Het zou erg handig zijn als je hier wat voorbeelden over zou kunnen geven, ook over array's etc. aangezien dit zaken zijn die ik best vaak gebruik en die dus schijnbaar sneller kunnen.

[crisp]

Grijze Vos schreef op 17 September 2003 @ 02:55:
PHP is nogal een 'iedereen-kan-het-leren' taaltje Max. Ik denk niet dat er echt serieuze ondernemingen zijn gedaan door mensen om 'netjes' te programmeren, en daar een website over op te zetten. (Kan me natuurlijk vergissen.)

Volgens mij staat er wel een stukje over in de FAQ hoor

Verder zie ik 'netjes' programmeren als 'efficient', en als zodanig maakt het weinig uit in welke taal je programmeert. De richtlijnen zijn meestal wel hetzelfde.
Op het moment dat je echt voor performance gaat optimalizeren kan je vaak wel wat taal-specifieke truuken gaan uithalen, maar meestal wordt een programma daar niet netter van.

Zoals Grijze Vos al aangeeft wordt PHP voornamelijk gebruikt als instap-taal door beginnende webprogrammeurs. Als zodanig zie je inderdaad veel voorbeelden waar de haren van een doorgewinterde programmeur van overeind gaan staan. Dat wil echter niet zeggen dat je niet netjes kan programmeren in PHP, echter zijn die voorbeelden schaarser.

[Verwijderd]

Misschien niet helemaal ontopic, maar het OO gedeelte van PHP vind ik geen OO te noemen, Je kunt inderdaad klasses maken maar er is geen sprake van de mogelijkheid tot het declareren van private / public / static variabelen, klasses of methodes, je kunt geen abstracte klasses / methodes maken en meer onderdelen die OO de kracht geven dat OO heeft.

Als je inderdaad een forum wilt bouwen dat je nog verder wilt ontwikkelen in de komende jaren dan zou ik voor het OO principe gaan omdat je functionaliteit dan netjes kunt scheiden en alles (of althans een groot deel) modulair kunt opbouwen.

[ACM]

Het is, imho, OOP.

Ongeacht of je wel of geen datahiding hebt en of je wel of geen static en abstracte zaken hebt.
Dus laat dat ajb even achterwege

[Verwijderd]

Ik ben nu aan het modeleren geslagen, maar ik zit nu nog wel met een boel twijfels...
Ik kan kan 4 grote klassen onderscheiden denk ik: forumcategorie, forum, topic, bericht. (Gebruikers enzo even achterwege gelaten) Maar dat betekent dat ik op de verschillende pagina's best veel instantie's van die klassen moet gaan maken. Zo moet de index pagina instanties hebben van alle categorien en alle forums.

Ook moet een 'viewtopic' pagina instantie's hebben van de klasse 'bericht' maar dat kunnen er dus best wel veel zijn. Al deze klasse worden naar mijn mening best groot (veel code) en dus worden die instantie's ook best groot. Dit lijkt me best wel ten koste te gaan van de snelheid.

Zou het beter zijn om van al deze klasse een 'light' versie te maken die bij overzichtspagina's enzo gebruikt wordt? Of kan ik beter niet werken met klasses als 'forum' en 'bericht' maar gewoon een klasse als 'viewtopic'? (lijkt me beetje onlogisch en niet helemaal volgens OO principe)

[whoami]

Waarom denk je dat je voor je overzichtspagina voor iedere categorie een object nodig gaat gaan hebben?

[Verwijderd]

Nou, als voorbeeld even GoT. Daar staan een boel categorien op de index pagina. Lijkt me dat dat allemaal objecten zijn, want bij een aantal categorie'en wordt bijvoorbeeld gecontroleerd of de gebruiker toegang heeft om die te zien. Ook wordt bij elke categorie de forums bijgezocht. Lijkt me dus dat iedere categorie een object is... Tenminste, zo zou ik het maken als het OO moest zijn.

Of sla ik de plank nou helemaal mis?

[terrapin]

Ja.. jij beschrijft meer het relationele database ontwerp

[whoami]

Ik zou het zo niet doen.

Wat is het nut ervan als je voor iedere categorie die je ziet, een object in memory hebt? Vergeet trouwens niet dat die objecten niet op jouw pc in het geheugen zullen gehouden worden, maar op de server. Als er 100 users met op je forum zitten, en iedere user ziet 10 categorieën, dan heb je al 1000 objecten in het geheugen van de server zitten, en wat ben je er mee?

Ik zou bv. gewoon een class Categorie hebben, die een static method GetCategories heeft, en die method gaat voor een bepaald userid de categorieën gaan ophalen waar die user toegang toe heeft.
Die categoriën ga je dan in je presentatie-laag outputten aan de gebruiker.

[Verwijderd]

terrapin schreef op 17 September 2003 @ 14:13:
Ja.. jij beschrijft meer het relationele database ontwerp

Mja, dan komt dat niet helemaal duidelijk over misschien want dat is niet de bedoeling. Hoe stel jij de klassen dan voor? Kritiek geven is makkelijk, een oplossing geven is moeilijker

[whoami]

Om nog even verder te brouwen op m'n eerdere post:

IMHO hoef je enkel een object 'in memory' te houden als er werkelijk iets met die data gedaan wordt.

Stel bv. dat jij een post gaat editten, of een nieuwe post gaat maken, dan kan je een instantie maken van de class 'Posts' bv. In dat object ga je dan de nodige informatie opvullen (bv oa de tekst die je op het forum wilt posten), en dan kan je een 'Save' method van dat object aanroepen die de gegevens in de DB gaat gaan saven.

Je object wordt dus pas gemaakt en geladen op het moment dat jij op het edit-knopje klikt. Het is gewoon onnodig, en verspilling van resources om voor iedere post die je ziet in een topic een object in memory te gaan houden.

[Verwijderd]

whoami schreef op 17 September 2003 @ 14:14:
--

Juist, dat dacht ik eerst ook. Maar dan krijg je het probleem dat die functie getCategories toch een soort van object zal moeten teruggeven. Want een Categorie bestaat niet alleen uit een titel ofzo, maar ook uit een link.
En stel je zou dan een class Forum maken met getForums. Deze moet nog meer data teruggeven als titel, aantal posts, laatste post etc. Dat zal toch in een object moeten staan.

[whoami]

Verwijderd schreef op 17 September 2003 @ 14:25:
[...]

Juist, dat dacht ik eerst ook. Maar dan krijg je het probleem dat die functie getCategories toch een soort van object zal moeten teruggeven. Want een Categorie bestaat niet alleen uit een titel ofzo, maar ook uit een link.
En stel je zou dan een class Forum maken met getForums. Deze moet nog meer data teruggeven als titel, aantal posts, laatste post etc. Dat zal toch in een object moeten staan.

Je kan een collection van classes teruggeven, die je dan in je presentatie-laag verwerkt om de gewenste output op te bouwen.
Die objecten hoef je daarna niet meer in memory te houden.

[Verwijderd]

Wat bedoel je met een 'collection van classes'? Een array met daarin objecten ofzo? Een andere manier kan ik niet verzinnen namenlijk..

[Maxonic]

Ja, dat kan. Zo heb ik het in mijn forum wel gedaan.

Ik gebruik in mijn forum btw nog meer classes. De BB-Parser is er één, het gedeelte dat voor de interaktie met de database zorgt, het templatesysteem en de eventuele ingelogde gebruiker.
Van deze classes wordt echter maar één instantie per pagina gemaakt.
Daarnaast heb ik ook een forum, topic en bericht als objecten.
Het taalsysteem en themasysteem moet ik nog een keer opnieuw opzetten.
De pagina viewtopic bestaat bijvoorbeeld uit 2 loops. 1 die dmv de instantie van het databasesysteem berichten uit de database trekt en deze in een array zet. (elk bericht is 1 instantie, de array bevat dus objecten)
De andere loop maakt gebruik van het templatesysteem en deze vult de templates dus één voor één in met de informatie uit de berichten array.

Daartussen gebeurt natuurlijk nog heel veer meer afhankelijk van de gebruikersinstellingen, foruminstellingen, themainstellingen, taalinstellingen enz enz.

misschien niet interessant maar misschien dat dit je op leuke ideen brengt.

[ Voor 5% gewijzigd door Maxonic op 17-09-2003 18:39 ]

[Verwijderd]

Ik heb vooral moeite met de 'scheiding' tussen objecten: stel je hebt een class Categorie en een class Forum, waar zet je de static (zie uitleg whoami!) functie die alle categoriën, inclusief de subfora, neerhaalt waar de gebruiker toegang tot heeft.

Je kan natuurlijk 2 functies maken, eentje voor de categoriën op te vragen (getCategories($userId)) en eentje voor de respectievelijke fora (getForums($categIds) waarbij $catgIds een array() van category-id's is), maar zulk opzet betekent ook 2 queries die eigenlijk perfect te combineren zijn in 1 query. Maar waar zet je die functie dan? Hij hoort eigenlijk zowel wel en niet in beide classen thuis?

Omdat ik aandacht wilt besteden aan het optimaal maken van sql queries (in dit geval overbodige queries vermijden), klopt de OO-strategie niet meer

edit: en eigenlijk is het dan nog altijd niet perfect OO: waarschijnlijk heb je ook een class User, voor allerlei functies die de gebruikers aangaan. Bij het ophalen van categoriën+fora ga je alleen die ophalen waartoe de gebruiker toegang heeft => je controleer zijn user-rights, dus eigenlijk zou je dat weer moeten opsplitsen naar de class User? Ja natuurlijk, dat kan allemaal, maar wel een query erbij!

Of zie ik perfecte OO gewoon verkeerd?

[ Voor 25% gewijzigd door Verwijderd op 18-09-2003 01:26 ]

[Brakkie]

Je kan natuurlijk 2 functies maken, eentje voor de categoriën op te vragen (getCategories($userId)) en eentje voor de respectievelijke fora (getForums($categIds) waarbij $catgIds een array() van category-id's is), maar zulk opzet betekent ook 2 queries die eigenlijk perfect te combineren zijn in 1 query. Maar waar zet je die functie dan? Hij hoort eigenlijk zowel wel en niet in beide classen thuis?

Het geheel waarbinnen categorieen en fora vallen kun je ook als een object zien. Verzin dr maar een mooie naam voor. Een klasse Board ofzo?

[Verwijderd]

Brakkie schreef op 18 september 2003 @ 09:48:
[...]


Het geheel waarbinnen categorieen en fora vallen kun je ook als een object zien. Verzin dr maar een mooie naam voor. Een klasse Board ofzo?

Ga jij nu echt voor elke functie die in pricipe 'tussen 2 classes thuishoort' een nieuwe class aanmaken? Lijkt mij een beetje TE overdreven imho. En wat doe je dan met mijn edit, nog eens een class BoardGebruiker aanmaken?

[Verwijderd]

Verwijderd schreef op 18 september 2003 @ 12:52:
[...]
Ga jij nu echt voor elke functie die in pricipe 'tussen 2 classes thuishoort' een nieuwe class aanmaken? Lijkt mij een beetje TE overdreven imho. En wat doe je dan met mijn edit, nog eens een class BoardGebruiker aanmaken?

Dit zou dan denk ik wel moeten. Maar je komt dan wel aan een boel klassen (7, 8 ofzo?), als je 'User' en 'Access' enzo gaat meetellen. Vandaar dit topic of OO wel zinvol is :-). Schijnbaar zegt 'iedereen' in eerste instantie JA, maar zodra er wat concrete uitwerkingen gevraagd worden is er een twijfel

Misschien is er iemand die een werkend OO-forum heeft en die een klassendiagram of iets dergelijks wil tonen? Zou iig wel fijn zijn om te kunnen discussieren over iets practisch dan theorie'en die niet in de praktijk zijn uitgevoerd.

[Verwijderd]

Verwijderd schreef op 18 September 2003 @ 17:10:
[...]

Dit zou dan denk ik wel moeten. Maar je komt dan wel aan een boel klassen (7, 8 ofzo?), als je 'User' en 'Access' enzo gaat meetellen.

Het probleem is niet zozeer het aantal classes, maar als je wil gaan opsplitsen, ga je je queries ook opsplitsen => trager!

Ik vroeg mij gewoon af hoe je zo'n zaken aanpakt.

[Maxonic]

Ik heb vooral moeite met de 'scheiding' tussen objecten: stel je hebt een class Categorie en een class Forum, waar zet je de static (zie uitleg whoami!) functie die alle categoriën, inclusief de subfora, neerhaalt waar de gebruiker toegang tot heeft.

Ik zou hem iig in de classe forum zetten.
Echt veel eigenschappen heeft een catogorie niet. Zo wel, dan kan je het nog andersom doen.
Je maart een klasse catogorie en een subclasse forum. Dat moet je het wel zo bekijken dat een forum een catogorie met meer eigenschappen is. Mischien is dat iets te abstract bekeken.

Ik zal in ieder geval eens proberen of ik de verschijning 'forum' kan modelleren. Lijkt me wel interessant.

Misschien is er iemand die een werkend OO-forum heeft en die een klassendiagram of iets dergelijks wil tonen? Zou iig wel fijn zijn om te kunnen discussieren over iets practisch dan theorie'en die niet in de praktijk zijn uitgevoerd

Ja, ik heb een OO-Forum
Nee, het is niet zo goed opgezet dat ik er een klasse diagram van wil laten tonen.
Ik wil binnekort wel met een nieuw forum beginnen. Geprogged in C++.
Dat moet de server voor het frontend forum bevatten en de gui voor het backend adminnen. Echter moet ik nog even goed nadenken hoe ik dit aan ga pakken.

[stekkel]

Wanneer ik zoiets zou bouwen dan zou ik gaan zoeken naar scheiding in functionaliteiten, dus alle db gerealeerde code in een aparte class, string parsing in een aparte class en je forum class daar vevolgens weer gebruik van laten maken.

Dus de bottum up approach in plaats van top down.

Eerst inventariseren wat voor basis classen je nodig hebt die geheel losgekoppeld zijn van de uiteindelijke forum implementatie en daar bovenop een forum class maken die gebruik maakt van je basis classes.

[Verwijderd]

Maxonic schreef op 18 september 2003 @ 20:11:Ik zal in ieder geval eens proberen of ik de verschijning 'forum' kan modelleren. Lijkt me wel interessant.

mij ook

[Maxonic]

Verwijderd schreef op 19 September 2003 @ 20:49:
[...]
mij ook

*kick*

Een ontwerp van een systeem kan je eigenlijk onderverdelen in drie delen. Het process-ontwerp, het gegevens-ontwerp, en het gebruikersinterface-ontwerp.
Bij de beslissing over hoe je je klasses moet indelen moet je voornamelijk naar het process-ontwerp kijken. Het gebruikers-interface ontwerp kan je zien als de laatste laag en daar hoef je je dan ook in eerste stadium niet druk om te maken. Deze post is dus misschien een beetje offtopic maar ik heb me hier even gericht op het gegevensontwerp.

Even snel zonder attributen in elkaar geflanst.
Ik kon zo snel geen driehoeken vinden dus directe relaties zonder kardinaliteiten moet je maar als ISA's zien.
Ik heb wel geprobeerd met zo veel mogelijk functies rekening te houden.



_{sorry voor layout}

Door forums aan forums te koppelen kan je subforums creëren.
Ik zie nu dat ik wel iets als catogoriën vergeten ben.

Een geregistreerde user kan op meerdere computers ingelogged zijn (dan heeft hij meerdere sessies lopen). Hij kan mailaccounts in het forum instellen. (altijd leuk om een extra forum te hebben waarin je mail staat )
Ook kan hij berichten sturen naar andere geregistreerde gebruikers.
Daarnaast heeft hij bookmarks. Dit zijn eigelijk gewoon links naar topics.
Zo'n topic kan gewoon een topic zijn maar ook een poll of een bestand. (attachment ondersteuning). Daarnaast is het voor de modjes mogelijk om een topic te verplaatsen en daarbij op de oude plaats een link achter te laten. Op die manier vinden de mensen na het verplaatsen de topics ook nog terug.
Het rechtensysteem heb ik nog niet echt grondig uitgewerkt. Ik denk dat het ook pas duidelijk wordt hoe het dient te werken als de attributen erbij staan, maar de bedoeling is als volgt:
Een user heeft bepaalde privileges. (ongeregistreerde users hebben ook privileges maar wel allemaal dezelfde natuurlijk [1 record voor de ongeregistreerde meuk])
Aan zo'n privilege kan een eis hangen. Zo kan een privilege gelden voor één enkele user of voor bijvoorbeeld alle users met 100 of meer posts.
Ik maak onderscheid in globale en lokale privileges.
globale privileges zijn dingen zoals bijvoorbeeld het gebruik mogen maken van usericons, html mogen posten, admin of global moderator zijn, verzin maar wat. Dingen dus die op het hele forum gelden.
Lokale privileges zijn forum afhankelijk. Dit kunnen dingen zijn zoals reply recht in forum 1, mod recht in forum 2, toegang tot forum 3 enz.

Dingen die ik niet in het model kwijt kon maar die waarschijnlijk wel tabellen nodig hebben zijn: tempates, banns, thema's, cp-logg, en natuurlijk de boardinstellingen.

Templates zijn gaaf. Het is een uitdaging om een forum te maken dat in de php-scripts geen enkele HTML tag gebruikt maar enkel templates uit de database rukt zodat de back-end-user niet alleen de kleur maar ook de rest van het uiterlijk van het forum kan veranderen.

Thema's ondersteunen dit template gebeuren. Een thema geeft aan welke plaatjes gebruikt worden en welke CSS gegenereerd wordt. De kleur van het forum, de tabelbreedte en het lettertype is bijvoorbeeld thema afhankelijk.

Banns, ja, dat heeft geen info nodig. Een ip adres of hostname moet voor een bepaalde of onbepaalde tijd van het forum geweerd kunnen worden.

CP-Log. Tja, misschien ook wel een leuke feature om te loggen wat mensen op het back-end-systeem uitvreten. Daar zal ook een tabel voor nodig zijn.

Smilies, dat is natuurlijk ook wel leuk om in de database vast te leggen. Misschien kan je zelfs het gebruik van diverse smiles aan een privilege koppelen zodat bepaalde mensen maar een smilie mogen gebruiken. Ook kan je ze thema afhankelijk maken. Op deze manier kan je bijvoorbeeld een smilieset voor donkere en één voor lichte achtergronden gebruiken.

Censors. Nu we toch bezig zijn. Misschien zijn censors ook leuk. Dus dat je bepaalde woorden niet in berichten, posts, signatures enz toestaat en deze vervangt met een ander woord.

Foruminstellingen. En natuurlijk komt er nog een tabel met 1 record waarin de instellingen van het gehele board worden vastgelegd. Dus welk taalbestand het forum gebruikt, welk thema standaard is, met welke voorwaarden de gerbuikers voor het registreren akkoord moeten gaan, de tijdzone instellingen, enz enz..

erg optioneel: voorzie het forum van een ingebouwde banner-admin. Klanten kunnen dan banners in een bepaald forum aanbieden enz.

En dan afgezien van het database-ontwerp:

Als je echt 1337 OOP wilt gaan doen moet je een apparte class voor de interaktie met de database maken. Op die manier kan je het forum voor meerdere databases geschikt maken. Ook van de tempate-engine en de UBB-Parser kan je een classe maken. Ow en nu we het toch over de UBB Parser hebben. Voorzie de parser niet alleen van de standaard code maar maak hem ook geschikt voor vette RML ofzo.

Ik kan daarnaast nog wel 100 ander eleuke features bedenken maar die zullen dan allemaal niet entiteitafhankelijk zijn. Dit is volgens mij dus de basis.

-- succes --



<sub>edit:

ik heb in het model het gedoe rondom forum wat verder uitgewerkt. Het is nu dus zo dat een forum een catogorie, een gewoon forum of een subforum kan zijn.
Een forum kan 0 of meerder subfora bevatten. En subforum behoort altijd tot 1 forum toe. Een forum kan deel uitmaken van 0 of 1 catogorie. Een catogorie kan meerdere fora bevatten. Opvallend is dat alle drie topics kunnen bevatten. Dus ook catogorieën. Dit zal er qua uiterlijk dan ongeveer zo uitkomen te zien als de t.net newsposts op het got-forum. Natuurlijk moeten hier wel zware privileges aan worden gebonden. Niet iedereen moet zomaar in een catogorie kunnen posten maar bijvoorbeeld alleen mod met belangrijk nieuws e.d.</sub>

Ik zit nog wel een beetje met dat privilege systeem in de maag. Dit zal ik later nog wat verder uitwerken. Misschien dat er wat standaard privilege groepen gemaakt moeten kunnen worden ofzo. Dan krijg je zoiets:

een groep bestaat uit meedere personen
een groep heeft meerdere rechten

maar kan een persoon dan ook in meerdere groepen zitten?
en hoe zit het dan met het overerven van rechten?

Ik ben zelf ook al een hele tijd aan een forum bezig maar heb ook nog geen goed rechtensysteem terwijl dat toch wel een van de vitale delen van een goed forum is.

Misschien kan Chem hier een tipje van de sluier oplichten. Hij schijnt er nogal bedreven in te zijn.

btw, Suggesties zijn welkom.
Voor de doe-het-zelfer: Visio bestand

[ Voor 25% gewijzigd door Maxonic op 28-09-2003 16:27 ]

[RedRose]

Sorry maar hier kan ik het niet mee eens zijn. Object Oriented programmeren heeft uiteraard wel wat te maken met wat voor leuke dingen je allemaal kan doen met je forum en welke functionaliteiten er in zitten, maar dit zou niet de basis moeten zijn van je OO-model.

Naast dat je je forum prima min of meer in PHP-OO kan opzetten, wordt er geen rekening gehouden met twee andere zaken die het modelleren veel makkelijker maken. Namelijk je datamodel en je procesmodel. Met dat laatste bedoel ik min of meer de wijze waarop je het proces van de te doorlopen code per instantie managed. Dingen als post_message en edit_message horen naar mijn mening thuis in de applicatielaag van je OO-model. Dat je de verwerking van deze twee verschillende typen in het verwerkingsproces in een aparte classes onderbrengt: dat kan prima. Maar beiden horen ze onder de applicatielaag te vallen.

Voorbeeld van een model:

Op het hoogste niveau kan je je model redelijk standaard laten, door een onderverdeling te maken van je classes in een datalayer, een applicationLayer en een presentationlayer.

Als ik dan even globaal en snel een tekeningetje maak, krijg je het volgende:

(klik)

Hier zie je een abstracte scheiding van je uiteindelijke classes en overige code in verschillende 'lagen' die in die schema elk haar eigen kleur hebben. Je bouwt een procesmanager die, afhankelijk van de gewenste actie, data uit de datalayer trekt (al dan niet via je app. layer), via diezelfde app. layer de gewenste transformatie bewerkstelligd, het dan doorstuurt naar je presentatielayer die het voor je parsed in de door jou gewenste format en stijl.

Zo kan je bijvoorbeeld je presentatie layer op een aantal verschillende manieren laten werken (bijv. XML/XSLT i.p.v. templates met een templatetaal) en ook nog naar verschillende typen interfaces laten outputten (output naar de browser is maar 1 van de vele mogelijkheden).

Op deze manier kan je in principe elk op zichzelf staande class met zijn specifieke methoden zelfstandig gebruiken. En er dus ook heel makkelijk extra functionaliteit aan toevoegen, of een compleet ander type systeem van maken dan een forum. In PHP zal je wel altijd goed moeten kijken naar je vars, je references, je loops en je queries, omdat je daar veel perfomance winst -of verlies mee kan behalen. Maar dat was boven geloof ik al gezegd.

Dan wat betreft het datamodel: dat is voor een forum helemaal niet zo moeilijk en ingewikkeld om te bedenken, mits je duidelijke scheiding aanbrengt in de verschillende typen gegevens. Ik zag boven het voorbeeld van een subcategorie (subforum) in een forum. In feite blijft dit gewoon een categorie, dus een tabel met subcategorieen heb je helemaal niet nodig. In feite volstaat in de basis deze tabelstructuur voor categorieen/subfora:

SQL:

CREATE TABLE categories (
catID BIGINT(255) auto_increment NOT NULL,
catParentID BIGINT(255) NOT NULL,
accessLevel INT(32) NOT NULL,
title VARCHAR(255) NOT NULL,
description TEXT NOT NULL,
adminID BIGINT(255) NOT NULL,
numberOfTopics BIGINT(255) NOT NULL,
numberOfPosts BIGINT(255) NOT NULL,
dateLastPost DATETIME,
PRIMARY KEY (catID)); #En dan even niet 
#letten op de columntypes a.u.b.

Verzin er zelf een 'messages'-table en een 'topics'-table bij en je bent al een heel eind. Sessiemanagement en usermanagement kan je op deze manier ook eenvoudig afhandelen, als je maar in de gaten houdt dat je je model en je code simpel en overzichtelijk houdt.

Als je alles aan elkaar gaat plakken in 1 groot schema, zie je later door de bomen het bos niet meer, wat zeer waarschijnlijk ook gaat resulteren in onoverzichtelijke code. In plaats van een schema heb je er minstens drie nodig (zie bovenstaand) en dan hou je niet alleen en overzicht, maar hou je het ook nog eens simpel en blijf je niet continue aan het 'zoeken' in je door elkaar gegooide functionaliteiten en allerlei veel te ingewikkeld gemaakte code.

Ja ik heb zo'n OO-forum in PHP, en nee ik ga geen source laten zien, omdat ik denk dat lezer daar niets van opsteken als ze niet eerst zelf de basisprincipes van modelleren onder de knie hebben. Ongeacht het model, of dat nu goed of slecht bedacht is, of dat je een door anderen 'apart' gevonden model zelf wel overzichtelijk vind: hou het gescheiden, netjes en vooral simpel. Dan ben je al een heel eind.

[Verwijderd]

Hoewel het model van Maxonic best aardig in elkaar steekt, is dit wel een ER (entity relation) model volgens mij. En dus heeft dit niet zoveel betrekking op de klassen, maar op vooral op de database. Nou is dat ook wel interessant natuurlijk, maar in eerste instantie ging het hier om het klassenmodel.
RedRose, je hebt ook geen zin om je klassenmodel hier te laten zien? Of het desnoods te mailen? Ik ben best benieuwd naar je model namenlijk aan de hand van je bovenstaande tekening.

[Maxonic]

Idd, daar ben ik ook wel erg benieuwd naar. Het ER heeft idd weinig met het OOP gebeuren te maken maar ook daar was ik wel benieuwd naar hoe dat een beetje in elkaar zou steken.

Ik zag boven het voorbeeld van een subcategorie (subforum) in een forum. In feite blijft dit gewoon een categorie, dus een tabel met subcategorieen heb je helemaal niet nodig.

Ja, ik heb misschien een beetje rare manier van modelleren. Een ISA wilt bij mij niet automatisch zeggen dat ik apparte tabellen creeer. Voor mezelf vind ik het echter zo wel duidelijk om aan te geven dat men de records in de tabel forum in drie groepen kan indelen. ^{ook mijn kardinaliteiten staan andersom dan velen geleerd hebben te doen...}

Ik zit mezelf al het hele weekend en ook vandaag het hoofd te breken over 2 vraagstukken.
1 is hoe een goed rechtensysteem met gebruikersgroepen eruit zal zien.
2 is hoe het klassendiagram eruit zal komen te zien.

1 is in dit topic een beetje inrellevant maar ik wacht met smart op iemand die een leuk voorbeeltje van een klassediagram heeft.

Bij het Procesmodel van RedRose kan ik me eigenlijk moeilijk een concrete voorstelling maken. Misschien dat dat ook niet de bedoeling is maar een iets bredere uitleg zouden leken als ik wel fijn vinden. Misschien dat we er zelfs nog wat van leren!

[Verwijderd]

als we nou met zijn allen gaan zeuren geeft parse misschien het klassendiagram voor dit forum vrij....

[Verwijderd]

Verwijderd schreef op 29 September 2003 @ 13:37:
als we nou met zijn allen gaan zeuren geeft parse misschien het klassendiagram voor dit forum vrij....

Begin 's bij chem zou ik zeggen
Ga er maar van uit dat dat geen zin heeft. Dit forum is niet bedoeld om jou in een keer een compleet ontwerp etc te geven. Meer om jou wat hulp te geven, zodat je het zelf kunt maken.

[Maxonic]

als we nou met zijn allen gaan zeuren geeft parse misschien het klassendiagram voor dit forum vrij....

Niet nodig, we gaan er gewoon zelf één maken die veel beter is

Ik ben momenteel bezig alle taken van de forumgebruikers te noteren.
Als ik hiermee klaar ben ga ik alle procedures die per taak doorlopen worden noteren.
Hierbij vermeld ik wanneer er op welke manier interaktie met de database voorkomt.
CRUD-diagram heet dat als ik me niet vergis.
Dan maak ik instinctief een leuk lijstje met alle klassen en daarna de bijbehorende functies waarbij ik aangeef welke input ze vereisen en welke output ze geven.

Ik weet niet of dit de gebruikelijke manier is, heb al een tijd niks met UML gedaan. Het lijkt me iig wel verstandig om het toch enigsinds in te delen naar database-interakties gezien je zo het aantal queries dat dadelijk nodig is beperkt houd.

Als je nl een klasse Topic hebt en een klasse Post dan is het nogal lastig om 1 één querie alle info over 1 topic + bijbehorende posts te verkrijgen. toch? correct me if i'm wrong, 'k klooi ook maar wat aan

[Verwijderd]

Maxonic schreef op 29 september 2003 @ 17:37:
[...]

...

Als je nl een klasse Topic hebt en een klasse Post dan is het nogal lastig om 1 één querie alle info over 1 topic + bijbehorende posts te verkrijgen. toch? correct me if i'm wrong, 'k klooi ook maar wat aan

Dat is moeilijk

topic: id, titel, locked, mededeling, id forum, ...
posts: id, datum, text, id topic, auteur, ...

Je kan natuurlijk de posts leeghalen, en per post telkens koppelen (dmv. id topic) aan de topic tabel, dan heb je het natuurlijk in 1 query Maar dan heb je wel veel redundantie, hoewel bij weinig posts dat nog eens sneller kan zijn dan een aparte topic query, maar mooi vind ik het niet. Je moet je relaties respecteren, imho.

[ Voor 9% gewijzigd door Verwijderd op 29-09-2003 17:50 ]

[Verwijderd]

Goed, om toch nog iets productiefs uit dit topic te halen heb ik een simpel klassendiagram gemaakt. Nou zou ik graag hebben dat dit helemaal afgekraakt zou worden en dat ik nuttige feedback zou kunnen krijgen.

[Verwijderd]

Moet ie het wel doen

[Edit: never mind - mijn fout hiero >:)]

[ Voor 72% gewijzigd door Verwijderd op 30-09-2003 16:42 ]

[Verwijderd]

Waarom een aggregatie van Forumpage -> Topic en niet van Forum -> Topic of zelfs van Forum naar Topicpage?

[Verwijderd]

Met forumpage bedoel ik een pagina waar alle topics van een betreffend forum opstaan.
Een aggregatie van Forum naar topic zou eigenlijk wel moeten ja, maar het nut van een forum->topicpage (een pagina waar alle posts van dat betreffende topic staan) zie ik even niet....