Graag zou ik willen weten of ik in de juiste richting zit te denken.
Vanuit mijn database maak ik opties aan voor in de select, zodat gebruikers alleen daar de keus uit hebben.
Natuurlijk wil je niet dat via de inspector de waardes alsnog kunnen worden aangepast.
Ik wil dus een controle of de waarde ook overeenkomt met de lijst uit de database.
Is het dan verstandig als het formulier geladen word eerst de waardes in een array te zetten en met een foreach loop de opties aan te maken en de controle te doen met array_key_exists?
>> Wat zou de use case zijn die de overhead rechtvaardigt?
- Lees Rob zijn reactie nog eens door
Bovendien zit een formulier dikwijls vol vuiligheid verstuurd door kwaadwillende bots of rotzakken. Daarom wil je een formulier op allerlei manieren "beproeven" om te voorkomen dat er data in je database komt die er helemaal niet hoort te zijn, ook als deze data "database technisch" wel klopt. Daarnaast kunnen er in je formulier velden zitten die niet of niet rechtstreeks naar de database geschreven worden maar die je wel wilt valideren zoals bijvoorbeeld een CSRF token.
Jouw (Ad Fundum) methode waarin je eigenlijk gaat afwachten of je database wel of niet met een foutmelding kan komen kan volgens mij wel nuttig zijn als er op één of meerdere kolommen een UNIQUE CONSTRAINT zit. (Bijvoorbeeld op de 'email' kolom in de user tabel om te voorkomen dat er meerdere accounts op één mailadres komen te staan).
De hele tabel doorlopen op alle voorkomende mailadressen lijkt me dan een kostbare operatie waardoor ik in dat geval zou kiezen voor een INSERT waaruit mogelijkerwijs een foutmelding komt die zegt dat het mailadres al in de tabel aanwezig is.
De hele tabel doorlopen op alle voorkomende mailadressen lijkt me dan een kostbare operatie waardoor ik in dat geval zou kiezen voor een INSERT waaruit mogelijkerwijs een foutmelding komt die zegt dat het mailadres al in de tabel aanwezig is.
Maar dat doe je toch in de validatie van het formulier? En in de query waarin je dat controleert zul je ook een case-insensitive controle moeten doen of wat dan ook. Net zoals je als je een nieuwe gebruiker aanmaakt iets soortgelijks wilt doen. Weet niet helemaal of je dat soort regels in de database kunt verankeren, bijvoorbeeld dat je als je een gebruiker Henk hebt dat het niet is toegestaan om een andere gebruiker HENK toe te voegen? Je zou dus kunnen stellen dat je op die manier meer semantische regels kunt toevoegen naast de reeds aanwezige syntactische regels. Dit valt volgens mij onder de "business logic" van de applicatie?
Vraag is ook, als dit uberhaupt mogelijk is, of het echt wenselijk is om dat allemaal in de database vast te leggen. Elke keer als je dan nieuwe regels verzint of wilt aanpassen houdt dit een databasewijziging in? Dat zou ik dan zelf liever in een andere laag regelen in plaats van dat helemaal vast te timmeren in de database. Op die manier worden dat soort regels ook makkelijker programmeerbaar.
Zou je dit kunnen vergelijken met een zwik rewriterules in een .htaccess-bestand die precies alle mappings vastleggen van externe URL naar intern adres versus een enkele regel die alles naar een index.php bestand delegeert? Ik zou dan wel weten welke variant ik zou kiezen.
Bedankt voor de reacties. Waar het mij hoofdzakelijk om gaat is het volgende
In de DB staan tijden, deze worden gefetched als de pagina geladen word.
De gebruiker mag alleen die tijden gebruiken, word er gemanipuleerd dan treed er een foutmelding op.
Stap 1: laad de tijden
Stap 2: controleer of de tijd die is geselecteerd voorkomt in de DB.
Werken met ID's?
De tijd die gepost word gebruiken in where?
Je zult wat meer moeten vertellen over deze tijden. Mogen deze ook maar één keer geselecteerd worden en zijn ze daarna niet meer beschikbaar? Hoe is het "gedrag" van zo'n tijd precies? Kun je concreet vertellen over wat voor tijd het gaat?
Er kan ook tijd verstrijken tussen het laden van de formulierpagina met de tijden en het submitten ervan. Daarnaast kan het gebeuren dat 100 personen tegelijkertijd een formulier submitten, en dat de tijd meerdere keren wordt gekoppeld aan verschillende records, mogelijk met dubbele boekingen of wat dan ook tot gevolg.
Het "gedrag" van zo'n tijd bepaalt hoe de validatie hiervan verloopt, als je hier tips over wilt zul je ons dus moeten uitleggen hoe je wilt dat deze tijden zich gedragen.
Klaarblijkelijk mag een gebruiker dus kiezen uit een aantal tijden.
De tijden kun je dan aan de gebruiker tonen op een nette manier, bijv.
13.15 uur
of als het om een tijdvak gaat
13.15 - 13.30 uur
Aan zo'n tijd of tijdvak kun je een value koppelen, bijv. 202009111315 voor het tijdstip 13.15 uur op 11 september 2020. Of in het geval van een tijdvak 2020091113151330.
Als de gebruiker het formulier submit, voer je een query uit en controleer je aam de hand van de value of het tijd/tijdvak nog vrij is. Ja, dan opslaan. Nee, dan opnieuw het formulier tonen met de beschikbare tijden/tijdvakken.
De gebruiker voert een datum in waardoor een AJAX request plaats vind waarmee ik check om welke dag het gaat en haal daarmee de start en eind tijd mee op.
Vervolgens word er voor elk kwartier een option element gemaakt welke ik dan met javascript in het select element zet zodat de gebruiker kan kiezen.
1) Regenereer je lijstje met tijden en kijk of de geselecteerde tijd in dit lijstje zit.
2) Controleer in de database of de betreffende datum+tijd nog vrij is.
Alhoewel het mbt 2) wel handig lijkt als je dit ook al op voorhand doet, zodat de gebruiker alleen de tijden te zien krijgt die nog vrij zijn.
En mbt 2) moet je sowieso achteraf / voor opslaan altijd een DB lookup doen (misschien heeft een andere gebruiker net datzelfde tijdstip gereserveerd, dus lijkt me dat je hier gewoon maar direct alles in de DB kunt controleren (dus ik zou geen "trucjes" toepassen om een DB lookup te besparen).
Nee, op het moment dat je de value ontvangt die bij de tijd hoort, dan check je direct in de database of de bijbehorende tijd vrij is. Zo ja, dan reserveer je direct de tbetreffende tijd in de database.
Je voert dus 2 queries achter elkaar uit. Die stap van een array maken zou ik overslaan.
@Ozzie: maar de beschikbare tijden staan (nog) niet in de database; alleen de begin- en eindtijd voor die dag. Op basis van de begin- en eindtijd moet je dus eerst het lijstje met opties weer regenereren om de check te kunnen doen.
