[UML/PHP/OOP] Forum Model

[Verwijderd]

Er lopen op GOT verscheidene draadjes met daarin vragen over het perfecte object orientated model voor een forum in PHP. Hierin schreeuwt iedereen meteen dat OOP de manier is die men moet volgen maar er zijn nooit concrete oplossingen en zo gauw er een discussie over begint haken de OOP aanhangers vaak af .

Nu ben ik zelf een OOP aanhanger alleen ben ik nog niet van mening dat het de beste oplossing is voor het schrijven van een forum in PHP. Nu weet ik dat React OOP based is en dat men hier heel content mee is dus het zal toch mogelijk zijn .

Na het lezen van alle draadjes gerelateerd aan dit onderwerp blijkt dat er 2 type oplossingen zijn volgens de Gotters. Namelijk een object per page (bijvoorbeeld ViewTopic en InsertTopic) welke allemaal gebaseerd zijn op een basis klasse. In deze basisklasse zijn vervolgens weer een aantal standaard klasses gedefinieerd voor het bijhouden van sessions en contact met de database. Imo is dit niet echt een hoogstaand model maar wellicht wel makkelijk om optimale queries te schrijven met dit model.

De 2e oplossing is het maken van Post, Topic, Category, Forum classes. In bijvoorbeeld een forum.php zou je dan classes voor het bijhouden van sessies & databases kunnen aanmaken en dan een bestand kunnen includen met daarin de code voor de juiste actie. Even als voorbeeld React

/forum/list_message/200000:
forum.php zou standaard zut aanmaken en vervolgens list_message.inc.php kunnen includen. (Dit zou ook nog weer een klasse kunnen zijn maar dan val je weer terug op de eerste oplossing ).

In list_message.inc.php zou hij een instantie van de klasse Topic maken en met een paar aanroepen de informatie uit de database trekken voor dat specifieke topic.

Al met al kan ik niet echt een briljant model voor een forum in PHP bedenken waarbij ik me redelijk aan de regels van OOP houdt en waar ik ook de mogelijkheid houdt om m'n queries zo optimaal mogelijk uit te voeren. (Dus geen listforums waar ik eerst alle categorien uit de database ruk waarbij ik dan per categorie nog weer aan het rukken ga )

Wanneer de uberl33t proggers van Got (Chem en andere parse luitjes? ) hier nog een tipje van de sluier kunnen oplichten en mij een trap in m'n achterste zouden kunnen geven dan zou ik dit zeer op prijs stellen.

Uiteraard vraag ik geen compleet model voor een forum in PHP. Enkel een voorzet. De goal hoop ik zelf te maken .

[Alarmnummer]

Ik heb de indruk dat jij alleen maar denkt in het domein model en niet zozeer in de algehele architectuur (die is vele malen groter en gecompliceerder). Een domein model is meestal maar een heel klein onderdeel van het geheel en als je kennis over het domein goed genoeg is, ook zeker niet het lastigste.

[Verwijderd]

Wat moet ik me voorstellen bij een domein model?

[ Voor 20% gewijzigd door Verwijderd op 18-07-2004 16:33 ]

[Alarmnummer]

Verwijderd schreef op 18 juli 2004 @ 16:32:
Wat moet ik me voorstellen bij een domein model?

Daarin vind je de entiteiten terug die je in een dat domein zult aantreffen. Het domein model van een forum zal een User, Forum, Topic, Ban etc bevatten. Maar geen datamapper, geen view, geen controller etc. Een domein model is dus maar een heel klein onderdeel van het volledige model van je applicatie. En technisch ook niet de meest uitdagende.

[edit]
Een domein model lijkt enorm veel op een database model.

[ Voor 7% gewijzigd door Alarmnummer op 18-07-2004 17:00 ]

[simon]

Is het niet veel handiger om al je 'acties' te 'normaliseren', en een soort van 'core' te maken, waar zaken als list_messages, list_topics alleenmaar de output regelen, maar niet het ophalen.

Dus scheiden in drie delen:
ophalen / verwerken data - data omzetten naar template - template

Hier zou je xml ook mooi in kunnen verwerken

[ Voor 15% gewijzigd door simon op 18-07-2004 17:04 ]

[Verwijderd]

Simon schreef op 18 juli 2004 @ 17:01:
Is het niet veel handiger om al je 'acties' te 'normaliseren', en een soort van 'core' te maken, waar zaken als list_messages, list_topics alleenmaar de output regelen, maar niet het ophalen.

Dus scheiden in drie delen:
ophalen / verwerken data - data omzetten naar template - template

Hier zou je xml ook mooi in kunnen verwerken

Jij denkt dat een core klasse met algemene routines als parent een mooi OOP design zou zijn. Het lijkt mij juist dat dit precies tegen de regels van OOP in is. Je hebt dan immers geen specifieke klasses maar (net als XMB dacht ik) een gigantische klasse met daarin een groot deel van je code waarbij je een paar regeltjes code typt in je actie specifieke bestanden.

Lijkt mij niet het id achter object orientated programmeren

[chris]

Wat je misschien kan helpen in het OO-gedeelte: een user request telkens één object. Dit kan b.v. een root-object zijn (output: de lijst met alle sub-fora en (a.d.h.v. rechten) een lijst met actiest, bijvoorbeeld: "new forum, delete forum"), een forum-object (output: een lijst met topics, actiest als: delete topic, new topic), een topic-object (output: een lijst met posts).

Enfin: er heeft - als je het allemaal goed op een rijtje zet - altijd maar één object de focus, en aan de hand daarvan ga je kijken welke subobjecten je moet selecteren en welke acties je wilt weergeven. Dit zet je b.v. in een xml-bestand, die je vervolgens met xslt kan transformeren naar een mooie html-pagina.