[Javascript] Checken van forms voor verzenden

[Jarige]

Ik probeer nou al een tijd een formulier te checken op de contents. Ik heb meerdere inputvelden waar getallen ingevuld moeten worden. Ik gebruik een Javascript script om elke input bij langs te gaan, en te controleren met Regular Expression er sprake is van een getal van 0 t/m 10 met maximaal 1 cijfer achter de komma (en in dit geval alleen nog maar een punt).
Er zijn vaak minimaal 10 inputvelden, en het aantal inputvelden is afhankelijk van een keuze die eerder is gemaakt.

Het gaat er om dat de input wordt gecontroleerd, of het aan de genoemde voorwaarden voldoet. Ik gebruik daarvoor dit script:

JavaScript:

<script type="text/javascript">
function checkForm(form) {
    var m = null;
    for (var x=4; form.elements[x]; x++ ) {
        if (form.elements[x].id != "nocheck") {
            var text = form.elements[x].value;
            var re =  /^([0-9]{1})(?:\.[0-9]{1})?(?:[0]{1})?$/g;
            m = re.exec(text);
            alert(m);
            if (m == null) {
                alert( "U bent vergeten een getal in te voeren, of een getal is niet correct ingevoerd in rij " + (x-4) );
                
                form.elements[x].focus();
                return false ;
            }
        }
    }
    return true;
}
</script>

(wist even niet hoe ik de code moest laten zien, heb maar quote gedaan, ziet er niet erg overzichtelijk uit)

Het formulier is op deze manier opgebouwd (versimpelt):

HTML:

<form method='post' action='index.php' onsubmit='return checkForm(this)'>
<input type="hidden" name="bla" value="bla" id="nocheck"/>       <!-- hier 4 van, met telkens een andere naam en value -->
<input type='text' name=getal[] value='' />         <!-- Hier dus een variabel aantal van -->
</form>

Het probleem is dat hij niet werkt. De eerste keer in de loop gaat hij altijd door, wat je ook invuld. De tweede keer (het tweede invoerveld) heeft hij altijd verkeerd. Ik heb de Regular Expression meerdere malen geprobeert op de handige site http://www.gskinner.com/RegExr/ en hij doet wat ik wil, behalve dan dat hij een getal met een komma nog fout rekent. Als iemand dat nog zou kunnen toevoegen zou ik daar ook blij mee zijn.
Wat is er fout aan het script? Hoe kan ik hem verbeteren?

Edit: Code tags toegevoegd.

[RobIII]

Jarige schreef op vrijdag 29 januari 2010 @ 14:05:
(wist even niet hoe ik de code moest laten zien, heb maar quote gedaan, ziet er niet erg overzichtelijk uit)

code tags

Verder: Een id dient binnen een pagina uniek te zijn; 4 x een "nocheck" id is dus niet goed.

Jarige schreef op vrijdag 29 januari 2010 @ 14:05:
Als iemand dat nog zou kunnen toevoegen zou ik daar ook blij mee zijn.

Kan iemand even...?

En verder: wat MueR hieronder zegt.

[ Voor 41% gewijzigd door RobIII op 29-01-2010 14:12 ]

[MueR]

Hoe post je code? / Hoe gebruik je de code tag?

Verder zul je hier moeten gaan debuggen. Snap je zelf wel waar je mee bezig bent? Vooral onderstaande regel komt op mij over als erg vreemd.

JavaScript:

for (var x=4; form.elements[x]; x++ )

edit:
* MueR mept RobIII

[ Voor 7% gewijzigd door MueR op 29-01-2010 14:10 ]

[Jarige]

Ik heb de code hiervandaan en daarna zelf aangepast:
http://www.joriso.nl/verh...avascript_form_check.html

Ik heb x=0 in x=4 veranderd aangezien de eerste paar inputs toch niet gecontroleerd hoeven te worden.

[Jarige]

Ik heb x=0 weer teruggezet, vervolgens de id's van de forms veranderd in 'nocheck1' enz.
Het nieuwe script is deze:

JavaScript:

<script type="text/javascript">
function checkForm(form)
{
    var m = null;
    for (var x=0; form.elements[x]; x++ ) {
        if (form.elements[x].id != "nocheck1") and (form.elements[x].id != "nocheck2") and (form.elements[x].id != "nocheck3") and (form.elements[x].id != "nocheck4") {
            var text = form.elements[x].value;
            var re =  /^([0-9]{1})(?:\.[0-9]{1})?(?:[0]{1})?$/g;
            m = re.exec(text);
            alert(m);
            if (m == null) {
                alert( "U bent vergeten een cijfer in te voeren, of een cijfer is niet correct ingevoerd in rij " + (x-4) );
                
                form.elements[x].focus();
                return false ;
            }
        }
    }
    return true;
}
</script>

[RobIII]

Jarige schreef op vrijdag 29 januari 2010 @ 14:27:
Ik heb x=0 weer teruggezet, vervolgens de id's van de forms veranderd in 'nocheck1' enz.

Waarom niet gewoon even kijken wat het type is en "hidden" velden overslaan en velden van het type "text" checken Daarbij zijn er slimmere constructies te bedenken dan 3 AND's (welke je overigens als && dient te schrijen)

Jarige schreef op vrijdag 29 januari 2010 @ 14:27:
Het nieuwe script is deze:

Geweldig. En doet 'ie het nu? En zo nee, heb je al gedebugged? (Debuggen: Hoe doe ik dat?) Ik zie zo al (naast de "and"'s die verkeerd zijn) dat je bijv. nog haakjes te kort komt in je if-constructie.

[ Voor 10% gewijzigd door RobIII op 29-01-2010 14:32 ]

[webinn]

ga gewoon debuggen met bv firebug. Doorloop je code stap voor stap en kijk waar het fout gaat. Er kan natuurlijk vanalles fout zijn en dat is op deze manier nu eenmaal moeilijk te zeggen

_{Roblll is sneller}

[ Voor 8% gewijzigd door webinn op 29-01-2010 14:32 ]

[Jarige]

Sorry vergat te zeggen dat hij nog steeds niet werkt. Stom van me dat ik er niet aan dacht om gewoon type='hidden' te gebruiken ipv die and's.
Nadat ik dit geimplementeerd heb werkte hij nog steeds niet. Nog nieuwere code (ik blijf bezig! )

JavaScript:

function checkForm(form)
{
    var m = null;
    for (var x=0; form.elements[x]; x++ ) {
        if (form.elements[x].type != "hidden") {
            var text = form.elements[x].value;
            var re =  /^([0-9]{1})(?:\.[0-9]{1})?(?:[0]{1})?$/g;
            m = re.exec(text);
            alert(m);
            if (m == null) {
                alert( "U bent vergeten een cijfer in te voeren, of een cijfer is niet correct ingevoerd in rij " + (x-4) );
                
                form.elements[x].focus();
                return false ;
            }
        }
    }
    return true;
}

[MueR]

vervolgens de id's van de forms veranderd in 'nocheck1' enz.

Je weet dat een ID unqiue moet zijn?

Jarige schreef op vrijdag 29 januari 2010 @ 14:35:
(ik blijf bezig! )

Wij niet. Ga debuggen. Klopt je regex, krijg je alle elementen die je wil valideren ook daadwerkelijk in je loop (maw klopt je loop).

[ Voor 55% gewijzigd door MueR op 29-01-2010 14:38 ]

[RobIII]

Jarige schreef op vrijdag 29 januari 2010 @ 14:35:
Nadat ik dit geimplementeerd heb werkte hij nog steeds niet. Nog nieuwere code (ik blijf bezig! )

En we gaan het "nog steeds" niet voor je fixen. Als je nou al eens aan kwam zetten met wat er niet werkt en wat je hebt geprobeerd om dat op te lossen etc. (Ik zie het overigens wel, we zitten hier alleen niet om alles voor je voor te kauwen). Je kunt wel steeds "nog nieuwere code" posten, maar we verwachten dat je zélf gaat debuggen (again: Debuggen: Hoe doe ik dat?)

MueR schreef op vrijdag 29 januari 2010 @ 14:36:
[...]

Je weet dat een ID unqiue moet zijn?

Dat zijn ze nu toch ook (en zei ik ook al )? Hij had nocheck1, nocheck2, nocheck3 en nocheck4. Maar dat is alweer overboord omdat heel dat ID overbodig is

MueR schreef op vrijdag 29 januari 2010 @ 14:36:
(maw klopt je loop).

De loop is, hoewel onconventioneel, in orde hoor
Het is "for ([initializer]; [condition]; [iterator-expression-dinges])". Die voorwaarde (condition) evalueert gewoon naar false als x "te hoog" wordt.

[ Voor 40% gewijzigd door RobIII op 29-01-2010 14:49 ]

[MueR]

RobIII schreef op vrijdag 29 januari 2010 @ 14:39:
Dat zijn ze nu toch ook (en zei ik ook al )? Hij had nocheck1, nocheck2, nocheck3 en nocheck4. Maar dat is alweer overboord omdat heel dat ID overbodig is

Stomme posteditert

De loop is, hoewel onconventioneel, in orde hoor

Hey, ik roep ook maar wat

[Jarige]

De id's zijn uniek aangezien ik ze heb weggehaald, en ik gebruik ze ook niet meer.
Ik heb behoorlijk lopen debuggen, de Regular Expression meerdere malen geprobeert, die is gewoon goed.

Ik heb zoveel dingen lopen te veranderen en te verklooien om vervolgens weer terug te zetten dat ik gewoon niet meer weet wat ik allemaal al geprobeert heb. Ik heb het topic over 'debuggen; hoe doe ik dat?' snel doorgekeken. Het geeft niet echt iets extra's waar ik me aan kan houden om te debuggen.

Nogmaals; ik heb hier al behoorlijk wat uren in zitten. Heb al iemand anders gevraagt die er ook niet uit kwam. Jullie kunnen me helpen, dat weet ik, en dat geeft RobIIl zelfs toe, ik heb geen tijd meer om er zelf uit te komen, en zoeken op internet gaf natuurlijk ook geen kant en klaar antwoord voor mijn probleem. Als ik hier naar toe ga (in alle gevallen dat ik hier iets heb gepost) ben ik zelf meestal ten einde raad, en heb ik al ontzettend veel geprobeert.

[RobIII]

Jarige schreef op vrijdag 29 januari 2010 @ 14:48:
Nogmaals; ik heb hier al behoorlijk wat uren in zitten. Heb al iemand anders gevraagt die er ook niet uit kwam. Jullie kunnen me helpen, dat weet ik, en dat geeft RobIIl zelfs toe, ik heb geen tijd meer om er zelf uit te komen, en zoeken op internet gaf natuurlijk ook geen kant en klaar antwoord voor mijn probleem. Als ik hier naar toe ga (in alle gevallen dat ik hier iets heb gepost) ben ik zelf meestal ten einde raad, en heb ik al ontzettend veel geprobeert.

En toch zal dat betoog je geen voorgekauwde kant-en-klaar oplossing geven hier In de Devschuur leven we volgens het principe:

Give a man a fish and feed him for a day. Teach a man how to fish and feed him for a lifetime.

[ Voor 24% gewijzigd door RobIII op 29-01-2010 15:02 ]

[Standeman]

Als ik jou was zou ik even kijken wat exec() nou precies doet.

[Jarige]

Ik weet wat exec doet. Dat gedeelte heb ik talloze keren met succes getest.
Bedankt voor de tips tot nu toe.

Met Firebug kan ik niet bepaald omgaan. Ik kan het script nergens vinden, misschien omdat hij pas uitgevoerd wordt nadat er op de submitknop druk? Anders zou ik namelijk niet weten waarom ik het script er niet in kan vinden...

Give a man a fish and feed him for a day. Teach a man how to fish and feed him for a lifetime.

Mee eens, maar dan moet je er wel van uit gaan dat elk mens verschillend is. Ga er bij mij maar van uit dat als ik de goede code zie, ik onmiddelijk zie wat ik fout heb gedaan, en hoe ik dat kan voorkomen in de komende keren. Ik ben niet dom, ik onthoud dit soort fouten en leer er van. Maar zonder oplossing kan ik niet leren.
Een duw in de goede richting is ook goed, maar doe het aub snel. Ik heb niet tijd in overvloed meer, hij moet binnenkort gewoon klaar zijn. Wat jullie in feite doen is me alleen een hengel geven zonder uit te leggen hoe ik moet vissen Ik kom een stapje verder, maar verder kom ik ook niet.

[RobIII]

g

Meer zeg ik niet Benieuwd wat je er van leert.

Jarige schreef op vrijdag 29 januari 2010 @ 15:53:
Een duw in de goede richting is ook goed, maar doe het aub snel. Ik heb niet tijd in overvloed meer, hij moet binnenkort gewoon klaar zijn.

Ho; je maakt van jouw probleem ons probleem. Zo werkt het natuurlijk niet.

[ Voor 213% gewijzigd door RobIII op 29-01-2010 16:50 ]

[webinn]

Jarige schreef op vrijdag 29 januari 2010 @ 15:53:
Met Firebug kan ik niet bepaald omgaan. Ik kan het script nergens vinden, misschien omdat hij pas uitgevoerd wordt nadat er op de submitknop druk? Anders zou ik namelijk niet weten waarom ik het script er niet in kan vinden...

Gouden tip van de dag: Breakpoints

[RobIII]

webinn schreef op vrijdag 29 januari 2010 @ 18:24:
[...]


Gouden tip van de dag: Breakpoints

Met een breakpoint ga je het deze keer niet redden als je niet weet waar (en waarom) het probleem zit

[Jarige]

quote: roblll

g

Meer zeg ik niet Benieuwd wat je er van leert.

Ongelovelijk -.- Een op het eerste gezicht zo'n nutteloze reply kan zo nuttig zijn. Vaak gekeken naar die rare g aan het eind van die variabele, maar diezelfde expression werkt wel gewoon op de eerder genoemde website. Ik dacht dus dat die wel in orde was. Blijkbaar niet -.-
Het enige probleem was dus die g.

Ik was voorbarig met de gedachte dat ik wel zou weten wat het probleem was als je me vertelde wat het probleem was. Ik heb gezocht, en die g staat voor global. Het zoekt globaal naar overeenkomsten, en hij geeft ze allemaal in een array. Door die zoektocht kwam ik er achter dat ik ook beter 'test' kon gebruiken. Die werkt sneller, en ik had toch geen info nodig over de matches. Ik neem aan dat het probleem zit in de vergelijking die ik daarna maakte; if (m == null)
Als m een array is gaat dit fout of niet? Heb ik gelijk? Ik kan er verder niet zo veel over vinden namelijk.

Bedankt voor de hulp Hierna liep ik nog tegen een klein probleempje aan; als alles was ingevuld gaf hij een foutmelding op rij 30 terwijl hij maar naar 29 ging. Ik heb dus maar een 'nocheck' id gemaakt voor de submit knop. Dat werkte.

Laat me wel even een opmerking maken dat jullie, waarschijnlijk onbedoeld, een indruk maken die een beetje uit de hoogte is. Net alsof het jullie in feite geen h*l kan schelen wat ik allemaal sta te blaten, jullie weten het toch beter. Of jullie het beter weten of niet, dat soort gedrag komt niet positief over, arogant zelfs. Ik wil niemand kwetsen hier, maar denk hier aub over na...

Nogmaals bedankt

[crisp]

inderdaad; exec() gebruik je als je informatie van de (sub)matches terug wilt krijgen. De global identifier zorgt er voor dat de volgende exec() begint na de laatste match (deze zet een lastIndex pointer) - dit gebruik je dus als je alle matches in een string wilt vinden door exec() in een loop te gebruiken totdat deze null teruggeeft (geen matches meer). Voor een simpele check die true of false teruggeeft kan je inderdaad het beste test() gebruiken.

[RobIII]

Jarige schreef op vrijdag 29 januari 2010 @ 20:05:
Als m een array is gaat dit fout of niet? Heb ik gelijk? Ik kan er verder niet zo veel over vinden namelijk.

Klik eens op in de betreffende post Het stond gewoon al die tijd recht voor je neus hoor

Jarige schreef op vrijdag 29 januari 2010 @ 20:05:
Laat me wel even een opmerking maken dat jullie, waarschijnlijk onbedoeld, een indruk maken die een beetje uit de hoogte is. Net alsof het jullie in feite geen h*l kan schelen wat ik allemaal sta te blaten, jullie weten het toch beter. Of jullie het beter weten of niet, dat soort gedrag komt niet positief over, arogant zelfs. Ik wil niemand kwetsen hier, maar denk hier aub over na...

Denk er ook eens even over na hoe het is als er iemand "op hete kolen" komt voor een oplossing die met een beetje simpel debuggen zélf prima op te lossen is. En dan zeker als je ons beleid kent qua Kan iemand even...? / scriptrequests. Ik had in eerste instantie ook niet door waar de (uiteindelijke) fout in zat, maar als ik dan al meteen een stapel fouten zie staan waar je gewoon meldingen over krijgt in een beetje JS console dan kan ik me niet aan de indruk ontrekken dat er überhaupt moeite gedaan is om iets op te lossen. Ook de conclusie die je trekt in je laatste post en die ik hier als eerst quote is, hoewel lovenswaardig by the way, gewoon met een paar alertjes prima zelf te testen. Dan had je gezien dat 't niet aan het wel of niet array-zijn van m ligt, en gezien dat er 'onverwachte' resultaten optraden bij de re.exec(). Dan had je meteen in die richting kunnen gaan zoeken. Net als ik deed. Ik kwam er zo achter:

Eerst strip-down naar "meest-basic":

JavaScript:

var re =  /^[0-9]$/g;  // Copy-paste uit dit topic, alle overbodige meuk uit de regex verwijderd
var a = ['1','1','1'];  // Simpele array
for (i=0; i<a.length; i++)
  alert(re.exec(a[i])); 

Output: 1, null, 1... WTF? 3 keer eenzelfde waarde, verschillende outputs -> Probleem iig gereproduceerd. Toen even goed gekeken; bleek er nog een g achter te staan die er niet hoorde. Uitleg waarom die daar niet hoort (en waarom je beter .test() kunt gebruiken): zie crisp of het begin van deze post Was toch wel 5 minuten werk.

De kunst van het debuggen, waar ik je al vrij vroeg in het topic op wees, is uitsluiten waar het wel/niet aan kan liggen en steeds verder "inzoomen op" of "pinpointen waar" het knelpunt zit. Testen met hele lappen irrelevante code of html er om heen maakt het alleen maar onduidelijk; weet je het probleem te localiseren in een paar regels code dan kun je véél gerichter zoeken. Naar mate je debug-kunsten vorderen kun je weer steeds beter door allerlei bomen heen kijken om een probleem te localiseren, maar zelfs de besten moeten zo nu en dan even een test-case bouwen om zeker te zijn dat ze zelf niet gek aan 't worden zijn

[ Voor 108% gewijzigd door RobIII op 29-01-2010 21:47 ]

[Jarige]

Je hebt gelijk met het debuggen. Het probleem was dus dat ik ff snel een website heb gevonden waarin ik zo'n regular expression had gemaakt zonder me meer te verdiepen in de verschillen tussen die van PHP en JS.
Verder was dit de eerste keer dat ik iets met JS heb gedaan, wat natuurlijk voor die rare oplossingen van me zorgde.
In de meeste forums is het vaak ook zo dat je gewoon een scriptrequest kan doen, ik moet zeer wennen aan het idee dat je hier bent om te leren ipv een snelle oplossing. Op zich heel goed natuurlijk dat je hier kan leren hoe het gaat, niets op tegen. In eerdere topics liep ik hier ook al tegen aan.

Ik heb trouwens een andere manier van debuggen (met PHP dan). Ik test namelijk veel, en vaak. Als ik een stukje heb getypt, 1 loop ofzo, dan sla ik op en test ik het onmiddelijk. Werkt dat niet dan ga ik debuggen. Volgens mij is dat tot dan toe nog redelijk normaal. Hoe kleiner je de stappen maakt, hoe geisoleerder de bug al is. Verder als je een grote loop hebt gemaakt de key variabelen zoals in die debug topic staat (eventueel meerdere malen) printen, en kijken wanneer de fout optreed. In het allerergste geval in je hoofd en met een papier (om variabelen en waarden te schrijven) de code bij langs gaan en alle stappen uit te voeren. Soms werkt zelfs dat niet, dan moet je een nachtje rust nemen, en de volgende dag zie je het in 5 minuten (heb ik gelukkig nog maar 1 keer gehad),
Veel debug prints, vooral print_r is ontzettend handig! Ik nam dezelfde houding aan bij JS. Behalve het letterlijk volgen met pen en papier. Van de output van de exec begreep ik niets, maar ik ging er van uit dat hij goed was. Ik had hem immers van een tutorial, en vervolgens zelf ietswat veranderd. De keuze van meerdere tutorialmakers voor exec ipv test is betreurenswaardig. Aangezien het op die manier meerdere malen op internet staat zullen veel beginnelingen onnodig in deze val trappen.

Nogmaals bedankt, en ik zal proberen de volgende keer meer zelf proberen op te lossen na aanleiding van de tips hier.