Class: Formulier Generator & Validator
Door Thijs X, 20 jaar geleden, 7.920x bekeken
Features:
- Genereren van een formulier
- Valideren van een formulier
Update
- Validatie ingebouwd
- setActie() aan toegevoegd ( in formulier klasse )
- Alternatief gebruikt voor filter_var mocht de PHP versie geen PHP 5.2 zijn
Tips en verbeteringen zijn altijd welkom!
Voorbeeld: http://php.ferket.net/formulier.php
Gesponsorde koppelingen
PHP script bestanden
Er zijn 22 reacties op 'Class formulier generator en validator'
0 
-0 
-0
Ik weet niet of jullie Formhandler kennen, maar die is zeer uitgebreid en heel handig.;)
0 -0
-0
Ja ik Formhandler wel maar ik maak toch het liefst alles zelf ;) Ik denk dat de meeste mensen hier hetzelfde doen.
Om er van te leren en/of alleen de juiste functies erin te hebben die je nodig hebt.
Om er van te leren en/of alleen de juiste functies erin te hebben die je nodig hebt.
0 -0
-0
Wat reacties op je OOP-stijl:
- Een klasse "Velden" noemen is niet echt handig, eerder verwarrend. 1 object representeert toch niet meerdere velden. Ik zou hier trouwens een interface voor gebruiken, aangezien je de methods die je in deze abstracte klasse definieert toch weer herdefinieert.
- In je klasse "Veld" hanteer je als eerste parameter, dat het type moet representeren een nummertje. Is het niet handiger om hier een constante voor te gebruiken in je code? Dan kan je tenminste zien wat voor soort veld je nu eigenlijk aan hebt gemaakt.
- Daarbij, waarom kan Veld van 4 verschillende typen zijn, terwijl bijvoorbeeld Select, Textarea, wat ook velden zijn, een aparte klasse hebben? Ik zou uitgaan van voor ieder soort veld een aparte klasse met al dan niet een bovenliggende klasse voor deze 4 velden die veel op elkaar lijken. (Dus stel, je maakt voor type="text" een klasse, dan extend je die voor type="password" weer)
- Zou het niet slim zijn om de veld-klassen zelf verantwoordelijk te houden voor het tekenen van het veld? Nu staat alle HTML in de klasse Formulier. Stel dat ik nu een eigen veld zou willen toevoegen, dan zou ik Formulier ook weer moeten aanpassen. Daarnaast zou ik voor alle gebruikte variabelen een accessor moeten maken (aangezien jij niet werkt met public properties) terwijl wanneer ik uit zou gaan van wat meer zelfstandige Veld-klassen ik alleen maar een draw() method nodig zou hebben.
- Persoonlijke ervaring: Gebruik bij voorkeur 'protected' voor eigenschappen die van de klasse zelf zijn en de eigenschappen definiëren. Op die manier kan je je bijvoorbeeld heel gemakkelijk een klasse extenden omdat je al toegang hebt tot alle benodigde eigenschappen. Ik denk dat je alleen maar eigenschappen die worden aangemaakt door de methods van een klasse, en verder nooit buiten de klasse zullen komen private hoeven te zijn. Bijvoorbeeld een $cache-array of een counter hoe vaak een bepaalde method is aangeroepen. Van die eigenschappen maken alleen de methods in die ene klasse gebruik, en alleen zijzelf.
- Voor jouw InvoerException bestaat al een Exception: InvalidArgumentException.
Verder, zou het niet mooi zijn om ook meteen de validatie in je setje klassen mee te nemen?
- Een klasse "Velden" noemen is niet echt handig, eerder verwarrend. 1 object representeert toch niet meerdere velden. Ik zou hier trouwens een interface voor gebruiken, aangezien je de methods die je in deze abstracte klasse definieert toch weer herdefinieert.
- In je klasse "Veld" hanteer je als eerste parameter, dat het type moet representeren een nummertje. Is het niet handiger om hier een constante voor te gebruiken in je code? Dan kan je tenminste zien wat voor soort veld je nu eigenlijk aan hebt gemaakt.
- Daarbij, waarom kan Veld van 4 verschillende typen zijn, terwijl bijvoorbeeld Select, Textarea, wat ook velden zijn, een aparte klasse hebben? Ik zou uitgaan van voor ieder soort veld een aparte klasse met al dan niet een bovenliggende klasse voor deze 4 velden die veel op elkaar lijken. (Dus stel, je maakt voor type="text" een klasse, dan extend je die voor type="password" weer)
- Zou het niet slim zijn om de veld-klassen zelf verantwoordelijk te houden voor het tekenen van het veld? Nu staat alle HTML in de klasse Formulier. Stel dat ik nu een eigen veld zou willen toevoegen, dan zou ik Formulier ook weer moeten aanpassen. Daarnaast zou ik voor alle gebruikte variabelen een accessor moeten maken (aangezien jij niet werkt met public properties) terwijl wanneer ik uit zou gaan van wat meer zelfstandige Veld-klassen ik alleen maar een draw() method nodig zou hebben.
- Persoonlijke ervaring: Gebruik bij voorkeur 'protected' voor eigenschappen die van de klasse zelf zijn en de eigenschappen definiëren. Op die manier kan je je bijvoorbeeld heel gemakkelijk een klasse extenden omdat je al toegang hebt tot alle benodigde eigenschappen. Ik denk dat je alleen maar eigenschappen die worden aangemaakt door de methods van een klasse, en verder nooit buiten de klasse zullen komen private hoeven te zijn. Bijvoorbeeld een $cache-array of een counter hoe vaak een bepaalde method is aangeroepen. Van die eigenschappen maken alleen de methods in die ene klasse gebruik, en alleen zijzelf.
- Voor jouw InvoerException bestaat al een Exception: InvalidArgumentException.
Verder, zou het niet mooi zijn om ook meteen de validatie in je setje klassen mee te nemen?
0 -0
-0
Jelmer bdankt voor je uitgebreide reactie!!
Echter zijn sommige dingen niet helemaal duidelijk.
- Wat bedoel je precies met een interface, welke classes zou jij zelf maken?
- Accessors heb ik express nog niet toegevoegd omdat het alleen nog maar het gereneren van het formulier was, als ik het ga uitbreiden met validatie heb ik dat inderdaad wel nodig.
Ga eens even kijken naar die InvalidArgumentException en hoe ik die het beste kan toepassen
Dus beste is om voor elk soort veld een classe te maken en dmv de __toString methode elke keer te overriden bij bijv: text, password, hidden. Omdat die worden extended van elkaar
Echter zijn sommige dingen niet helemaal duidelijk.
- Wat bedoel je precies met een interface, welke classes zou jij zelf maken?
- Accessors heb ik express nog niet toegevoegd omdat het alleen nog maar het gereneren van het formulier was, als ik het ga uitbreiden met validatie heb ik dat inderdaad wel nodig.
Ga eens even kijken naar die InvalidArgumentException en hoe ik die het beste kan toepassen
Dus beste is om voor elk soort veld een classe te maken en dmv de __toString methode elke keer te overriden bij bijv: text, password, hidden. Omdat die worden extended van elkaar
0 -0
-0
Ik blijf het vreemd vinden om 468 regels code te moeten gebruiken om een formuliertje van 44 regels te genereren... Kun je dan niet beter gewoon even het formuliertje typen?
Ik zie in dit geval het voordeel van de OOP klasse niet.
Ik zie in dit geval het voordeel van de OOP klasse niet.
0 -0
-0
Het is ook niet de bedoeling voor 1 formulier PHP Newbie maar wanneer je vaker in dezelfde applicatie gebruik maakt van formulieren.
Als je nou bijvoorbeeld iets wilt wijzigen in al je formulieren hoef je dat in dit geval maar in 1 classe te doen.
Als je nou bijvoorbeeld iets wilt wijzigen in al je formulieren hoef je dat in dit geval maar in 1 classe te doen.
0 -0
-0
@Thijs: In PHP5 kan je gebruik maken van interfaces. Dit zijn een soort regels, definities die een klasse kan implementeren. Maar wil die klasse dat mogen, dan moet hij voldoen aan alle regels van de interface. Zie deze tutorial.
Je gebruikt wel accessors, namelijk al die getXXX() methods. Wanneer je het tekenen door de klassen zelf laat doen, heb je in principe veel minder van deze methods nodig.
Een select-klasse zou ik dan weer niet laten afstammen van een input-type-field/password-klasse, want deze zijn wezenlijk anders. Maar een text/password-veld zijn vrijwel identiek. Daar zou dit dus prima kunnen.
@PHP Newbie:
In deze opzet is het ook nog niet echt voordelig. Echter, wanneer je er validatie instopt, en het bijvoorbeeld mogelijk maakt om op basis van een Model een formulier te laten genereren kan dit uiteindelijk best handig zijn. Wanneer je dan wijzigingen in je model doorvoert, hoef je niet al je formulieren te bewerken. En bij langere formulieren zal deze methode trouwens ook winnen aangezien je dan validatie, waarde controleren en invullen etc in 1 combineert. Het copy-paste gehalte is normaal enorm bij formulieren, hier niet. Maar voor een klein contact-formulier loont het de moeite inderdaad niet.
Je gebruikt wel accessors, namelijk al die getXXX() methods. Wanneer je het tekenen door de klassen zelf laat doen, heb je in principe veel minder van deze methods nodig.
Een select-klasse zou ik dan weer niet laten afstammen van een input-type-field/password-klasse, want deze zijn wezenlijk anders. Maar een text/password-veld zijn vrijwel identiek. Daar zou dit dus prima kunnen.
@PHP Newbie:
In deze opzet is het ook nog niet echt voordelig. Echter, wanneer je er validatie instopt, en het bijvoorbeeld mogelijk maakt om op basis van een Model een formulier te laten genereren kan dit uiteindelijk best handig zijn. Wanneer je dan wijzigingen in je model doorvoert, hoef je niet al je formulieren te bewerken. En bij langere formulieren zal deze methode trouwens ook winnen aangezien je dan validatie, waarde controleren en invullen etc in 1 combineert. Het copy-paste gehalte is normaal enorm bij formulieren, hier niet. Maar voor een klein contact-formulier loont het de moeite inderdaad niet.
0 -0
-0
Nieuwe Update.
- Word gebruik gemaakt van een Interface
- Alle HTML word per classe zelf bepaald en dmv de __toString methode naar het formulier gehaald
- Voor elk veld / button een apparte klasse aangemaakt, en de de dichtbijelkaar liggende velden worden extended van elkaar en de __toString methode overrided.
- Word gebruik gemaakt van een Interface
- Alle HTML word per classe zelf bepaald en dmv de __toString methode naar het formulier gehaald
- Voor elk veld / button een apparte klasse aangemaakt, en de de dichtbijelkaar liggende velden worden extended van elkaar en de __toString methode overrided.
0 -0
-0
Je mag bij InvalidArgumentException nog best vermelden welk argument fout is, en wat de eventuele oplossing is hoor :)
Je hebt op verschillende plekken de constructor van je klasse die je extend overschreven, maar alleen om vervolgens weer de overschreven variant aan te roepen? Je kan in bijv File & Password best de constructor helemaal weglaten. Hij pakt automatisch die van Text.
Je bent bij Submit nog vergeten je iPrintable te implementeren. Wat dat doet Submit wel, maar het staat niet vermeld.
Nu je die interface gebruikt, kan je die ook meteen gebruiken om bij Formulier::add af te dwingen dat je alleen printbare elementen kan toevoegen:
Code (php)
1
2
3
2
3
<?php
throw new InvalidArgumentException('$mxHeight moet een integer zijn en liggen tussen 30 en 50');
?>
throw new InvalidArgumentException('$mxHeight moet een integer zijn en liggen tussen 30 en 50');
?>
Je hebt op verschillende plekken de constructor van je klasse die je extend overschreven, maar alleen om vervolgens weer de overschreven variant aan te roepen? Je kan in bijv File & Password best de constructor helemaal weglaten. Hij pakt automatisch die van Text.
Je bent bij Submit nog vergeten je iPrintable te implementeren. Wat dat doet Submit wel, maar het staat niet vermeld.
Nu je die interface gebruikt, kan je die ook meteen gebruiken om bij Formulier::add af te dwingen dat je alleen printbare elementen kan toevoegen:
0 -0
-0
Wederom bedankt voor je reactie Jelmer,
Ga gelijk even aanpassen!
Dat je die constructor weg mocht laten wist ik niet eens, aangezien dat bij Java ook niet mag.
Ga gelijk even aanpassen!
Dat je die constructor weg mocht laten wist ik niet eens, aangezien dat bij Java ook niet mag.
Edit:
Geupdate!
Geupdate!
0 -0
-0
Mooie class!
Misschien ga ik alleen nu een domme vraag stellen: Wat is het nut van het gebruik van een interface? De functie __toString() wordt toch gwn overal gebruikt? Hoezo wordt die dan eerst toegekend aan een interface?
Misschien ga ik alleen nu een domme vraag stellen: Wat is het nut van het gebruik van een interface? De functie __toString() wordt toch gwn overal gebruikt? Hoezo wordt die dan eerst toegekend aan een interface?
0 -0
-0
@Bjorn: De interface wordt weer genoemd in Formulier::add. Dit dwingt af dat alleen objecten die de interface implementeren als argument gegeven kunnen worden. Klassen die de interface implementeren moeten een method genaamd __toString hebben. Zo weet je dus zeker dat alle objecten die via Formulier::add zijn toegevoegd een method genaamd __toString hebben.
0 -0
-0
Ahh ok, klinkt wel logisch. Bedankt voor de verheldering. Als ik nog 1 vraag moet stellen dan. Ik weet wat PHP_EOL doet, maar wat doet TAB?
0 -0
-0
Tab maakt gewoon een tab in je broncode aka \t, alleen met enkele quotes ( ' ) werkt dat niet vandaar dat ik hem even define bovenaan tussen dubbel quotes ( " ).
0 -0
-0
Nieuwe update:
- Validatie ingebouwd
- setActie() toegevoegd aan formulier classe
En nog paar kleine aanpassingen
Voorbeeld: http://php.ferket.net/formulier.php
- Validatie ingebouwd
- setActie() toegevoegd aan formulier classe
En nog paar kleine aanpassingen
Voorbeeld: http://php.ferket.net/formulier.php
0 -0
-0
Echt een mooi script Thijs, netjes volgens de styleguide ;-)
Ik heb alleen nog 1 klein dingetje, en je moet het zien als opbouwend kritiek...klassecommentaar/methodecommentaar is ervoor bedoelt dat iemand zonder naar de code te kijken weet wat de code doet...met andere woorden, als jij
@return String $dikketamme
in je commentaar hebt staan, dan weet degene die de documentatie uit PHPDoc leest nog niet wat er gebeurt. Dus, klein puntje daar...maak er iets van als
@return String Name of textfield
Verder geen op/aanmerkingen, ziet er echt netjes uit!
Ik heb alleen nog 1 klein dingetje, en je moet het zien als opbouwend kritiek...klassecommentaar/methodecommentaar is ervoor bedoelt dat iemand zonder naar de code te kijken weet wat de code doet...met andere woorden, als jij
@return String $dikketamme
in je commentaar hebt staan, dan weet degene die de documentatie uit PHPDoc leest nog niet wat er gebeurt. Dus, klein puntje daar...maak er iets van als
@return String Name of textfield
Verder geen op/aanmerkingen, ziet er echt netjes uit!
0 -0
-0
@ klystr
Bedankt voor de opmerking! Ik zal het wel veranderen naar het volgende:
Bedankt voor de opmerking! Ik zal het wel veranderen naar het volgende:
Code (php)
1
@return String $html, hier dan een omschrijving over de variabele
0 -0
-0
Groot beveiligings lek:
Als je het formulier faket (dmv Tamper Data, ff-extension) en sommige _verplichte_ velden niet mee laat sturen, dan merkt hij niet op dat er een _verplicht_ veld mist...
Als je het formulier faket (dmv Tamper Data, ff-extension) en sommige _verplichte_ velden niet mee laat sturen, dan merkt hij niet op dat er een _verplicht_ veld mist...
0 -0
-0
Thijs
Wat ik niet terugvind is de functie juistWachtwoord. Jij vraagt in je voorbeeld slechts een keer om het wachtwoord terwijl normaal gesproken het wachtwoord twee keer ingegeven moet worden om een evt typefout te tackelen. Als je dat kan inbouwen heb je volgens mij een mooie uitbreiding
Wat ik niet terugvind is de functie juistWachtwoord. Jij vraagt in je voorbeeld slechts een keer om het wachtwoord terwijl normaal gesproken het wachtwoord twee keer ingegeven moet worden om een evt typefout te tackelen. Als je dat kan inbouwen heb je volgens mij een mooie uitbreiding
0 -0
-0
Aangezien ik deze class wil gebruiken in combinatie met een loginsysteem, ben ik bezig met een extra validate function voor het vergelijken van de wachtwoorden. Dit is de functie:
Ik wou dit zo gaan gebruiken:
Maar het werkt nog niet echt. Wie kan me helpen? t zou een mooie toevoeging zijn aan dit systeem.
Code (php)
Ik wou dit zo gaan gebruiken:
Code (php)
Maar het werkt nog niet echt. Wie kan me helpen? t zou een mooie toevoeging zijn aan dit systeem.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu