Een controle op <input type=number
Als ik nu in een numeriek veld 'aaa' invul, dan wordt daar een 0 van gemaakt en een 0 is toegestaan in mijn controles.
http://php.net/is_numeric en http://php.net/manual/en/function.ctype-digit.php
En voor HTML 5 hebben we:
Code (php)
1
2
3
4
2
3
4
<form action="iets.php">
Aantal: <input type="number" name="aantal">
<input type="submit" value="Versturen">
</form>
Aantal: <input type="number" name="aantal">
<input type="submit" value="Versturen">
</form>
De ondersteuning hiervan is inmiddels erg breed: http://caniuse.com/#search=number
Gewijzigd op 07/06/2015 21:17:25 door - Ariën -
Onthoud wel dat PHP validatie belangrijker is dan javascript.
Quote:
Als ik nu in een numeriek veld 'aaa' invul, dan wordt daar een 0 van gemaakt en een 0 is toegestaan in mijn controles.
Ik bedoelde: hoe blokkeer ik een numeriek inputveld van niet numerieke tekens. Ik vind het niet netjes dat gebruikers in een numeriek veld ook letters in kunnen vullen, wat dan vervolgens resulteert in een nul-waarde, omdat het een type=number is.
Vangen jullie dat af (hoe dan?) of vinden jullie dat geen problem ?
Toevoeging op 07/06/2015 23:38:26:
Dus hoe los ik dit op aan de clientside ?
Gewijzigd op 07/06/2015 23:39:23 door Paco de Wulp
Geen idee of dit de béste methode is, maar dit is denk ik wat jij bedoelt:
http://jsfiddle.net/Vj2Kk/2/
Code (php)
1
<input type="number">
Daaraan kun je een minimum en/of maximum toevoegen:
Code (php)
1
<input type="number" min="1">
Of:
Code (php)
1
<input type="number" min="1" max="100">
Verder kun je er nog een stapgrootte aan toevoegen. Voor veelvouden van 1 bijvoorbeeld:
Code (php)
1
<input type="number" min="1" max="100" step="1">
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
if(!ctype_digit($aantal)) // er mogen alleen cijfers gebruikt worden dus ook een nul :-)
{
//fout
}
?>
if(!ctype_digit($aantal)) // er mogen alleen cijfers gebruikt worden dus ook een nul :-)
{
//fout
}
?>
Ozzie PHP op 08/06/2015 01:26:01:
Even Googlen doet wonderen ;)
Geen idee of dit de béste methode is, maar dit is denk ik wat jij bedoelt:
http://jsfiddle.net/Vj2Kk/2/
Geen idee of dit de béste methode is, maar dit is denk ik wat jij bedoelt:
http://jsfiddle.net/Vj2Kk/2/
Waarom die isNumber functie :)? Daar heeft JS gewoon isNaN voor ingebouwd (isNotANumber)
Let er wel op dat dit een omgekeerde controle is dus true als het GEEN nummer is en false als het wel een nummer is. Als je dus is_numeric van php functionaliteit wil bereiken moet je !isNaN(nummer) doen
@Ozzie: Ik gebruik geen jQuery, maar zou het op die manier ook met javascript kunnen doen.
@Frank: Wanneer ik 'aaa32' in het numerieke veld invoer (<input type=number), dan is het in PHP (serverside)al een nul-waarde geworden. Natuurlijk doe ik in PHP checks op een geldige numerieke waarde.
Ik moet de 'aaa32' dus opvangen op cliëntside met Javascript of HTML5.
Voorstel van Ozzie is een oplossing (backspace, indien er een verkeerd teken wordt ingevoerd), maar ik zag ergens (weet niet meer waar) een oplossing zodat er in zijn geheel geen vreemde tekens konden worden ingevuld, totaal geblokkeerd, m.b.v. event onkeypress="return function();". Dit laatste lijkt me een mooie oplossing. Iemand zo'n oplossing voorhanden ? :-)
Toevoeging op 08/06/2015 11:00:07:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
<html>
<script>
function isNumberKey(evt){
var charCode = (evt.which) ? evt.which : event.keyCode
if (charCode > 31 && (charCode < 48 || charCode > 57))
return false;
return true;
}
</script>
<input name="someid" type="number" onkeypress="return isNumberKey(event)"/>
</html>
<script>
function isNumberKey(evt){
var charCode = (evt.which) ? evt.which : event.keyCode
if (charCode > 31 && (charCode < 48 || charCode > 57))
return false;
return true;
}
</script>
<input name="someid" type="number" onkeypress="return isNumberKey(event)"/>
</html>
Maar kan geloof ik ook maar alleen onder HTML5 werken !! mmmmmm
Gewijzigd op 08/06/2015 11:02:12 door Paco de Wulp
Paco de Wulp op 08/06/2015 10:46:41:
@Ward: Allemaal leuk en aardig, maar HTML5 wordt nog lang niet ondersteund door alle browsers. Dus dan zou je buiten de HTML5 checks, zoals jij voorstelt ook nog javascript checks moeten doen. Of te wel HTML5 checks kunnen net zo goed niet worden toegepast. Toch ?
Ja, dat is waar. Alleen mag de uiterste consequentie niet zijn dat je helemaal geen HTML5 gebruikt zolang er nog browsers zijn die HTML5 niet ondersteunen.
Ik denk dat je in dergelijke gevallen dus voor een compromis moet kiezen:
+ HTML5 voor moderne browsers
+ een fallback in JavaScript voor andere browsers
+ per definitie altijd een server-side validatie.
In HTML5 kun je overigens ook nog een pattern gebruiken bij een input, bijvoorbeeld voor bedragen met komma's. Alleen heeft dat hetzelfde nadeel: het is en blijft HTML5.
Voorbeelden: http://html5pattern.com/Miscs
Vandaar ook de disclaimer die er bij stond ;)
Anyhow, Paco ... ik zou voor de 'native' HTML5 oplossing gaan. Dan hoef je ook geen extra javascript te implementeren (waar je site weer iets trager van wordt). Mensen met een wat oudere browser hebben dan gewoon pech. Het is geen fnuctionaliteit die het gebruik van de website beperkt.
Daarnaast kun je ook aangeven, als dat nodig is, dat er alleen cijfers gebruikt mogen worden. In sommige gevallen is dat niet eens nodig, bijv. als de omschrijving van het veld "Aantal" is. Als mensen dan alsnog letters invullen is het hun eigen "fout". En in gevallen waar het niet geheel duidelijk is, schrijf je achter het invoerveld "(alleen cijfers)". De extra HTML5 controle helpt dan nog een keer extra bij mensen met een moderne browser, en bij mensen met een oudere browser die toch niet goed opletten, heb je de fallback van je serverside controle.
Toch nog een vraagje:
Maakt en dan ook niet uit (qua performance) dat de checks eventueel 2x worden gedaan (eerst HTML5 en vervolgens Javascript) of kan je dit misschien ook omzeilen, door eerst te checken of een browser HTML5 gebruikt of niet ?
In mijn blog heb ik hiervoor stap-voor-stap een micro-optimalisatie uitgewerkt:
http://bloknood.blogspot.nl/2013/06/alleen-invoer-van-getallen-accepteren.html
Code (php)
1
function isNum(a){var b=(a.which)?a.which:a.keyCode;return(b>31&&(b<48||b>57))?false:true};
Waarom heb je voor die code gekozen? ipv :
Code (php)
1
2
3
2
3
function isNum(a) {
return !isNaN(a);
}
return !isNaN(a);
}
Ben even nieuwschierig, als er een goede reden voor is moet ik mischien mn code even beetje omkloppen
1ste Check: HTML5
2de Check: JavaScript
3de Check: PHP
Moet niet gekker worden....
Gelukkig geldt zulke zooi niet aan de achterkant(serverside) of eigenlijk ook wel (PHP-checks, MYSQL-checks). O.M.G.
Daarnaast heeft isNaN() een slechte "track record" bij het consistent afhandelen van niet-numerieke waarden. Dat maakt het gedrag voor cross-browser compatibiliteit onvoorspelbaar:
https://developer.mozilla.org/nl/docs/Web/JavaScript/Reference/Global_Objects/isNaN
Ward van der Put op 08/06/2015 15:00:21:
Vooral om de functie te kunnen aanpassen: afhankelijk van de applicatie wil ik soms bijvoorbeeld een komma kunnen accepteren voor bedragen. Daarom controleer ik op de keyCode.
Daarnaast heeft isNaN() een slechte "track record" bij het consistent afhandelen van niet-numerieke waarden. Dat maakt het gedrag voor cross-browser compatibiliteit onvoorspelbaar:
https://developer.mozilla.org/nl/docs/Web/JavaScript/Reference/Global_Objects/isNaN
Daarnaast heeft isNaN() een slechte "track record" bij het consistent afhandelen van niet-numerieke waarden. Dat maakt het gedrag voor cross-browser compatibiliteit onvoorspelbaar:
https://developer.mozilla.org/nl/docs/Web/JavaScript/Reference/Global_Objects/isNaN
Zo leer je nog eens iets, thnx.
kijk ook eens naar de filter_input functies:
http://php.net/filter-input
(dit geeft trouwens geen melding als $_POST['my_num_field'] ontbreekt, maar aangezien het dan geen nummer is, is dat geen ramp)
Paco de Wulp op 08/06/2015 14:50:53:
Okay, nog een laag checks er over heen. LOL
1ste Check: HTML5
2de Check: JavaScript
3de Check: PHP
Moet niet gekker worden....
1ste Check: HTML5
2de Check: JavaScript
3de Check: PHP
Moet niet gekker worden....
Ik zou die javascript check dan ook laten vervallen. Accepteer het feit dat het in oude browsers niet werkt. Maar dat is geen probleem want je serverside controle vangt dit af. Die oude browsers worden vanzelf vervangen en dan werkt het wel. Het is geen functionaliteit waardoor de code niet meer werkt. En als je dan toch zo ver gaat. Realiseer je ook dat er browsers/mensen zijn die geen javascript ondersteunen. Dus 100% waterdicht zul je het aan de cliënt kant nooit krijgen. Ik zou voor de oplossing gaan die toekomstbestendig is, en niet voor houtje-touwtje materiaal omdat een kleinere groep mensen een verouderde browser gebruikt. Maar goed, dit is mijn mening dus.