Heyhey, ik beheer een website waar bezoekers een contactformulier kunnen opstellen. Daar zit een formbuilder bij waarmee zij hun contactformulier zonder HTML kennis kunnen aanmaken.

Het client-side gedeelte bestaat al; bezoekers klikken eerst welk type inputveld ze willen toevoegen aan hun contactformulier (textveld, textarea, checkbox, etc), vervolgens vullen ze in welke vraag het veld moet beantwoorden ("Wat is uw lievelingskleur, bijv") en ook de antwoordmogelijkheden (bij bij een radiobuton; groen, blauw, rood, anders). Zodra de gebruiker op toevoegen klikt wordt het input veld aan het contactformulier toegevoegd. Zodra het formulier klaar is, is het als HTMLbestand te downloaden.

Nu wil ik ook de mogelijkheid bieden om de contactformulieren op te slaan. Belangrijk punt hierbij is dat de contactformulier velden (én hun antwoordmogelijkheden) allebei op volgorde worden opgeslagen.

Ik zit aan 2 manieren te denken:

1- een tabel met de velden:
contactformID (int) , emailto, contactform_velden (text)

waarin 'contactform_velden' gesplitst wordt met een delimeter (::)per vraag, en daarin ook delimeters (//) per subvraag zitten. Bijv:

::TEXT=Wat is uw naam?::RADIO=Wat is uw lievelingskleur?//Rood//Groen//Blauw::

Maar dan met delimeters die niet in de vraag gebruikt kunnen worden.

2. 3 tabellen:

- contactform
contactformid, emailto

- contactform_question
questionid, questiontype, parent_contactformid, questionstr, question_order

- contactformquestion_options
option_id, parent_questionid, optionstr, option_order

Bijv:

-contactform
123, 'jan@bla.nl

- contactform_question
1, 'TEXT, 123, "Wat is uw leeftijd?", 0
2, 'RADIO', 123, "Wat is uw lievelingskleur?",1

- contactformquestion_options
1, 2, "Blauw",1
2, 2, "Rood",3
3, 2, "Groen",2

Methode 2 lijkt me qua SQL er veel beter uitzien, maar ik weet niet welke methode het in PHP ook makkelijker maakt om de form op te stellen.

Wat vinden jullie? Hoe lossen jullie een probleem op waarbij SQL rijen op volgorde geplaatst moeten worden, en aan veel wijzigingen onderhevig zijn?

grz chiel

absoluut optie 2.

Normaliseren totdat je erbij neervalt
Het is 1000maal efficienter om iets door je DBMS te laten doen dan met code (zoals het opsplitsen van velden)

(01-02-2010 11:13:36)Violent J schreef:  absoluut optie 2.

Normaliseren totdat je erbij neervalt
Het is 1000maal efficienter om iets door je DBMS te laten doen dan met code (zoals het opsplitsen van velden)

Ik ben het niet helemaal eens met de "absoluut"

Ik neem aan dat een formulier altijd in zijn geheel wordt opgehaald en niet in losse delen. Daarom zou ik het formulier opslaan als XML formaat opslaan in de database.

Dan kan je doormiddel van een JSTL -translatie je formulier renderen, en hoef je geen moeilijke contructies te gaan bedenken om je formulier in elkaar te zetten.

(06-02-2010 18:17:57)reijnemans schreef:  [...]

Ik ben het niet helemaal eens met de "absoluut"

Ik neem aan dat een formulier altijd in zijn geheel wordt opgehaald en niet in losse delen. Daarom zou ik het formulier opslaan als XML formaat opslaan in de database.

Dan kan je doormiddel van een JSTL -translatie je formulier renderen, en hoef je geen moeilijke contructies te gaan bedenken om je formulier in elkaar te zetten.

Opslaan in XML zodat je data binnen je DBMS alle semantische waarde verliest? Probeer dan nog maar eens zinnige transformaties te doen op je data, good luck.

Ik zie dat JSTL een Java package is, we zitten hier op het php forum he
Ik vermoed dat het een soort van XSL-transformatie is. Dat is op zich leuk, maar ben daar zelf niet zo kapot van. Vaak is het net zo makkelijk te coden En daarnaast, als je zo graag zoiets wilt gebruiken, trek je data uit de database, bak daar een XML van en pleur je XSL dr overheen, best of both worlds zou ik zeggen.

(09-02-2010 10:14:57)Violent J schreef:  Ik zie dat JSTL een Java package is, we zitten hier op het php forum he

Je hebt gelijk ik bedoelde eigenlijk een XSLT translatie, ik weet zelf ook niet hoe ik op JSTL ben gekomen.

(09-02-2010 10:14:57)Violent J schreef:  Dat is op zich leuk, maar ben daar zelf niet zo kapot van

Dat zou geen argument moeten zijn om het niet te gebruiken.
XSLT is namelijk wel heel krachtig. A fin, de voordelen en nadelen

Voordelen XSLT:
* Makkelijk renderen van formulieren zonder dat daar code aan te pas hoeft te komen
* Makkelijk uitbreidbaar met nieuwe functionaliteiten (vb eigen style voor een formulier)
* Eenvoudig in 1 tabel op te slaan
* Code is cleaner
* Makkelijk wijzigingen te doen in de STRUCTUUR van het formulier,

Nadelen XSLT:
* Maintainablility, "lastiger" te onderhouden dan uitgenormaliseerde manier.
* Je haald altijd het hele formulier op uit de database

(10-02-2010 08:05:52)reijnemans schreef:  [...]

(09-02-2010 10:14:57)Violent J schreef:  Dat is op zich leuk, maar ben daar zelf niet zo kapot van

Dat zou geen argument moeten zijn om het niet te gebruiken.

Is het ook niet, de reden daarvoor geef ik ook aan: 'Vaak is het net zo makkelijk te coden'

(10-02-2010 08:05:52)reijnemans schreef:  XSLT is namelijk wel heel krachtig. A fin, de voordelen en nadelen

Voordelen XSLT:
* Makkelijk renderen van formulieren zonder dat daar code aan te pas hoeft te komen
* Makkelijk uitbreidbaar met nieuwe functionaliteiten (vb eigen style voor een formulier)
* Eenvoudig in 1 tabel op te slaan
* Code is cleaner
* Makkelijk wijzigingen te doen in de STRUCTUUR van het formulier,

Nadelen XSLT:
* Maintainablility, "lastiger" te onderhouden dan uitgenormaliseerde manier.
* Je haald altijd het hele formulier op uit de database

Je haalt hiermee ook exact de twee grootste nadelen aan, die wat mij betreft echt show stoppers zijn.
XSLT syntax is echt hel, probeer het maar eens te onderhouden, te lezen, te delen met een team. Zoek maar eens op google op 'xslt readability'

Bovendien heb ik twijfels bij jou opsomming van 'voordelen':
* Makkelijk renderen van formulieren zonder dat daar code aan te pas hoeft te komen: Je hebt een (complexe) XSLT, dat is ook code die onderhouden moet worden
* Makkelijk uitbreidbaar met nieuwe functionaliteiten (vb eigen style voor een formulier): Hier zijn voldoende alternatieven voor binnen een MVC setup
* Eenvoudig in 1 tabel op te slaan: Wat is hier het voordeel van?
* Code is cleaner: Zie hierboven 'xslt readability'
* Makkelijk wijzigingen te doen in de STRUCTUUR van het formulier: idem

Daarnaast ga je niet in op mijn laatste punt:

(09-02-2010 10:14:57)Violent J schreef:  En daarnaast, als je zo graag zoiets wilt gebruiken, trek je data uit de database, bak daar een XML van en pleur je XSL dr overheen, best of both worlds zou ik zeggen.

Je behoudt alle voordelen van je DBMS, plus je kan gebruik maken van XSLT mocht je daar behoefte aan hebben.
XML als datastore kan (bijna) nooit een zinnige oplossing zijn.