Sentry
Door Dbr Br, 18 jaar geleden, 3.871x bekeken
Update 04-02:
- Email-verificatie toegevoegd
- Minimaal aantal tekens toegevoegd: validateMinCharCount( $input, [limiet] );
- Maximaal aantal tekens toegevoegd: validateMaxCharCount( $input, [limiet] );
Simpel, klein, lichtgewicht class die (tot nu toe) controleert of een bepaalde input alleen cijfers, of cijfers en letters bevat.
Uitbreiding is mogelijk, kom maar op met suggesties!
Controle gaat gemakkelijk als volgt (voorbeeld):
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
$Sentry = new Sentry;
try{
$Sentry->validateMix( 'adajkdna8y2q;7839&^*&');
$Sentry->validateNum( '22;' );
}catch(Exception $Sentry){
echo $Sentry->getMessage();
}
?>
$Sentry = new Sentry;
try{
$Sentry->validateMix( 'adajkdna8y2q;7839&^*&');
$Sentry->validateNum( '22;' );
}catch(Exception $Sentry){
echo $Sentry->getMessage();
}
?>
Gesponsorde koppelingen
PHP script bestanden
Er zijn 11 reacties op 'Sentry'
0 
-0 
-0
Ehm, idee is goed, en opbouw ook wel.
Alleen, als je gegevens fout hebt ingevuld gelijk die(bam message) lijkt me niet de bedoeling. En bij validate staat kijhard in de code dat het om gebruikersgegevens gaan. Dat hoeft niet het geval te zijn. Voor de rest, uitbouwen ;-)
Alleen, als je gegevens fout hebt ingevuld gelijk die(bam message) lijkt me niet de bedoeling. En bij validate staat kijhard in de code dat het om gebruikersgegevens gaan. Dat hoeft niet het geval te zijn. Voor de rest, uitbouwen ;-)
0 -0
-0
Daarom is het OOP toepassen zo handig, errorfunctie veranderen naar wens en klaar is kees. Uitbouwen ligt inderdaad in de planning, maar zoals gezegd, suggesties zijn nooit weg :)
0 -0
-0
Quote:
Daarom is het OOP toepassen zo handig, errorfunctie veranderen naar wens en klaar is kees.
was dat een tip voor je zelf?? xD
0 -0
-0
Ik vind je voorbeeldje een beetje misleidend. Het if-statement suggereert dat de functie true of false terug gaat geven, maar het is meer true or die. Dat maakt het if-statement nogal overbodig :+
Verder zie ik hier de meerwaarde van een klasse niet zo. Zelf zie ik een klasse altijd als een object dat iets representeert, en dat een bepaalde staat heeft. Als het alleen maar een verzameling functies is, dan maak ik gewoon een verzameling functies (omdat een klasse dan toch geen meerwaarde heeft)
Die $enabled property is ook wat vreemd naar mijn idee. Hij wordt al in de constructor geraadpleegd, dus tijd om hem vanuit de code zelf anders in te stellen is er niet. Je moet de code aanpassen om hem aan of uit te zetten, en dat geldt dan meteen voor alle instanties van Sentry. Sowieso zal handmatig __destruct aanroepen geen effect hebben. $this unsetten heeft geen gevolgen voor de verwijzing naar de instantie die in $Sentry staat.
Als je hem dan aan en uit wilt kunnen zetten, doe het dan op zo'n manier dat je het per instantie kan regelen. Dan kan je bijvoorbeeld een instantie gebruiken voor het login-formulier, en eentje voor het zoekveld, en dan kan je die van het zoekveld uit zetten zonder dat daarmee ook het login-formulier onbeveiligd is.
Verder zou ik voor exceptions gaan in plaats van die, ook al is die alleen maar een voorbeeld. throw Exception is een nuttiger voorbeeld want daar kan je ook werkelijk wat mee :+ Misschien nog een beter idee is om de methods werkelijk true/false terug te laten geven, en de foutmeldingen (met details) in de instantie zelf op te slaan, in een property, $sentry->errors[] bijvoorbeeld. Dan kan je controleren of die leeg is of niet, en je kan ze makkelijk allemaal tegelijk weergeven boven je formuliertje. Of je kan hem gewoon negeren en de klasse gebruiken zoals jij in je voorbeeld doet suggereren.
(en gebruik geen private voor die unpure() method, protected is veel fijner als je hem wilt uitbreiden met nieuwe methods)
Verder zie ik hier de meerwaarde van een klasse niet zo. Zelf zie ik een klasse altijd als een object dat iets representeert, en dat een bepaalde staat heeft. Als het alleen maar een verzameling functies is, dan maak ik gewoon een verzameling functies (omdat een klasse dan toch geen meerwaarde heeft)
Die $enabled property is ook wat vreemd naar mijn idee. Hij wordt al in de constructor geraadpleegd, dus tijd om hem vanuit de code zelf anders in te stellen is er niet. Je moet de code aanpassen om hem aan of uit te zetten, en dat geldt dan meteen voor alle instanties van Sentry. Sowieso zal handmatig __destruct aanroepen geen effect hebben. $this unsetten heeft geen gevolgen voor de verwijzing naar de instantie die in $Sentry staat.
Als je hem dan aan en uit wilt kunnen zetten, doe het dan op zo'n manier dat je het per instantie kan regelen. Dan kan je bijvoorbeeld een instantie gebruiken voor het login-formulier, en eentje voor het zoekveld, en dan kan je die van het zoekveld uit zetten zonder dat daarmee ook het login-formulier onbeveiligd is.
Verder zou ik voor exceptions gaan in plaats van die, ook al is die alleen maar een voorbeeld. throw Exception is een nuttiger voorbeeld want daar kan je ook werkelijk wat mee :+ Misschien nog een beter idee is om de methods werkelijk true/false terug te laten geven, en de foutmeldingen (met details) in de instantie zelf op te slaan, in een property, $sentry->errors[] bijvoorbeeld. Dan kan je controleren of die leeg is of niet, en je kan ze makkelijk allemaal tegelijk weergeven boven je formuliertje. Of je kan hem gewoon negeren en de klasse gebruiken zoals jij in je voorbeeld doet suggereren.
(en gebruik geen private voor die unpure() method, protected is veel fijner als je hem wilt uitbreiden met nieuwe methods)
0 -0
-0
Ik ben het eens met Jelmer's argumenten, verder zie ik het nut hier totaal niet van in. Je hebt gewoon is_numeric, ctype, filter en dingen die je gewoon ter plekke in een if moet stoppen zoals checken van lengte van een var.
0 -0
-0
Bedankt voor de response, zolang hij nuttig is (Peter)!
Ben inderdaad bezig met het uitvogelen van Exceptions (mijn queste in PHP5 is in volle gang). Daarnaast had ik al een gevoel dat het unset($this) nutteloos was. Hierbij dus die bevestiging.
Het zou dus wenselijk zijn om bij het aanmaken der instantie een waarde 0 al dan niet 1 mee te geven, waarmee hij aan of uit staat? Misschien die functionaliteit maar helemaal weglaten aangezien het geen punt heeft om een instantie aan te maken en vervolgens zeggen dat ie uit staat.
Nu sta ik voor de keuze om
- of exceptions te gebruiken voor de errorhandling
- of een method aanhouden waarin een array wordt bijgehouden
Ik denk dat ik voor die exceptions ga. Zometeen een update.
Ben inderdaad bezig met het uitvogelen van Exceptions (mijn queste in PHP5 is in volle gang). Daarnaast had ik al een gevoel dat het unset($this) nutteloos was. Hierbij dus die bevestiging.
Het zou dus wenselijk zijn om bij het aanmaken der instantie een waarde 0 al dan niet 1 mee te geven, waarmee hij aan of uit staat? Misschien die functionaliteit maar helemaal weglaten aangezien het geen punt heeft om een instantie aan te maken en vervolgens zeggen dat ie uit staat.
Nu sta ik voor de keuze om
- of exceptions te gebruiken voor de errorhandling
- of een method aanhouden waarin een array wordt bijgehouden
Ik denk dat ik voor die exceptions ga. Zometeen een update.
0 -0
-0
Hmm, exceptions zijn eigenlijk voor onverwacht gedrag, en zijn handig omdat je ze gemakkelijk op een hoger niveau in je code kan afvangen. Of ze echt handig zijn voor het controleren van user-input...
Je zou kunnen stellen dat het controleren verwacht dat het goed of fout is, en dat een foute invoer dan ook niet als een onverwachte gebeurtenis moet worden gezien. In dat geval zijn exceptions waarschijnlijk niet op hun plaats. (omdat je dan een heleboel try-catch blokjes krijgt zoals je anders if-blokjes zou hebben)
Als je je klasse hebt bedoelt voor het controleren voor invoer, dan zou ik voor de array met errors gaan. Heb je hem bedoelt als controle-klasse die vooral voor de programmeur bevestigd dat er werkelijk gebeurt wat de programmeur denkt (waar bijvoorbeeld assert voor bedoeld is) dan zou ik voor de exceptions gaan, omdat dan foute invoer als onverwacht beschouwd kunnen worden.
Je zou kunnen stellen dat het controleren verwacht dat het goed of fout is, en dat een foute invoer dan ook niet als een onverwachte gebeurtenis moet worden gezien. In dat geval zijn exceptions waarschijnlijk niet op hun plaats. (omdat je dan een heleboel try-catch blokjes krijgt zoals je anders if-blokjes zou hebben)
Als je je klasse hebt bedoelt voor het controleren voor invoer, dan zou ik voor de array met errors gaan. Heb je hem bedoelt als controle-klasse die vooral voor de programmeur bevestigd dat er werkelijk gebeurt wat de programmeur denkt (waar bijvoorbeeld assert voor bedoeld is) dan zou ik voor de exceptions gaan, omdat dan foute invoer als onverwacht beschouwd kunnen worden.
0 -0
-0
1. Exceptions zijn voor uitzonderingen, niet voor verwachte resultaten (zoals Jelmer zegt)
2. Je moet al je functies statisch maken want er is geen reden om hier een object van te maken
Verder erg makkelijk voor mensen die nog geen validatiehelden en OOP-helden zijn.
2. Je moet al je functies statisch maken want er is geen reden om hier een object van te maken
Verder erg makkelijk voor mensen die nog geen validatiehelden en OOP-helden zijn.
0 -0
-0
wist niet dat je ## kon gebruiken als comment...
wat doet ## precies? one-liner net als // ?
wat doet ## precies? one-liner net als // ?
0 -0
-0
@toby hinloopen, het is eigelijk een enkele #. Dit is inderdaad een one-liner net als //
Voorbeeld:
Voorbeeld:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
# commentaar
// commentaar
/*
* commentaar
* nog meer
*/
?>
# commentaar
// commentaar
/*
* commentaar
* nog meer
*/
?>
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu