Een controle op <input type=number

>> Waarom die isNumber functie :)? Daar heeft JS gewoon isNaN voor ingebouwd (isNotANumber)

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.

Dank jullie voor de (zoals altijd snelle) reacties. Ik ga doen wat jullie zeggen. Eerst gebruikmaken van de mogelijkheden van HTML5, daarna als fallback gebruik maken van javascript.

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 ?

Voor de performance zal het verschil marginaal zijn: een controle op de ondersteuning van HTML5 brengt misschien zelfs meer overhead mee dan "blind" altijd hetzelfde stukje JavaScript uitvoeren.

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

function isNum(a){var b=(a.which)?a.which:a.keyCode;return(b>31&&(b<48||b>57))?false:true};

Ward,

Waarom heb je voor die code gekozen? ipv :

function isNum(a) {
   return !isNaN(a);
}

Ben even nieuwschierig, als er een goede reden voor is moet ik mischien mn code even beetje omkloppen

Okay, nog een laag checks er over heen. LOL
1[sup]ste[/sup] Check: HTML5
2[sup]de[/sup] Check: JavaScript
3[sup]de[/sup] 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.

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

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

Zo leer je nog eens iets, thnx.

qua controle in PHP.

kijk ook eens naar de filter_input functies:

<?php

if(filter_input(INPUT_POST, 'my_num_field', FILTER_VALIDATE_INT)) {
// ok
}
?>

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
1[sup]ste[/sup] Check: HTML5
2[sup]de[/sup] Check: JavaScript
3[sup]de[/sup] 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.

@Ozzie: Waarom is er nu javascript ooit bedacht! Om de GUI wat gebruikersvriendelijker te maken, en dat probeer ik dan ook. Ik hou mijn gebruikers (mijn klanten) liever tevreden. Klant is Koning !