Class: Formulier Generator & Validator
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
22 reacties op 'Class: Formulier Generator & Validator'
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 @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 @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 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 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.
- Details
Door:
Thijs X- 5 jaar geleden
- 875 x bekeken
- PHP scripts opties
- Overig
- Nieuwste PHP scripts
- PHP script toevoegen
PHP hulp
0 seconden vanaf nu