[php] Klachtafhandeling voor verschillende site onderdelen

[radem205]

Hey,

Voor een website moeten voor de meeste onderdelen waarbij bezoekers input kunnen leveren (zoals reacties, topic, etc.) een optie komen om een klacht te kunnen indienen over het betreffende item.

Nu heb ik dus zo goed als het hele systeem klaar, echter wil ik graag jullie advies hebben over hoe zo'n klachtensysteem in elkaar te zetten.

In het beheer is het de bedoeling dat alle klachten te zien zijn en het item waar het over gaat zichtbaar en aanpasbaar is.

Wat ik nu heb is een tabel genaamd 'klachten'. Nu moeten daar dus alle klachten bijeen komen (dit is geen probleem).

De tabel 'klachten' bevat de volgende velden:

id
klachttype - Dit is een enum veld met het type klacht, zoals forum, mp3reactie, etc.
itemid - Dit is een integer wat correspondeert met de id behorend bij het type klacht, waarmee het beteffende item opgevraagd kan worden
lidid - Het id van het lid die de klacht heeft ingediend
klachtomschrijving - Omschrijving van de klacht
datum - Datum toegevoegd

Nu dient in het beheer de afzonderlijke items waarover de klacht gaat (reacties, topic, mp3, video, etc.) zichtbaar te worden, waarbij er aantal opties zijn: item aanpassen, item verwijderen of klacht negeren.

Het lastige aan deze manier van klachten afhandelen is dat je te maken hebt met verschillende veldnamen per klachttype.
Wat ik nu heb is een array met de verschillende klachttypen die de veldnamen bevatten en het type item (text, mp3, video, etc.). Deze array gebruik ik om te weten wat voor een type item weergegeven moet worden (moet er een textarea getoond worden met daarin het bericht, of een mp3 speler met het mp3 bestand, etc.).

Ik hoop dat jullie door mijn verhaal een indruk hebben hoe ik het nu heb. Ik loop namelijk tegen een aantal problemen aan, kortweg:

- Het aanpassen van de items wordt lastig door de verschillende veldnamen die per type item worden gebruikt.
- Bij een forumreactie moet ik een controle inbouwen om te kijken of het een reactie of een topicstart is (is omslachtig)
- Het wordt allemaal erg complex

Een andere methode is om bij een klacht rechtstreeks door te verwijzen naar het item zoals die op de website te zien is, maar omdat het veelal om reacties gaan die door ajax worden ingeladen wordt dit een lastig zaak en zal het bericht, etc. nog aanpasbaar gemaakt moeten worden.

Ik kan het allemaal wel op deze manier doen, maar ik heb een idee dat het wat beter kan en vraag jullie of jullie wellicht een betere, eenvoudigere oplossing hebben.

[Alain]

radem205 schreef op woensdag 26 mei 2010 @ 22:15:
Ik kan het allemaal wel op deze manier doen, maar ik heb een idee dat het wat beter kan en vraag jullie of jullie wellicht een betere, eenvoudigere oplossing hebben.

Gezien het feit dat itemid naar verschillende entiteiten kan wijzen denk ik dat je datamodel niet op orde is. Misschien is het handig om dat wat meer uit de doeken te doen.

Hou je nog over dat je een topicstart als iets anders dan een reactie beschouwd, maar ik denk dat dit een simpele check is zodra je datamodel op orde is.

[Cartman!]

Misschien te simpel gedacht, maar waarom pak je niet de url van de pagina ipv. een itemid?

[simon]

Omdat urls wels veranderen?

[CH4OS]

simon schreef op woensdag 26 mei 2010 @ 23:00:
Omdat urls wels veranderen?

Met een mooi rewrite systeem heb je daar als het goed is nooit last van...

[japaveh]

AlainS schreef op woensdag 26 mei 2010 @ 22:51:
[...]
Gezien het feit dat itemid naar verschillende entiteiten kan wijzen denk ik dat je datamodel niet op orde is. Misschien is het handig om dat wat meer uit de doeken te doen.

Dat is strikt genomen toch niet zo erg? Voorwaarde is dan wel dat het gekoppeld is aan waarde van klachttype en dat de combinatie maar 1 keer voor mag komen. Je zou dat dan wel moeten afdwingen met een unique key op beide velden, of mis ik nu iets?

update: die unieke restrictie is natuurlijk niet nodig, je hebt immers de mogelijkheid op meer dan 1 klacht per element te hebben.

[ Voor 24% gewijzigd door japaveh op 27-05-2010 00:17 . Reden: Aanvulling ]

[radem205]

Het probleem bij het gebruiken van de oorspronkelijke url is dat veel reacties met ajax worden ingeladen en het zo moeilijk is om de focus op de juiste reactie te leggen.

Bij reacties hebben alle onderdelen dezelfde veldnamen, namelijk "id" en "bericht", waarbij bericht dus aangepast dient te worden. Echter zijn er veel meer onderdelen waar een klacht over ingediend kan worden, zoals een toegevoegde mp3, video, etc. Deze onderdelen hebben vanzelfsprekend geen veldnaam "bericht", maar respectievelijk "mp3" en "video" (waarin de bestandsnaam van de video wordt opgeslagen).

Ik denk dat het niet op een eenvoudigere manier kan dan ik al had bedacht, of zien jullie andere kansen?

AlainS schreef op woensdag 26 mei 2010 @ 22:51:
[...]


Gezien het feit dat itemid naar verschillende entiteiten kan wijzen denk ik dat je datamodel niet op orde is. Misschien is het handig om dat wat meer uit de doeken te doen.

Hou je nog over dat je een topicstart als iets anders dan een reactie beschouwd, maar ik denk dat dit een simpele check is zodra je datamodel op orde is.

En itemid bevat altijd een integer van het item (onderdeel) dat gewijzigd moet worden. Dit lijkt mij een vereiste, anders weet je niet over welk item het gaat.

[ Voor 31% gewijzigd door radem205 op 27-05-2010 10:06 ]

[Alain]

radem205 schreef op donderdag 27 mei 2010 @ 10:04:
En itemid bevat altijd een integer van het item (onderdeel) dat gewijzigd moet worden. Dit lijkt mij een vereiste, anders weet je niet over welk item het gaat.

Dat bedoel ik niet. Ik bedoel dat een bericht iets anders is dan een mp3 en dat 1 id (wat dus zowel een bericht als een mp3 kan zijn) niet erg praktisch is. Ik denk dat daar jou moeilijkheid zit.

japaveh schreef op donderdag 27 mei 2010 @ 00:13:
[...]

Dat is strikt genomen toch niet zo erg? Voorwaarde is dan wel dat het gekoppeld is aan waarde van klachttype

Dat is een mogelijkheid, maar ik vind dat erg omslachtig. Je zou dan aan de hand van de waarde van klachttype moeten bepalen welke tabel je moet gaan koppelen.

[ Voor 29% gewijzigd door Alain op 27-05-2010 23:17 ]

[radem205]

AlainS schreef op donderdag 27 mei 2010 @ 23:09:
Dat is een mogelijkheid, maar ik vind dat erg omslachtig. Je zou dan aan de hand van de waarde van klachttype moeten bepalen welke tabel je moet gaan koppelen.

Dat is wel de manier die ik nu toepas. Ik zou niet weten hoe je anders de klacht kan koppelen aan een bepaalde rij in een tabel. Misschien dat jij een betere manier weet?

[muksie]

Het probleem waar je tegen aan loopt is dat je eigenlijk inheritance nodig bent. Dit is echter lastig te realizeren in een relationele database. Je hebt namelijk verschillende soorten inhoud (topicstart, reactie, mp3 etc.) die allemaal een vorm van content zijn. Zelfs de klachten zou je kunnen zien als een vorm van content.

Er zijn verschillende manieren om deze hierarchische object-structuur te mappen naar een relationele structuur, zie bijv. hier, maar er is imho geen manier welke in alle gevallen geschikt is.

Wat je zou kunnen doen (en wat ik denk ik zou doen) is een content tabel te maken, met in ieder geval velden id en type. Zo heeft ieder stukje content een uniek id, en kun je in je klachten tabel het type veld weglaten, en van itemid een FK naar content maken.

Op deze manier kun je eenvoudig, gegeven een zeker content id, de bijbehorende klachten vinden. Andersom gaat misschien wat lastiger, dus dat je een klacht hebt, welke d.m.v. itemid verwijst naar een stukje content, de details van de content op kunt vragen. Het eenvoudigste lijkt me om een functie o.i.d. te maken welke, gegeven een content id en content type, de url naar deze content geeft. Op deze manier krijg je geen problemen wanneer de urls wijzigen, en indien je een framework gebruikt is dit bij veel frameworks eenvoudig te realiseren.

Indien je met AJAX klachten op content wilt kunnen geven, dan is het zaak om van ieder stukje content waar je een klacht over wilt kunnen indienen de content id en content type mee te geven en op te slaan zodat dat met javascript opgevraagd kan worden.

[Alain]

Ik dacht zelf aan een klachten tabel per item. Dus bij de Reactie tabel hoort een tabel ReactieKlacht en bij de tabel MP3 hoort een tabel MP3Klacht. Je kunt dan eenvoudig de eigenschappen van een item opvragen bij een klacht, klachten opvragen bij een item en door middel van een UNION een lijst van klachten opvragen.

Wat ook een mogelijkheid zou zijn is dat je bij een klacht verschillende id velden gebruikt met een constraint dat slechts 1 van de id's niet NULL is. Dus:

Klacht
klachtId, reactieId, mp3Id, [eigenschappen van klacht]

Vervolgens join je alle item tabellen en dan hou je de eigenschappen van het item over. Dit vind ik gevoelsmatig een minder mooie oplossing.

[SvMp]

- Het aanpassen van de items wordt lastig door de verschillende veldnamen die per type item worden gebruikt.

Werken met een abstract class waar het algemene en tevens grootste deel van je code zit en een gewone class die per item wordt geschreven. Verdeel de taken zo dat de gewone class zo eenvoudig en compact mogelijk is, zodat je als je het eenmaal voor een item werkend hebt, ook binnen no-time voor de andere items klaar hebt.

Voor de database heb je de keuze uit één klacht tabel of afzonderlijke tabellen.
Eéń tabel: Velden die specifiek zijn voor een item zet je in de beschrijving. Jouw script moet er een mooi verhaaltje van maken zegmaar.
Of je kiest voor afzonderlijke tabellen voor elk type klacht. Ook prima werkbaar icm. een abstracte class met algemeen geldende code.

[ Voor 27% gewijzigd door SvMp op 28-05-2010 23:14 ]

[MoBi]

Dome vraag misschien, maar heb je niet gewoon ook een itemtype? Deze zou dan gelijk moeten zijn aan je klachttype.

[radem205]

MoBi schreef op zaterdag 29 mei 2010 @ 10:03:
Dome vraag misschien, maar heb je niet gewoon ook een itemtype? Deze zou dan gelijk moeten zijn aan je klachttype.

Aangezien klachttype en itemtype gelijk zijn aan elkaar is de klachttype ook meteen het itemtype in de huidige situatie.

[Janoz]

radem205 schreef op zaterdag 29 mei 2010 @ 11:02:
[...]


Aangezien klachttype en itemtype gelijk zijn aan elkaar is de klachttype ook meteen het itemtype in de huidige situatie.

Op zich is je naamgeving dan niet helemaal correct. Een 'klachttype' is het type van de klacht, niet het type van het item. Bij klachttype zou ik dan ook eerder denken aan een enum als spam, schelden, discriminatie, porno , anders.

[Cartman!]

En de naam van je tabel + het id bij je klacht opslaan? Dan ben je er volgens mij toch ook en is het makkelijk uitbreidbaar.

Verder met Janoz, klachttype lijkt me waar de klacht over gaat, niet je type entiteit.

[radem205]

Cartman! schreef op zondag 30 mei 2010 @ 09:47:
En de naam van je tabel + het id bij je klacht opslaan? Dan ben je er volgens mij toch ook en is het makkelijk uitbreidbaar.

Verder met Janoz, klachttype lijkt me waar de klacht over gaat, niet je type entiteit.

De naamgeving van het veld "klachttype" is misschien niet helemaal correct, maar in dit geval is het dus ook de tabel + id opgeslagen worden en aan de hand daarvan worden de items waarover de klacht gaat opgehaald. Alleen heb ik dan nog een constructie moeten bedenken om ook de betreffende velden binnen de tabel van het item op te halen.