Zend Validate UniqueField
Door Thijs Damen, 19 jaar geleden, 3.690x bekeken
origineel: http://www.chrisantoine.net/2008/07/14/uniquefield-validate-helper/
Aangepast zodat het ook daadwerkelijk werkt.
Dit is een toevoeging aan de Zend_Validate library die helaas niet de mogelijkheid bied (in 1.5) om een formveld te controleren tegen een database en aan te geven of deze waarde uniek is of niet. Aangezien dit toch wel erg veel gebruikt word ben ik op zoek gegaan naar een script. het script hieronder heb ik aangepast.
Gesponsorde koppelingen
PHP script bestanden
Er zijn 10 reacties op 'Zend validate uniquefield'
0 
-0 
-0
Handig!
Een paar dingen:
- Default staat er users en username als standaard, lijkt me niet verstandig. Liever een error gooien wanneer niet gezet
- Ik vind dat ie ook een model moet accepteren inplaats van de modelnaam.
Een paar dingen:
- Default staat er users en username als standaard, lijkt me niet verstandig. Liever een error gooien wanneer niet gezet
- Ik vind dat ie ook een model moet accepteren inplaats van de modelnaam.
Code (php)
1
array('UniqueField', false, array(new Users(), 'username'))
0 -0
-0
Code (php)
1
$result = $table->fetchAll($table->select()->where("$this->_fieldName = '$value'"))->toArray();
Gaat dit ook goed wanneer de door jou opgegeven $value quotes bevat?
0 -0
-0
En vergeet niet om een UNIQUE-constraint in je database aan te maken, dan wordt het onmogelijk om dubbele data op te slaan.
Vooraf controleren zal in 99,9999% van de gevallen wel werken, maar is niet 100% waterdicht. Een UNIQUE-constraint maakt de boel waterdicht, dan is het technisch onmogelijk om dubbele data op te slaan. Probeer je dat toch te doen, zal de INSERT of UPDATE-query keurig mislukken en een foutmelding geven dat er een UNIQUE-constraint is overtreden. Vaak krijg je ook exact te zien welke constraint dat is, kun je dus een prachtige foutmelding op geven.
Vooraf controleren zal in 99,9999% van de gevallen wel werken, maar is niet 100% waterdicht. Een UNIQUE-constraint maakt de boel waterdicht, dan is het technisch onmogelijk om dubbele data op te slaan. Probeer je dat toch te doen, zal de INSERT of UPDATE-query keurig mislukken en een foutmelding geven dat er een UNIQUE-constraint is overtreden. Vaak krijg je ook exact te zien welke constraint dat is, kun je dus een prachtige foutmelding op geven.
0 -0
-0
@Storeman:
Je hebt helemaal gelijk. ik had ze al uit mijn construct gehaald (origineel geeft daar zelf ook waardes mee.
voor je 2e comment. Misschien. maar op deze manier is het voor mij 100% customisable. ik kies ervoor om op deze manier te werken en in mijn models $_table mee te gaan geven.
Mocht jij het op een andere manier willen zul je het script moeten aanpassen.
@Jelmer:
Deze validator niet. maar deze validator is alleen verantwoordelijk voor het controleren van dubbele waardes in een database.
Ik controleer bijvoorbeeld ook niet stringlength, dat doet de andere validator. Voor quotes etc. kun je er gewoon een andere validator opgooien.
@pgFrank:
Jep:) Helemaal gelijk.
Je hebt helemaal gelijk. ik had ze al uit mijn construct gehaald (origineel geeft daar zelf ook waardes mee.
voor je 2e comment. Misschien. maar op deze manier is het voor mij 100% customisable. ik kies ervoor om op deze manier te werken en in mijn models $_table mee te gaan geven.
Mocht jij het op een andere manier willen zul je het script moeten aanpassen.
@Jelmer:
Deze validator niet. maar deze validator is alleen verantwoordelijk voor het controleren van dubbele waardes in een database.
Ik controleer bijvoorbeeld ook niet stringlength, dat doet de andere validator. Voor quotes etc. kun je er gewoon een andere validator opgooien.
@pgFrank:
Jep:) Helemaal gelijk.
0 -0
-0
@Thijs, ik bedoelde meer: gaat het goed wanneer ik een waarde met een quote invul, aangezien het er nogal op lijkt dat je de waarde gewoon zonder controle (of escapen van quotes) in de query stopt. Het origineel waar je naar verwijst gebruikte nog een prepared-statement achtige syntax waar je de query scheidt van de waarden.
0 -0
-0
Nee die zitten hier inderdaad niet in Jelmer.
maar dat komt vooral omdat dit een simpel voorbeeld is en simpel moet blijven.
ik voer op mijn username-input-veld 7 validators aan.
Een andere aanrader is ook HTMLPurifier te gebruiken. gaat leuk samen met zend en schoont alles netjes op.
maar dat komt vooral omdat dit een simpel voorbeeld is en simpel moet blijven.
ik voer op mijn username-input-veld 7 validators aan.
Een andere aanrader is ook HTMLPurifier te gebruiken. gaat leuk samen met zend en schoont alles netjes op.
0 -0
-0
Ik vind dit script juist een verkeerde interpretatie van Zend_Validate. Zend_Validate gebruik je in de applicatie-laag (application tier/logic) van je systeem. Deze laag moet input controleren en doorsturen naar je model (logica + data). Je hebt nu een validator (=voor input) gemaakt die niet de input valideert, maar controleert tegen je model. Dit is eigenlijk de volgende stap. Het is geen validatie meer, het is foutafhandeling maar dan omgedraaid (je controleert voordat je de fout maakt). Qua architectuur ben je zo dus juist bezig je MVC opzet te verpesten. Maar dit hangt af van de opzet van je architectuur en je interpretatie van MVC (als design pattern óf als architectuur).
Verder wel mooi script, goed om Zend Framework te zien.
Verder wel mooi script, goed om Zend Framework te zien.
0 -0
-0
Erik,
gedeeltelijk ben ik het helemaal met je eens. aan de andere kant natuurlijk niet.
Het is geen controle van de input van een gebruiker. Dat klopt en is daarom ook niet 100% een validator. maar wat het daarna doet klopt natuurlijk wel. het valideerd een waarde, in dit geval of deze al bestaat in een database.
Ik zou me zo eeerlijk gezecht ook niet 1.2.3. een voorstelling kunnen maken van hoe het dan wel te doen. Door het als een validator te gebruiken krijg ik namelijk de mogelijkheid om gewoon getMessages() te gebruiken voor al mijn foutmeldingen en tegelijk met alle andere validators foutmeldingen te geven. Het meest vervelende voor een gebruik is om na alles te hebben ingevuld en de eerste validatie niet succesvol was. nogmaals alles aan te passen om dan nogmaals een foutmelding te krijgen.
ps. een andere fout die ik maak is dat ik iets toevoeg aan de Zend Library. (Zend_Validate). om hem helemaal goed te maken zet je hem in library/Jeeigenfolder/Validate/UniqueField.php en kun je hem gebruiken via addValidator()
gedeeltelijk ben ik het helemaal met je eens. aan de andere kant natuurlijk niet.
Het is geen controle van de input van een gebruiker. Dat klopt en is daarom ook niet 100% een validator. maar wat het daarna doet klopt natuurlijk wel. het valideerd een waarde, in dit geval of deze al bestaat in een database.
Ik zou me zo eeerlijk gezecht ook niet 1.2.3. een voorstelling kunnen maken van hoe het dan wel te doen. Door het als een validator te gebruiken krijg ik namelijk de mogelijkheid om gewoon getMessages() te gebruiken voor al mijn foutmeldingen en tegelijk met alle andere validators foutmeldingen te geven. Het meest vervelende voor een gebruik is om na alles te hebben ingevuld en de eerste validatie niet succesvol was. nogmaals alles aan te passen om dan nogmaals een foutmelding te krijgen.
ps. een andere fout die ik maak is dat ik iets toevoeg aan de Zend Library. (Zend_Validate). om hem helemaal goed te maken zet je hem in library/Jeeigenfolder/Validate/UniqueField.php en kun je hem gebruiken via addValidator()
0 -0
-0
Ik vind het idee van dit object wel erg goed, maar ik zou de databaseafhankelijkheid denk ik weghalen. Want eigenlijk (volgens MVC-architectuur) zou je controller (en dus je validator) geen toegang moeten hebben tot Zend_Db_Table-objecten. Want je controller mag eigenlijk niet eens weten waar data vandaan komt. Het enige wat hij weet is dat hij het aan bepaalde Model-objecten moet vragen.
Dus in dat geval kun je beter een callback maken dan een Zend_Db_Table-object mee te geven. Dan ben je ook onafhankelijk van storage mechanisme (database, xml, file, webservice) en kun je het validatieobject ook gebruiken als je werkt met een data access service (sdo's) of met iets totaal anders.
Maar eerlijk toegegeven dit is één van de nuttigere scripts op PHPhulp.
Dus in dat geval kun je beter een callback maken dan een Zend_Db_Table-object mee te geven. Dan ben je ook onafhankelijk van storage mechanisme (database, xml, file, webservice) en kun je het validatieobject ook gebruiken als je werkt met een data access service (sdo's) of met iets totaal anders.
Maar eerlijk toegegeven dit is één van de nuttigere scripts op PHPhulp.
0 -0
-0
Ik weet dat dit geschreven is voor een oudere Zend versie, maar het lijkt me handig om het volgende te vermelden voor iedereen die dit topic via Google tegenkomt. In de huidige Zend versies is er standaard een validator aanwezig genaamd Db_NoRecordExists. Die gebruik je als volgt:
Code (php)
1
2
3
4
5
2
3
4
5
$username = new Zend_Form_Element_Text( 'username' );
$username->addValidator( 'Db_NoRecordExists', false, array(
'table' => 'users',
'field' => 'username'
) );
$username->addValidator( 'Db_NoRecordExists', false, array(
'table' => 'users',
'field' => 'username'
) );
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu