[js] Form validatie

[Clay]

Waar ik (en ik denk iedereen) in Js de grootste hekel aan heb is form validatie. Nou had ik het gister met iemand erover dat die dat nooit deed omdat je toch altijd wel kan omzeilen, maar daar ben ik het niet helemaal mee eens, en soms is die keuze niet eens aan jezelf of je client side validatie moet maken of niet.

Op zich zou het dan tof zijn als je een soort JS module zou kunnen schrijven, die een formvalidatie Object bevat die je met een paar regels kan aanspreken:

code:

// pseudo meuk

validator = new formValidator('formNaam');
validator.setCheck('elementNaam', RegExp);

Nou is dit nog wel redelijk makkelijk te maken, ook zo dat je inderdaad niet kan submitten als je foute dingen invult. Wat al moeilijker wordt zijn kruislinkse regels als "als je dit veld leeg laat mag je dat veld niet invullen" die je meestal met onchange/blur wat dan ook maakt.
Alleen, als je dit WEL weet te maken, dan ben je voor altijd van die ellendige formvalidatie af:

code:

// meer pseudo meuk

validator.setRule('if isempty produkt disable aantal else enable aantal');

Zoiets bijvoorbeeld. Dit zou die JS module dan moeten omzetten naar goeie js code, en door een eval halen oid. Dan zou je uiteindelijk een validatie hebben als:

code:

// online bestellen oid

validator = new formValidator('bestelForm');
validator.setCheck('produkt', RegExp);
validator.setCheck('aantal', RegExp); 

validator.setRule('if isempty produkt disable aantal else enable aantal');

En verder niets. Dat zou toch tof zijn?

[Dennis]

Op vrijdag 25 januari 2002 09:38 schreef Clay het volgende:
En verder niets. Dat zou toch tof zijn?

Heb je een nieuw project in gedachten Clay ?

[Clay]

Lijkt me iig wel handig om te maken ja als het kan waarom niet.

[Verwijderd]

Het enige wat ik zeg is: waarom het bij de validatie houden?

[Dennis]

Op vrijdag 25 januari 2002 09:49 schreef Blues het volgende:
Het enige wat ik zeg is: waarom het bij de validatie houden?

Jij wilt zeker ook dat ie dan alles emailt

[Verwijderd]

Op vrijdag 25 januari 2002 09:38 schreef Clay het volgende:

Dat zou toch tof zijn?

Jazeker, ik ben ook een voorstander van modules schrijven die je met enkele regels in kunt voegen.

Maar nu ik er even over nadenk, zul je waarschijnlijk met recursieve functies moeten gaan werken, om het waterdicht te krijgen. Ik hoop dat je begrijpt waar ik op doel?

(Ik zit ook te denken: je kunt aan objecten later not methods toevoegen, dmv prototyping toch? Kun je dat ook voor elkaar krijgen met objects als form elementen? Dat zou de snelheid heel erg ten goede komen denk ik)

[crisp]

Je zou voor je rules een soort eigen syntax moeten maken waarmee je alle voorkomende zaken kan afhandelen.
Dit soort dingen heb ik al eens eerder gemaakt (in RPG op AS/400 welliswaar).

Misschien zoiets:

code:

if <field> <operator> <field>|<constant>|<specialvalue>
[<and>|<or> <field> <operator> <field>|<constant>|<specialvalue>]..
<field> <action> [<actionvalue>]
[; <field> <action> [<actionvalue>]]..

voorbeeld:

code:

validator.setRule('if product == isempty aantal disable');
validator.setRule('if product != isempty aantal enable');
validator.setRule('if name != isempty name setstyle color=red');

[RM-rf]

goed idee, maar heb wat vraagjes/opmerkingen/ideetjes:

code:

validator = new formValidator('formNaam');
validator.setCheck('elementNaam', RegExp);

dat zou enkel checks mogelijk maken met regEx-en, persoonlijk denk ik dat checks redelijk uitgebreid kunnen worden:
validator.setCheckInteger('elementnaam'[, 'minValue', 'maxValue'])
validator.setCheckEmail('elementnaam')
validator.setCheckRegEx('elementnaam', 'regEx')

code:

validator.setRule('if isempty produkt disable aantal else enable aantal');

zo'n soort van 'pseudo'-code als variabele in de code lijkt me niet prettig (ook in xsl vindt ik dit soms wat verwarrend) verder lijkt het me dat zoiets met evals ofwel met regEx-en gefiltered zou moeten worden;
beter lijkt het me met losse variabelen te werken:

code:

validator.setDependancyRule('produkt', '', 'aantal', 'disable');

als laatste;
het lijkt me dat ook aandacht moet worden besteed aan de action, validatie gebeurt niet enkel pas bij submit, en de submit true geven is ook niet altijd het doel, afhankelijk van de soort check zou het ook mogelijk moeten zijn om een specifiek andere actie te geven (zodra selectbox is aangevinked, maak die layer hidden en die layer zichtbaar)

[Woudloper]

Clay: En verder niets. Dat zou toch tof zijn?

Helemaal gelijk.... Dit zou erg handig zijn!

RM-rf:
persoonlijk denk ik dat checks redelijk uitgebreid kunnen worden.

[..]

zo'n soort van 'pseudo'-code als variabele in de code lijkt me niet prettig (ook in xsl vindt ik dit soms wat verwarrend) verder lijkt het me dat zoiets met evals ofwel met regEx-en gefiltered zou moeten worden;

beter lijkt het me met losse variabelen te werken:

code:

validator.setDependancyRule('produkt', '', 'aantal', 'disable');

Ik ben het met RM-rf eens dat je beter met losse variabelen kan werken, want met pseudo-code werken maakt het alleen maar verwarrrend...

[Clay]

Ik weet niet in hoeverre je ueberhaupt van pseudo code af kan komen, een rule is zowiezo iets wazigs wat nooit hetzelfde is, en zal altijd vertaald moeten worden naar een stuk code wat echt wat betekent in js. Het lijkt mij dat juist als je dat in zon zin zet (syntax kan je idd gewoon helemaal zelf verzinnen dan) dat je veel verschillende soorten dingen kan laten gebeuren.

zo zou

code:

'if isempty produkt disable aantal else enable aantal'

// vertaald worden naar:
if(isEmpty('produkt')) { disable('aantal') ....

en hoef je in je "module" alleen je isEmpty, disable, e.d. functies te defineren, krijg je ook niet zo'n lading code.

Selects/check/radio zou je kunnen checken met iets als:

code:

if selected land:nederland then ....

// vertaald
if(isSelected('land', 'nederland')) { ...

en ook voor het uitvoeren van custom functies is dan echt wel wat te vinden. Integer max/min checks moeten er uiteraard ook in ja.

Wanneer je deze checks laat uitvoeren is denk ik niet echt een probleem. je kan overal waar je wil onchange/blur dingen toekennen in de module. Rules vind ik typisch iets voor onchange/blur, terwijl dat met gewone checks niet echt hoeft, maar natuurlijk wel kan.

[Annie]

Er is inderdaad niets zo erg als voor de 100e keer een simpele if bla is ingevuld then controle te schrijven. Ik heb hiervoor al eens een basis checkgenerator geschreven aan de server-side waar je voor alle velden definieert welk type het is (numeriek, datum, verplicht/niet verplicht). De functie gooide de benodigde javascript naar de browser. Heel simpel opgezet maar het neemt je al wel veel werk uit handen.

Het zou inderdaad mooi zijn als er iets te verzinnen is (natuurlijk ) waarbij je voor invoervelden alleen definieert wat de eigenschappen van het element zijn en eventueel wat de relatie is van dat element met andere elementen (de rules).

Natuurlijk moet de mogelijkheid van maatwerkuitbreidingen van het form nog wel blijven bestaan.

Dus bijv voor een simpel numeriekveld wat verplicht is en max 50 mag zijn:

code:

var oValidator = new formValidator(document.forms[0]);
oValidator.defineField('naam', 'number', 0,   50,  true);
//              |    |    |    |    |
//              veld    type     min  max  required

En dat je daarmee klaar bent.

'Exotische' uitbreidingen / uitzonderingen moet je dan makkelijk aan de validator kunnen hangen, maar moeten niet verplicht worden (anders blijf je alsnog veel werk doen).

Helemaal mooi wordt het als alle onchange/onkeydown onzin lostrekt van de feitelijke <form> htmlcode. Zodat evt. html-ers geen last hebben van de js-brouwsels die hier verzonnen worden.

[oh,when?]

formvalidation clientside blijft natuurlijk jezelf voor de gek houden, maar om dan toch nog mijn 2 cents toe te voegen. (btw ik heb het toch al een keer met jou over gehad Clay? )

Omdat niet iedereen een regular expression koning is (incl me) zat ik zelf meer te denken aan wat standards methods:

code:

form = new FormValidator('name');
form.checkEmail('elementname');
form.setBounds('elementname',min,max);

if (!form.isEmpty('elementname')) { return false; }

wat nog grappiger is als je natuurlijk een virtueel form bouwt en die dan in een keer output:

code:

form = new Form('name');
form.addValidation();
form.addElement{'name',email', doCheck());

// en helemaal mooi

form.addElement('name', select, hasChilds);
name.appendChild('waarde van select', 'textelement');
name.appendChild('waarde van select', 'textelement', selected);
form.addElement('name', select, close);

// en nu outputten
form.parse(this);

en voila..een formulier met formvalidation

* oh,when? gaat weer verder met werken...

[Clay]

oh,when?:
Omdat niet iedereen een regular expression koning is (incl me) zat ik zelf meer te denken aan wat standards methods:

om verschillende functies te gebruiken voor iets wat eigenlijk steeds hetzelfde doet vind ik niets, die regexps kan je ook aanbieden in constanten als string:

code:

validate.setCheck('email', MAIL_CHECK [, required, min, max])

maar als je al die parameters in 1 functie plempt wordt het ook zo'n janboel idd, dus een paar verschillende types checks is misschien wel handig, toch denk ik dat je dan aan 2 methodes wel genoeg hebt.

code:

validate.setCheck('email', MAIL_CHECK [, required]);
validate.setBounds('aantal', min, max [, required]);

De setBounds voert dan zelf een check uit of je ook werkelijk een getal hebt ingevuld, en verder ga ik me echt focussen op die rules want dat moet nou juist die lappen validatie die je normaal gesproken zou moeten schrijven overbodig maken.

ik snap het voordeel van het setDependancyRule voorbeeld toch nog niet echt. Ook hier wil ik met 1 functie volstaan, die de rule set. En hoe zou je dan gebruiksvriendelijk een methode opzetten waar je met enkel losse argumenten zowel selects, inputdisabling, radio's en alles oplost?

bijvoorbeeld:

code:

validate.setRule('if selected carType:ford or isempty age then disable insurance');
validate.setRule(if not selected carType:audi then select payPer:month);

Dat zijn 2 totaal verschillende dingen, hoe zou je dat met een setDependancyRule oplossen?

[Blue-eagle]

toevallig dit! Ik heb ook vandaag zo`n probleem gehad met form validatie. Ik moest dus een form controleren mbv een functie die makkelijk en goed werkt, alleen hij controleerd alleen of er iets in een form element staat, die aangegeven zijn in de "myFunction.arguments" collectie.
Helaas moest ik met de leuke "return" in js ook nog een tweede functie combineren.. dat werd dus na 30 min denken en proberen het volgende:
men schrijft een functie die twee functies combineert en daaruit een true of een false terug geeft. Aan de hand daarvan bepaald het formulier wat ie gaat doen. Helaas werd de foutmelding minder netjes, op zijn zachtst gezegd

Met andere, en veel kortere, woorden: kickass projectje dit. En nuttig ook

[Verwijderd]

code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>

    <head>
        <meta http-equiv="content-type" content="text/html;charset=iso-8859-1" />
        <title>template</title>
        <script type="text/javascript">
            function formValidator(formName, formFields)
            {
                this.name = formName;
                this.fieldName = new Array(formFields);
                this.fieldCondition = new Array(formFields);
                this.element = 0;
                
                this.setCheck = function(name, condition)
                {
                    this.fieldName[this.element] = name;
                    this.fieldCondition[this.element] = condition;
                    this.element++;
                }
            }
            
            function validate(caller)
            {
                for (var i = 0; i < caller.element; i++)
                {
                    switch (caller.fieldCondition[i])
                    {
                        case 'word':
                            if (!isWord(caller.fieldName[i])) return false;
                            break;
                        case 'number':
                            if (!isNumber(caller.fieldName[i])) return false;
                            break;
                        default:
                            break;
                    }
                }
                return true;
            }
            
            function isWord(fieldName)
            {
                fieldValue = document.forms['testform'].elements[fieldName].value;
                if (fieldValue.length == 0) return false;
                
                for (var i = 0; i < fieldValue.length; i++)
                {
                    code = fieldValue.charCodeAt(i);
                    if ((code < 65) || (code > 122)) return false;
                    if ((code > 90) && (code < 97)) return false;
                }
                return true;
            }
            
            function isNumber(fieldName)
            {
                fieldValue = document.forms['testform'].elements[fieldName].value;
                return !isNaN(fieldValue);
            }

        </script>
    </head>

    <body>
        <form id="testform" action="" onsubmit="alert(validate(validator)); return false;">
            <input id="username" type="text" value="Cheatah" /><br />
            <input id="password" type="password" value="43646" /><br />
            <input type="submit"><br />
        </form>
        <script type="text/javascript">
            validator = new formValidator('testform', 14);
            validator.setCheck('username', 'word');
            validator.setCheck('password', 'number');
        </script>
    </body>

</html>

Dit is een eenvoudige versie, hierin zit nog absoluut geen enkele vorm van interactie russen formuliervelden, maar in ieder geval kun je met zulke 'plugin' functies als isWord en isNumber al eenvoudig zeggen wat een enkel formulierveld moet/mag zijn.

Volgens mij heb je heel veel functies nodig wil je het universeel bruikbaar maken, maar dat is gewoon een kwestie van iedere keer iets toevoegen.

En zoals Annie zei: er moet zo weinig mogelijk javascript in de source komen, zodat iemand die er weinig vanaf weet het ook kan gebruiken.

[oh,when?]

Op vrijdag 25 januari 2002 19:53 schreef Clay het volgende:

maar als je al die parameters in 1 functie plempt wordt het ook zo'n janboel idd, dus een paar verschillende types checks is misschien wel handig, toch denk ik dat je dan aan 2 methodes wel genoeg hebt.

code:

validate.setCheck('email', MAIL_CHECK [, required]);
validate.setBounds('aantal', min, max [, required]);

De setBounds voert dan zelf een check uit of je ook werkelijk een getal hebt ingevuld, en verder ga ik me echt focussen op die rules want dat moet nou juist die lappen validatie die je normaal gesproken zou moeten schrijven overbodig maken.

ff korte reply want ben zo weer weg. Ik heb al een mooie regular expression voor jou voor je email:

code:

^(([^<>;()[\]\\.,;:@"]+(\.[^<>()[\]\\.,;:@"]+)*)|(".+"))@((([a-z]([-a-z0-9]*[a-z0-9])?)|(#[0-9]+)|(\\[((([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\.){3}(([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\]))\.)*(([a-z]([-a-z0-9]*[a-z0-9])?)|(#[0-9]+)|(\\[((([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\.){3}(([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\]))$

volgens RFC 821...alsje

[Blue-eagle]

Oh,When? heb je voor die regexes ook een prog? Ik ken um niet iig als `t freeware is, wil je me dan de naam ervan geven? Tnx in advance.

Iemand anders mag trouwens ook.

[Clay]

geen idee eigenlijk of er progs zijn voor regexpen, maar dat zijn eigenlijk gewoon een paar redelijk simpele regeltjes die je moet combineren.

hiero staat zo'n beetje alles erover. 't ziet er raar uit, maar het is wel heel handig.

[Clay]

Hier staat een test versie met werkende rules. Als je in het eerste veld "bus" invult doet de select dat ook, en het disabled merk/motorinhoud al naar gelang de ingevulde dingen. Er zitten alleen nog wat haken en ogen aan,

• moz struikelt over de onchange dinges, dus het werkt nog niet.
• met select kan je een item uit een dropdown laten selecteren, maar dat forceert geen onchange als die dropdown zelf een rule heeft, heb ik wel geprobeerd, maar dat crashed Ie5 w000t
• je kan (nu) maar 1 functie achter then doen
• als een element meer dan 1 rule heeft worden alle rules uitgevoerd van de hele validatie uitgevoerd, moet ik ook nog wat op vinden.
• dit gaat (onchange/blur) hoe dan ook conflicteren met normale validatie, dus waarschijnlijk moet de onchange een soort element-validatie objectje gaan aaspreken waar zowel checks als rules inkunnen.

maar het principe werkt iig vaarwel ellendige formvalidatie

[Blue-eagle]

Op zaterdag 26 januari 2002 14:31 schreef Clay het volgende:
..knip..

Wow! Die ziet er echt vet uit! Cool gedaan. Vind je het erg als ik het script overneem om wat dingen mee te proberen? M`n JS kennis kan wel een kick gebruiken

[Clay]

Is goed, maar ik ga het nog flink herschrijven, want de onchange moet wel werken op checks en meerdere rules. Dus waarschijnlijk wordt het helemaal anders

[Blue-eagle]

Op zaterdag 26 januari 2002 15:45 schreef Clay het volgende:
Is goed, maar ik ga het nog flink herschrijven, want de onchange moet wel werken op checks en meerdere rules. Dus waarschijnlijk wordt het helemaal anders

En radio buttons/checkboxes? Ik ga eens kijken hoe het script daarmee kan werken

[Verwijderd]

Ik heb intussen juist wat gespeeld met regexen enzo, om oa een eenvoudigere check per veld te maken.

Hier zie je een eenvoudig voorbeeld. Alleen wil ik die onchange daar weghebben, die is voor ieder veld zeg maar gelijk. Misschien kan Clay me vertellen hoe dat moet? Iets met attachEvent ofzo?

Maar als dat eenmaal werkt kun je heel eenvoudig nog wat regexen toevoegen, en zoals je ziet is er amper script nogig om de zooi te initialiseren, net als in de form van Clay. Misschien een idee om die checks per veld te implementeren?

En owja: heel erg bedankt voor die link naar regexen, die is zeer duidelijk

[Clay]

kewl

Maar ik denk niet dat je van die onchange setters afkomt, misschien dat het terug te brengen is naar een onchange = referentie; ipv een hele functie eraan hangen, maar het heeft ook geen zin om overal onchages aan te plempen als niet alle velden ueberhaupt gevalideerd hoeven worden.

Je code is wel extreem kort maar je kan zo maar 1 validator per pagina hebben, omdat je binnen de code zelf een rechtstreekse verwijzing naar dat validator object hebt staan, en "validator" is nu ook de enige naam die het script foutloos laat werken.
Dat is waarom ik het form object een .validator property geef, die naar het validatie object verwijst, zodat elementen met this.form.validator in hun eigen onchange toch het validator object kunnen aanspreken, en zo (het igg 1 manier) kan je wel meerdere validators per pagina hebben.

[Verwijderd]

Op zaterdag 26 januari 2002 19:56 schreef Clay het volgende:
kewl

Maar ik denk niet dat je van die onchange setters afkomt, misschien dat het terug te brengen is naar een onchange = referentie; ipv een hele functie eraan hangen, maar het heeft ook geen zin om overal onchages aan te plempen als niet alle velden ueberhaupt gevalideerd hoeven worden.

Nee dat klopt, maar velden die niet gevalideerd hoeven worden, hoeven ook niet 'aangemeld' te worden in de validator.

Je code is wel extreem kort maar je kan zo maar 1 validator per pagina hebben, omdat je binnen de code zelf een rechtstreekse verwijzing naar dat validator object hebt staan, en "validator" is nu ook de enige naam die het script foutloos laat werken.

Ja dat is weer die eeuwige irritante grap dat je niet weet hoe het object heet dat op dat moment aangemaakt wordt. Ik zal de naam dus als argument mee moeten geven aan de constructor

Dat is waarom ik het form object een .validator property geef, die naar het validatie object verwijst, zodat elementen met this.form.validator in hun eigen onchange toch het validator object kunnen aanspreken, en zo (het igg 1 manier) kan je wel meerdere validators per pagina hebben.

Dat is me nog niet opgevallen, code is vaak nogal onleesbaar als je het niet zelf geschreven hebt
Maar ik zal eens kijken of ik inderdaad ook met meerdere validators kan werken, en uiteraard die dependencies en rules zien in te voeren.

[Verwijderd]

Het is me inmiddels inderdaad gelukt, en ik denk nu dat je zojuist de vraag uit m'n eerst post (die tussen haakjes) ook min of meer beantwoord, en volgens mij kan ik dit probleempje er ook mee oplossen

Zulke projecten zijn altijd leuk, omdat ik hier zelf ook nogeens wat van leer, en het gaat heel veel werk besparen natuurlijk

[brammetje]

Leuk, leuk

Ik ben de laatste tijd aan het denken van hoe ik dit in php kan implementeren. Ik zat te denken aan een soort van array waarin je namen, types, regels enzovoorts definieert, met printform($formarray) print je hem, en met checkform($formarray) kan je hem meteen netjes validaten..

Het probleem van javascript-checks is dat je nog steeds serverside je data ook moet verifieren..

[Verwijderd]

Op zondag 27 januari 2002 00:44 schreef PlayR het volgende:
Leuk, leuk

Ik ben de laatste tijd aan het denken van hoe ik dit in php kan implementeren. Ik zat te denken aan een soort van array waarin je namen, types, regels enzovoorts definieert, met printform($formarray) print je hem, en met checkform($formarray) kan je hem meteen netjes validaten..

Het probleem van javascript-checks is dat je nog steeds serverside je data ook moet verifieren..

Wat wil je precies gaan doen met het formulier in PHP? Wil je een ander keuzeformulier erna genereren, of ja.. wat anders eigenlijk? Gewoon valideren is niet echt moeilijk als je alle input al hebt.

Het probleem wat Clay wil oplossen zit hem voornamelijk in de realtime controle, en vlugge aanpassingen aan de client-side. Met PHP zal je dit probleem nooit echt krijgen omdat er niet continue user-input kan zijn.

Of zie ik dat verkeerd?

[brammetje]

Op zondag 27 januari 2002 00:49 schreef Cheatah het volgende:
Of zie ik dat verkeerd?

Mja, na het bekijken van zijn voorbeeld zie ik inderdaad dat hij het formpje aan wilt passen aan de geselecteerde dingen.. Dat kan in php niet.. Wat ik wil maken is gewoon het simpel maken en valideren in php met code die je maar 1 keer schrijft en het meteen beide doet.

edit: kromme Nederlandse zinnen typen is niet moeilijk

Nog maar een poging dan

Mijn ideetje was een stuk minder uitgebreid dan dat van Clay. Ik kom ook nooit echt tegen dat ik zo'n ingewikkeld form heb als het voorbeeld van Clay.. Wel ben ik vaak aan het kutten omdat ik voor elk formpje een uur bezig ben met de html maken en de validatie-shit typen. Met een stuk of 10 formpjes per project is het toch handig hier iets van een handige generieke class voor te schrijven..

totdat we straks allemaal Xforms gebruiken zullen we ons zo moeten behelpen

[oh,when?]

omdat ik eigenlijk in bed hoor te liggen, en dat dadelijk ook ga doen, hier mijn aandeel totnutoe voor deze thread, CheckEmail functie die eventueel als standard method in FormValidation kan:

code:

    function CheckEmail(form,field) {
        if (window.RegExp) { // ondersteunen we wel regular expressions?
            var regexRule   = /^(([^<>;()[\]\\.,;:@\"]+(\.[^<>()[\]\\.,;:@\"]+)*)|(\".+\"))@((([a-z]([-a-z0-9]*[a-z0-9])?)|(#[0-9]+)|(\\[((([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\.){3}(([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\]))\.)*(([a-z]([-a-z0-9]*[a-z0-9])?)|(#[0-9]+)|(\\[((([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\.){3}(([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\]))$/;
            var str         = document.forms[form].elements[field].value;
            var regex       = new RegExp(regexRule);
                if (regex.test(str)) {
                    return true;
                } else {
                    return false;
                }
        } else { // zo niet..evt andere code hier...
            return false;
        }
    }

regular expressions zitten vanaf Javascript 1.2

[Verwijderd]

Hmm, ik vulde daarmee m'n eigen email in, maar die scheen niet echt te werken. Het is wel een monster van een regex

Online versie

[Clay]

Ik heb ook weer een update, deze keer checks en rules tezamen, met 1 onchange die zowel checks als rules doet (setBounds en required moet nog), en moz trekt het nu wel, alleen wil die de motorinhoud niet enablen

http://www.xs4all.nl/~peterned/got/validate/

Rule syntax zou best nog eens totaal anders kunnen worden, maar het blijft een mening, de ene vindt het ene handig, de ander wat anders

[oh,when?]

Op zondag 27 januari 2002 02:05 schreef Cheatah het volgende:
Hmm, ik vulde daarmee m'n eigen email in, maar die scheen niet echt te werken. Het is wel een monster van een regex

Online versie

ja zie net een foutje in de regex...domeinnamen mogen nu niet met cijfers beginnen. dus dit is de vernieuwde:

code:

^(([^<>;()[\]\\.,;:@\"]+(\.[^<>()[\]\\.,;:@\"]+)*)|(\".+\"))@((([a-z0-9]([-a-z0-9]*[a-z0-9])?)|(#[0-9]+)|(\\[((([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\.){3}(([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\]))\.)*(([a-z]([-a-z0-9]*[a-z0-9])?)|(#[0-9]+)|(\\[((([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\.){3}(([01]?[0-9]{0,2})|(2(([0-4][0-9])|(5[0-5]))))\]))$

en nu validate je emailadres wel

[SchizoDuckie]

Wat helemaal mooi zou zijn, is een object oriented manier om de tables gelijk ook te 'write''en. bijv:

FormContainer = new FormContainer(action, 2 cols, 4 rows);
FormContainer[1][2].addchild('text', naam, length, etc); //column 1, row 2

De 2 cols en 4 rows uit de eerste opdracht zouden dan automagisch een (x-browser ) table genereren waar je met addchild je textfield in kan zetten

( * SchizoDuckie zit al een tijdje te peinzen over zoiets in PHP, maar js ruled natuurlijk hiervoor

[Verwijderd]

Op donderdag 31 januari 2002 09:26 schreef papa_eend het volgende:
Wat helemaal mooi zou zijn, is een object oriented manier om de tables gelijk ook te 'write''en. bijv:

FormContainer = new FormContainer(action, 2 cols, 4 rows);
FormContainer[1][2].addchild('text', naam, length, etc);

De 2 cols en 4 rows uit de eerste opdracht zouden dan automagisch een (x-browser ) table genereren waar je met addchild je textfield in kan zetten

( /me zit al een tijdje te peinzen over zoiets in PHP, maar js ruled natuurlijk hiervoor

Voor diegenen die het bovenstaande in de praktijk willen zien:
http://www.singularit.com/files/quest/quest.html

[Verwijderd]

Clay moet dit soort projecten is laten liggen en beginnen aan BomberClay of ClayKart (bomberman, mariokart).

[SchizoDuckie]

Op donderdag 31 januari 2002 09:36 schreef Blues het volgende:

[..]

Voor diegenen die het bovenstaande in de praktijk willen zien:
http://www.singularit.com/files/quest/quest.html

Hmmm... is niet helemaal wat ik bedoel. De 'syntax' die clay gebruikt is veel duidelijker, en je hoeft niet alle <div> 's voor te definieren.

B.t.w. als je bij stap 2 als referer 'http://gathering.tweakers.net' invult, dan keurt ie dat af. 'http://www.tweakers.net' werkt wel.

^{tijd voor een nieuwe regexp}

[Verwijderd]

Op donderdag 31 januari 2002 10:54 schreef papa_eend het volgende:

[..]

Hmmm... is niet helemaal wat ik bedoel. De 'syntax' die clay gebruikt is veel duidelijker, en je hoeft niet alle <div> 's voor te definieren.

B.t.w. als je bij stap 2 als referer 'http://gathering.tweakers.net' invult, dan keurt ie dat af. 'http://www.tweakers.net' werkt wel.

^{tijd voor een nieuwe regexp}

Ik zal er even wat meer over vertellen. Alle vragen, stappen en interactiemodellen zijn gedefinieerd in een javascript dataObject. Alle DIVs worden dus ook on demand gecreeerd. De hele formafhandeling (het uitlezen van values, valideren, bepalen welke vragen zichtbaar moeten zijn) gaat door dat dataobject. Een formulier van 7 onderling-afhankelijke dynamische pagina's wordt zo een stuk makkelijker te onderhouden.

Je opmerking over 'div's voordefinieren' snap ik niet zo.

^{note to self: must master regExp}

[Clay]

Mjah, dat gaat ook wel iets verder dan puur validatie toch zou ik ook een validatie module zoals ik die nu heb gebruiken binnen zo'n superformtool.

Het gaat/ging er gewoon om dat ik formvalidatie scripten haat en dat kan dus ook simpel met een module zo, en er zijn vast nog wel honderd andere manieren om zoiets te bouwen.

Het form zelf dynamisch bouwen is dan wel een volgende (logische) stap idd.

[Anders]

Op vrijdag 25 januari 2002 17:44 schreef oh,when? het volgende:
formvalidation clientside blijft natuurlijk jezelf voor de gek houden

Zeker niet! De bezoeker hoeft met client-side validatie immers niet bij ieder foutje telkens weer opnieuw een pagina te laden.

Uiteraard hoort er achter elke client-side-validatie een stevige server-side validatie. Klinkt als dubbelop werk, maar je kunt voor beide soorten validaties redelijk eenvoudig modules schrijven.

[oh,when?]

Op vrijdag 01 februari 2002 16:47 schreef Anders het volgende:

[..]

Zeker niet! De bezoeker hoeft met client-side validatie immers niet bij ieder foutje telkens weer opnieuw een pagina te laden.

true true...bovenstaande had eigenlijk nog aangevuld worden met:

"client-side validation als veilig accepteren is natuurlijk jezelf voor de gek houden"

[Woudloper]

* Shop *

Clay heb je al een downloadable versie beschikbaar net zoals Beehive

[Verwijderd]

*schop*

Ik heb de afgelopen anderhalve dag af en toe eens lekker gescript, en daar is tot nu toe het volgende resultaat uitgekomen:
http://www.50hertz.net/dev/formtest.html
Ongeveer 200 regels javascript waarvan de helft accolades en simpele switch/case/break statements.

Zoals je kunt zien gebruikt deze geen 'smerige' eval-functies, maar worden de regels netjes geanalyseerd. Documentatie zal misschien nog volgen, het is ook nog niet echt af ofzo, maar de basis is er.

De rules zijn in de stijl van:
^{condities { acties als alle condities gelden } else { acties als dat niet zo is }}
Losse condities en acties moeten gescheiden worden door een ; en je kunt er ook velden mee enablen/disablen en al dan niet read-only maken.

To do list:
• recursief rules op andere velden toepassen
• meer functionaliteit voor radiobuttons
• regular expressions support voor textfields inbouwen
• mogelijk ook 'or' functionaliteit (verdomd lastig)
• nog meer dat ik nog moet bedenken

Dit is allemaal getest in NS 4.78, NS 6.21, IE 6.0, Moz 0.93, en ik heb weinig reden om aan te nemen dat het in andere browsers niet zou werken.

Alleen NS 4.7 doet uiteraard moeilijk over disablen enzo

Verder kun je de FormHandler class gebruiken om lekker simpel waarden te setten/getten. Geen geknoei meer met document.forms['naam'].elements['select'].options[document.forms['naam'].elements['select'].selectedIndex].value enzo

Feature requests en bug reports zijn uiteraard welkom

[Bosmonster]

Hmm. ben zelluf ook bezig geweest Mijne is 50 regels en de volgende features:

- Regex tekst-validatie
- check test voor radiobuttons
- checkbox-test (minimaal X opties moeten geselecteerd zijn uit een gegeven verzameling)
- Select-test
- default en custom messages per element, met %fieldname% variable
- Auto-trim
- Auto-focus

Hijs nog nie klaar en wil je ook niet 'overtreffen', maar mogelijk kun je er nog ideeen uithalen voor jullie public formvalidator

URL: http://bosmonster.b2f.nl/formval/formval.html

Met dit systeem kun je als je een checkbox aanklikt ofzo dynamisch de rules aanpassen, dus hoef geen ingewikkelde condition-shit te schrijven.

Verder wil ik het optioneel maken of je per element een melding krijgt of achteraf een overzicht...

[LuCarD]

Op maandag 25 maart 2002 14:31 schreef Bosmonster het volgende:
Hmm. ben zelluf ook bezig geweest Mijne is 50 regels en de volgende features:

En ik krijg allemaal JavaScript errors.... Maar het idee is leuk...

[Bosmonster]

hijs nog niet af..

Onder IE6 en NS4 en NS6 werkt ie prima

Mogelijk onder oudere IE versies foutmeldingen door de ungreedy regex in de trim-functie.. NS4 negeert het (en past het ook niet toe)..

moet er nog ff naar kijken

Mijn doel bij JS is altijd zo klein mogelijke bestandgrootte.

[LuCarD]

Ik heb hier alleen IE5 en Mozilla, NS

Ik zal nog eens kijken met NS

edit:

Mozilla werkt!

edit:

Errormessages onder IE5:
• Line 22: unexpected quantifier
• Line 8: FV_NUMBER is undefined

[Verwijderd]

Op maandag 25 maart 2002 13:41 schreef Cheatah het volgende:
*schop*

Ik heb de afgelopen anderhalve dag af en toe eens lekker gescript, en daar is tot nu toe het volgende resultaat uitgekomen:
http://www.50hertz.net/dev/formtest.html
Ongeveer 200 regels javascript waarvan de helft accolades en simpele switch/case/break statements.
[...]
Feature requests en bug reports zijn uiteraard welkom

FF snel zeiken maar volgens mij mag dit niet

code:

<!doctype html public "-//W3C//DTD XHTML 1.0 Strict//EN" ... >
en
<input type="text" name="text1" value="Jeuhj" readonly />

Toch?

[Bosmonster]

Foutmeldingen komen van de ungreedy-regex.

Even gechecked.. als ik de trim eruithaal dan doet ie het zelfs onder IE4 zonder fouten.. IE5.5 doet het wel goed.

[Bosmonster]

Volgens mij zit de ungreedy regex in dezelfde JS-versie als de Array.prototype.push() method. Dat zou een simpele check kunnen zijn..

Done..

URL: http://bosmonster.b2f.nl/formval/formval.html

[Verwijderd]

Op maandag 25 maart 2002 14:50 schreef Blues het volgende:

FF snel zeiken maar volgens mij mag dit niet

U heeft gelijk, tijdens de develop-fase doe ik nog weleens foute dingen

Het ging dan ook om de javascript in dit geval
Bovendien ging de W3C validator volledig op z'n bek

[LuCarD]

Op maandag 25 maart 2002 15:11 schreef Bosmonster het volgende:
Volgens mij zit de ungreedy regex in dezelfde JS-versie als de Array.prototype.push() method. Dat zou een simpele check kunnen zijn..

Done..

URL: http://bosmonster.b2f.nl/formval/formval.html

Sorry zelfde fouten alleen nu op regelnummers 23 en 8.

[Bosmonster]

klopt.. ik geef het op..

ik kan of voor de trim functie alleen een browsercheck gaan implementeren of ik kan er wat anders op gaan verzinnen...

[Verwijderd]

Op maandag 25 maart 2002 16:31 schreef Bosmonster het volgende:
klopt.. ik geef het op..

ik kan of voor de trim functie alleen een browsercheck gaan implementeren of ik kan er wat anders op gaan verzinnen...

Wat wil je precies trimmen dan? De spaties voor en na de inputs?

[Bosmonster]

yup.. any ideas?

[LuCarD]

code:

function trim(str) {
  return str.replace(/^\s*/, '').replace(/\s*$/, '')
}

[Bosmonster]

hmm.. ff testen

cool werkt.. dat ik daar niet opgekomen ben

return str.replace(/^\s*/, '').replace(/\s*$/, '')


Probeerde de oplossing altijd maar te zoeken in een enkele regex.. en dat kan ook wel, maar dan loop je tegen die ungreedy beperking aan van ouwere browsers..

Vage blijft overigens wel dat NS4 de laatste niet uitvoert.. spaties blijven aan het einde staan.. Maar who cares. Zelfs de Mac doet het nu goed

[Verwijderd]

code:

function trim(str) {
  regex = /^\s*(.*?)\s*$/;  
  return regex.exec(str)[1]; 
}

Zo dan?

[Bosmonster]

regex = /^\s*(.*?)\s*$/;

das dus ungreedy (het vraagteken) en werkt nie (had precies hetzelfde)

OW.. originele post van LucarD stelde dus de goeie werkende oplossing voor:

return str.replace(/^\s*/, '').replace(/\s*$/, '')

Nog bedankt

[Verwijderd]

Op maandag 25 maart 2002 13:41 schreef Cheatah het volgende:
To do list:

• recursief rules op andere velden toepassen
• meer functionaliteit voor radiobuttons

• regular expressions support voor textfields inbouwen
• mogelijk ook 'or' functionaliteit (verdomd lastig)
• nog meer dat ik nog moet bedenken

Ik ga nu er nog een zooitje documentatie bij schrijven, al met al is het best efficient geworden dacht ik zo.

Als het goed is kan zelfs een beginner hier wel mee overweg. En dat was uiteraard één van de oorspronkelijke doelen.

[Clay]

ik zal die van mij ook binnenkort eens online zetten

is best leuk geworden. En hij is ook getest op een extreem formulier waar er echt BAKKEN checks en rules werden uitgepoept (honderden) en dat werkte

in de rules heb ik alleen een enkelvoudige or, dus iets als if(dit || (dit en dat)) kan (nog) niet "verwoord" worden in de rule syntax. maar dat worden waarschijnlijk gewoon haken ala:

_{if not selected auto:ford or (checked fiets and checked brommer) then disable garantie and execute customFunctie}

nooit meer zelf validaties hoeven schrijven!! wooohaaa!

[SchizoDuckie]

Op dinsdag 26 maart 2002 20:10 schreef Clay het volgende:
ik zal die van mij ook binnenkort eens online zetten

is best leuk geworden. En hij is ook getest op een extreem formulier waar er echt BAKKEN checks en rules werden uitgepoept (honderden) en dat werkte

in de rules heb ik alleen een enkelvoudige or, dus iets als if(dit || (dit en dat)) kan (nog) niet "verwoord" worden in de rule syntax. maar dat worden waarschijnlijk gewoon haken ala:

_{if not selected auto:ford or (checked fiets and checked brommer) then disable garantie and execute customFunctie}

nooit meer zelf validaties hoeven schrijven!! wooohaaa!

* SchizoDuckie wacht met smart

[Bosmonster]

Is de wereld weer een berg formvalidators rijker

[Bosmonster]

Heb ook maar 2 toevoegingen gedaan aan de hand van wat gebreken die aan het licht kwamen bij implementatie

1. Argument voor het optioneel maken van text-validators. Dus er wordt pas op syntax gecheckt asl er uberhaupt iets ingevuld wordt. Standaard is check=verplicht.

2. Toevoeging voor custom validatie na de gewone validatie (dus als je er vanuit kunt gaan dat de syntax van velden goed is). Bijvoorbeeld om passwords te vergelijken of iets dergelijks.

Script nog steeds < 2K

[Verwijderd]

Bosmonster: Probeerde de oplossing altijd maar te zoeken in een enkele regex.. en dat kan ook wel, maar dan loop je tegen die ungreedy beperking aan van ouwere browsers..

Nope, greediness heeft er niets mee te maken. (Zie uitleg via FAQ in /14 )

Vage blijft overigens wel dat NS4 de laatste niet uitvoert.. spaties blijven aan het einde staan..

Copy-paste, edit:

code:

function trim(str) {
    return str.replace(/^\s*/g, '').replace(/\s*$/g, '')
}

(Waarom nul of meer keer whitespace vervangen door niets? Als er al geen whitespace is hoef je niet te vervangen...)

Of (als je het in 1 enkele regex wilt):

code:

function trim(str) {
    return str.replace(/^\s+|\s+$/g, '')
}

[Bosmonster]

Nope, greediness heeft er niets mee te maken.

Aha.. wat is dan je verklaring dat ie het onder IE5.5+/NS6+ wel goed doet en elke lagere versie de greediness negeert of zelfs foutmeldingen geeft over ongeldige regexp-factoren? In die /14 topic gaat het aleen maar over PHP/Perl en niet over het Javascript RegExp object, browsercompatibiliteit en Javascript versies.

(Waarom nul of meer keer whitespace vervangen door niets? Als er al geen whitespace is hoef je niet te vervangen...)

true.. beetje te snel gecopy-paste.

return str.replace(/^\s*/g, '').replace(/\s*$/g, '')

Die 'g' is een beetje nutteloos aangezien je toch alleen aan het begin en einde van de string kijkt.. en een string heeft maar 1 begin en 1 einde

Bovendien blijft het een NS4 bug/gemis in JS-RegExp. Het laatste doet ie niet om een nog onbekende reden.

Of (als je het in 1 enkele regex wilt):

code:
--------------------------------------------------------------------------------
function trim(str) {
return str.replace(/^\s+|\s+$/g, '')
}

Thanks.. die is inderdaad beter, al blijft ook hier de NS4 bug bestaan natuurlijk. Hier is de 'g' wel noodzakelijk als vervanging voor de greediness (anders voert ie het laatste niet uit).

[Verwijderd]

Bosmonster: In die /14 topic gaat het aleen maar over PHP/Perl en niet over het Javascript RegExp object, browsercompatibiliteit en Javascript versies.

Het ging me me erom dat in dat topic staat wat greediness is en dat je daar kan zien dat greediness niets met de opossing te maken heeft. Je wilt nl zoveel mogelijk whitespace aan het begin en eind door niets vervangen en het default gedrag van de + quantifier is zoveel mogelijk te matchen, dus je hoeft hem niet lazy (un-greedy) te maken door er een ? achter te zetten.

Alleen als je een vervanging wilt van

code:

/^\s*(.*?)\s*$/

door $1 (of hoe je een backreference ook schrijft in JavaScript) is er een probleem...

Maar dan is de betere oplossing om te matchen in plaats van te vervangen:

code:

/\S+(\s+\S+)*/

// match een of meer non-whitespaces,
// optioneel gevolgd door een herhaling
// van "whitespaces en non-whitespaces"

Daarmee wil ik niet beweren dat dit nou echt een mooie oplossing is, maar beter dan die hierboven wel. (Die \S is trouwens een non-whitepsace; ik neem aan ook in JavaScript...)

Die 'g' is een beetje nutteloos aangezien je toch alleen aan het begin en einde van de string kijkt.. en een string heeft maar 1 begin en 1 einde

/me begint ineens overal /g achter te zetten./g

Hier is de 'g' wel noodzakelijk als vervanging voor de greediness (anders voert ie het laatste niet uit).

Niet als vervanging van de greediness. Als je hem lazy (non-greedy) strip hij max 1 whitespace teken van begin en/of eind af (afhankelijk van de /g modifier) ipv zoveel mogelijk (wat je wilt).

[Bosmonster]

Alleen als je een vervanging wilt van

code:
--------------------------------------------------------------------------------
/^\s*(.*?)\s*$/
--------------------------------------------------------------------------------

door $1 (of hoe je een backreference ook schrijft in JavaScript) is er een probleem...

Dat was dus precies de oplossing die ik eerst had.. maar dus niet werkte in oudere browsers...

Maaruh.. nog bedankt voor

code:

/^\s+|\s+$/g

Das een goeie simpele korte en browser compatibele trim-regex!

[Verwijderd]

Bosmonster: Maaruh.. nog bedankt voor

code:

/^\s+|\s+$/g

Das een goeie simpele korte en browser compatibele trim-regex!

Geen dank. Vond het wel een leuk draadje.

[LuCarD]

[ot-en nutteloze toevoeging]
* LuCarD maakt notities
[/ot]

[oZy]

*schop*

Clay, weer een toppertje van een script!

Werkt prima voor een prototype, heb alleen 1 'maar':

Ik heb het script binnen 1 minuut geïmplementeert bij een formpje in een popup waar mee je een advertentie kunt plaatsen. Zonder correcte email kan je geen titel invoeren, zonder titel geen inhoud, en zonder inhoud geen submit. Prima

Maar bij een submit, komt de gebruiker op een voorbeeldje van de ingevoerde advertentie. Mocht de gebruiker nog wat willen aanpassen, dan druktie op zn back toets om te editten.. alleen dan gaat het fout want ookal is alles correct ingevuld, je kan pas editten/submitten als je eerst email ff focussed en een spatie of whatever invoert, daarna titel, inhoud en dan pas submitten.

Misschien een idee om iets van onLoad checkValues oid (ben geen js held) in te bouwen

[SchizoDuckie]

*überSchop!*

mmmclaaaaay... heb je toevallig per ongeluk die flexe validatie van je nog? Je hebt je /got/ dir op je site opgeruimd namelijk en k kan m voorderest niet meer vinden

[ Voor 0% gewijzigd door SchizoDuckie op 29-10-2002 16:41 . Reden: als iemand anders deze .js nog ergens heeft en zo vriendelijk wil zijn deze te doneren wordt dat ook op prijs gesteld :* ]

[Pelle]

Euh.. hartstikke leuk, maar kicken en schoppen na zo'n periode is nie fijn nie.
Clay heeft ook mail en ICQ enzo