Archief - javacript code probleem

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Mikey_1

Legacy Member
hallo

ik ken al redelijk java, spring,...
maar ben nog een maar beginneling voor javascript (maar al doende leert men :) )


ik heb 2 input velden, naam en mail

ik heb problemen met het checken of het allemaal letters zijn.
ik heb zelf al , na meerdere pogingen, codes gekopieerd van het internet en zelfs deze werken niet.


-waarom gaat hij niet door de "if (abc.value.match(letters))" ??
-en als hij door de else lus gaat dan zou het programma toch verder moeten gaan naar de mail controle op "@" en ".".


-wat ik ook een groot verschil met java, bij java kreeg je een lijst methodes die beschikbaar (bijv: toString, length, etc..) deze optie is er niet bij javascript

bedankt voor de hulp & advies


Code:
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
    <head>




        <script language="javascript">

            function test() {


                if (document.form1.naam.value === "") {
                    alert("naamveld is leeg");

                    return false;
                }
            
//        controleren dat het alleen letters zijn
        
                else {


                    var abc = document.form1.naam.value;
                    alert("ingegeven naam" + abc);
                    var letters = /^[A-Za-z]+$/;
                    if (abc.value.match(letters))
                    {
                        alert("juiste ingave");
                        return true;
                    }
                    else
                    {
                        alert('foute ingave, herbegin');
                        return false;
                    }

                }



                if (document.form1.mail.value.indexOf("@") === -1 || document.form2.mail.value.indexOf("." === -1)) {
                    alert("een mail adres heeft een @ en een . nodig");
                }

            }

        </script>

        <title>JSP Page</title>
    </head>
    <body>
        <!--action="mailto:uwMailAdres@..." -->
        <form name="form1"  method="post" enctype="text/plain" onsubmit="return test()">
            naam: <input type="text" size="15" name="naam">
            email: <input type="text"size="15"  name="mail">
            <input type="submit" value="Versturen">


        </form>
    </body>
</html>

Dieterg

Legacy Member
1. Je haalt de value van uw abc al op dus je zou eigenlijk het volgende moeten doen:
Code:
if ( abc.match(letters) )

Nu klopt er nog iets niet helemaal met uw REGEX. Ik ben zelf geen krak in regex maar het volgende werkt bij mij:
Code:
 var letters = /^[A-Za-z]+/;

Zie jsFiddle

2. Neen, je zet een functie test en je geeft een returnwaarde op dus hij zal nooit bij uw e-mail check geraken.

Zie jsFiddle voor een mogelijke oplossing

3. Wat bedoel je hiermee? toString bestaat in javascript en length ook?

edit: ik raad u aan om een cursus javascript te volgen. Lees meer over eventhandlers in javascript (https://developer.mozilla.org/en-US/docs/DOM/EventTarget.addEventListener)

bealzebub

Legacy Member
Dieterg zei:
1. Je haalt de value van uw abc al op dus je zou eigenlijk het volgende moeten doen:
Code:
if ( abc.match(letters) )

Inderdaad, slordige code leidt tot slordige en moeilijk te vinden fouten. Ik veronderstel dat je je Java code toch een beetje volgens de regels van de kunst schrijft, doe dat dan ook met Javascript.

Dieterg zei:
Nu klopt er nog iets niet helemaal met uw REGEX. Ik ben zelf geen krak in regex maar het volgende werkt bij mij:
Code:
 var letters = /^[A-Za-z]+/;

De originele RegEx was juist, want als je die $ op het einde weghaalt, dan zal "abcdefhij123" wel werken. $ duidt immers op het einde van de string. De origele regex zei dus: "alles tussen begin en einde moet één of meer letters zijn".

Je bent wel vergeten spaties toe te laten, en wat met namen zoals "Jean-François" etc?

RegEx werkt in grote lijnen identiek over alle talen heen, dus blijkbaar ook niet zoveel ervaring mee ;) Enige pitfall voor Javascript waar ik tot nu toe mee te maken gehad heb is dat je niet de modifier "s" hebt (/regex/s) die toelaat van punt (.) ook newlines te laten matchen. Is gemakkelijk rond te werken door "[\s\S]" te gebruiken ipv "." Maar da's hier helemaal niet van toepassing.

Dieterg zei:
3. Wat bedoel je hiermee? toString bestaat in javascript en length ook?

Waarschijnlijk gebruikt de TS één of andere IDE met Intellisense (alhoewel ik daar persoonlijk weinig intelli-gent aan vind, maar da's persoonlijk). Der zullen er wel zijn als je googlet op "javascript {mijn IDE naam} intellisense".

Mikey_1

Legacy Member
bedankt voor jullie uitleg.

ik zal vanavond verder oefenen

wat ik bedoelte met bijv: toString, length, etc..

in java, (ik werk met netbeans), kreeg ik met "crtl spatie" (die ik gebruikte na een variabele: bijv: eengetal.xxx) allerlei methodes die ik kon gebruiken.

In javascript krijg ik ook methodes te zien, maar bijv: length, indexOf, etc.. toont netbeans me niet en moet ik deze dus zelf invullen. (en me deze methodes herinneren)
als er zo een lijst tervoorschijn komt is het soms makkelijker (voor een beginneling toch) want dan kan je zien welke methodes er van toepassing kunnen zijn.

de RegEx zal ik eens bestuderen.

nogmaals bedankt voor de hulp

Dieterg

Legacy Member
bealzebub zei:
De originele RegEx was juist, want als je die $ op het einde weghaalt, dan zal "abcdefhij123" wel werken. $ duidt immers op het einde van de string. De origele regex zei dus: "alles tussen begin en einde moet één of meer letters zijn".

Bedankt om hier op in te pikken, weeral iets bijgeleerd! :-)

Ik weet niet hoe het juist in netbeans te werk gaat maar je kan eens googlen op: netbeans javascript intellisense

edit: amai de klok staat precies verkeerd opt forum? 14:49? :D

bealzebub

Legacy Member
Mikey_1 zei:
in java, (ik werk met netbeans), kreeg ik met "crtl spatie" (die ik gebruikte na een variabele: bijv: eengetal.xxx) allerlei methodes die ik kon gebruiken.

In javascript krijg ik ook methodes te zien, maar bijv: length, indexOf, etc.. toont netbeans me niet en moet ik deze dus zelf invullen. (en me deze methodes herinneren)
als er zo een lijst tervoorschijn komt is het soms makkelijker (voor een beginneling toch) want dan kan je zien welke methodes er van toepassing kunnen zijn.

Javascript is een interpreted language met loosely typed objecten. Het ene moment kan variabele "a" nog een string zijn, het andere moment is het een integer. Bovendien weet je al helemaal niet wat er in een function binnenkomt van arguments. Je IDE kan dus niet contextgevoelig gaan suggereren, want hij kent de context niet.

In Java ga je expliciet je objecten declareren, er is dus geen discussie waarover het gaat.

Daardoor kan Netbeans of Visual Studio heel moeilijk weten welke methods kunnen aangeroepen worden. Ze zouden via de runtime kunnen proberen uit te vinden wat het is, maar dan nog&#8230; Meer dan een vage gok zal het toch niet zijn, jij als developer bent eigenlijk de enige die weet waarmee hij bezig is. Vandaar dat die autosuggest menutjes voor Javascript zo beperkt zijn, ze suggereren enkel waar ze echt zeker van kunnen zijn (wat al niet echt veel is).

Voor webdevelopment, zeker frontend development, vind k persoonlijk dat je veel beter af bent met een goeie code editor zoals Sublime Text 2 en niet met een IDE. IDEs zijn goed voor omgevingen waar je echt gaat compilen (waar je vóór je code runt eigenlijk al errors kan detecteren) en dikwijls nog aan memory management moet doen (Java, C++, Objective-C, &#8230;) maar niet voor interpreted omgevingen. Daar ben je gewoon beter af met een lean mean speedmachine ipv een log bombastisch gedrocht.

Xenron

Legacy Member
dit is misschien niet veel, maar probeer er rekening mee te houden, heb het al vaak meegemaakt dat het in het honderd loopt dmv deze stomme foutjes:

<body>
<!--action="mailto:uwMailAdres@..." -->
<form name="form1" method="post" enctype="text/plain" onsubmit="return test()">
naam: <input type="text" size="15" name="naam">
email: <input type="text"size="15" name="mail">
<input type="submit" value="Versturen">
</form>
</body>

maak je HTML tags zelfsluitend (naam, email, input)

<body>
<!--action="mailto:uwMailAdres@..." -->
<form name="form1" method="post" enctype="text/plain" onsubmit="return test()">
naam: <input type="text" size="15" name="naam"/>
email: <input type="text"size="15" name="mail"/>
<input type="submit" value="Versturen"/>
</form>
</body>

cheers :p

Dieterg

Legacy Member
Hij gebruikt HTML5 doctype dus dat is geen probleem. In HTML5 is dat geen must!

Ene van Mol joh! Heb ik nog op school gezeten :-)

Xenron

Legacy Member
aah oke :d daar is dat idd geen must :p

haha, waar hebt ge gezeten ? KTA hier.

TheBud

Legacy Member
bealzebub zei:
Javascript is een interpreted language met loosely typed objecten. Het ene moment kan variabele "a" nog een string zijn, het andere moment is het een integer. Bovendien weet je al helemaal niet wat er in een function binnenkomt van arguments. Je IDE kan dus niet contextgevoelig gaan suggereren, want hij kent de context niet.

In Java ga je expliciet je objecten declareren, er is dus geen discussie waarover het gaat.

Daardoor kan Netbeans of Visual Studio heel moeilijk weten welke methods kunnen aangeroepen worden. Ze zouden via de runtime kunnen proberen uit te vinden wat het is, maar dan nog&#8230; Meer dan een vage gok zal het toch niet zijn, jij als developer bent eigenlijk de enige die weet waarmee hij bezig is. Vandaar dat die autosuggest menutjes voor Javascript zo beperkt zijn, ze suggereren enkel waar ze echt zeker van kunnen zijn (wat al niet echt veel is).

Voor webdevelopment, zeker frontend development, vind k persoonlijk dat je veel beter af bent met een goeie code editor zoals Sublime Text 2 en niet met een IDE. IDEs zijn goed voor omgevingen waar je echt gaat compilen (waar je vóór je code runt eigenlijk al errors kan detecteren) en dikwijls nog aan memory management moet doen (Java, C++, Objective-C, &#8230;) maar niet voor interpreted omgevingen. Daar ben je gewoon beter af met een lean mean speedmachine ipv een log bombastisch gedrocht.

Hier ben ik het niet mee eens.

Als je met Visual Studio werkt kan je gebruik maken van TypeScript, een tussentaal die compileert naar javascript. Hiermee kan je strong typing toepassen en kun je gewoon gebruikmaken van intellisense.

Rechtstreeks in javascript programmeren is wat een hackjob en je weet ook moeilijk hoe browsers reageren op wat je doet. In die zin is het ook een erg onvolwassen taal, mogelijk in de volgende versie dat ze er typing bij insteken zodat je eindelijk op een deftige manier met objecten kunt werken.

bealzebub

Legacy Member
TheBud zei:
Hier ben ik het niet mee eens.

Als je met Visual Studio werkt kan je gebruik maken van TypeScript, een tussentaal die compileert naar javascript. Hiermee kan je strong typing toepassen en kun je gewoon gebruikmaken van intellisense.

Daar zeg je het: het compileert naar Javascript. Of je nu Coffeescript of TypeScript gebruikt, het zijn niet meer dan convenience layers (die ook nog hun eigen quirks en onhebbelijkheden hebben trouwens). En by all means, gebruik een precompiler als dat je ding is, maar je kan net hetzelfde in plain Javascript doen en mits een beetje ordelijkheid en een goeie testsuite heb je geen precompiler nodig.

Ikzelf gebruik trouwens quasi altijd Coffeescript de afgelopen jaren, zowel voor serverside JS (Node) als browser JS. Maar Coffeescript en TypeScript verhouden zich tot Javascript zoals Haml zich verhoudt tot HTML en LESS/Stylus/SASS zich verhoudt tot CSS. En op zich is dat helemaal niet slecht: je kan met meer keuzes zelf beslissen wat jij de meest aangename omgeving vindt. Maar zeggen dat jouw keuze de keuze is die iedereen dan maar moet maken&#8230; euhm&#8230; waarom?

TheBud zei:
Rechtstreeks in javascript programmeren is wat een hackjob en je weet ook moeilijk hoe browsers reageren op wat je doet. In die zin is het ook een erg onvolwassen taal, mogelijk in de volgende versie dat ze er typing bij insteken zodat je eindelijk op een deftige manier met objecten kunt werken.

Da's de typische reactie van een OO programmeur die denkt dat OO het Lam Gods is en dat Javascript zich op de Java-manier moet gedragen. Javascript is een prototype-based programming language waar je functional programming in doet. Wat ik vaak hoor bij mensen die van OO talen naar Javascript komen is dat Javascript geen inheritance kent. Da's dus dikke zever, in Javascript heet dat de prototype chain. Als je momenteel niet goed in Javascript met objecten kan werken, dan is t omdat je Javascript maar oppervlakkig begrijpt, zo simpel is het. Javascript is trouwens verre van de enige niet-OO taal. Het is wel de minst niche-omgeving, dus wordt er veel meer over gejankt.

En laat ons niet over strong typing vs weak typing beginnen. Als je nog Pascal van vroeger kent, dat was strong typed taal en dat was (op dat vlak dan toch) dikwijls een bitch om in te werken. Arrrrgghhh, als ik alleen maar aan arrays denk&#8230; C++ is trouwens waarschijnlijk de bekendste weak typed taal, maar heeft toch static typing. Zelfs C# en Visual basic, die toch door de meesten aanzien worden als strong typed talen, laten nog altijd het gebruik van pointers en andere vormen van direct memory manipulatie toe.

Bovendien wijs je op de inconsistentie tussen verschillende Javascript engines. Dat is alsof je het verwijt zou maken dat C++ geen goeie taal is omdat er conditionele compilation code moet voorzien worden voor GCC in al z'n varianten, dan nog net iets anders voor de Visual C++ compiler en nog anders voor LLVM. Trouwens, de recentste Javascript engines werken over het algemeen uniform in wat ze ondersteunen en hoe ze reageren. De meeste conditionals in frameworks zoals jQuery etc. zijn niet meer dan het opvangen van legacy engines en bugs in de huidige engines die er eigenlijk niet zouden mogen zijn. Dat heeft niet met Javascript zelf te maken (de taal ligt vast), maar met meerdere engines.

Talen evolueren, en gelukkig maar. Dat heeft niets met onvolwassenheid te maken, integendeel. De voorstellen ivm "classes" en "typing" in Javascript, die TypeScript je momenteel al laat gebruiken in afwachting van een mogelijke implementatie, zijn in mijn ogen meer een poging om minder slechte code door slecht gebruik te krijgen dan iets anders. Eigenlijk brengen ze niets bij aan Javascript dat nu niet mogelijk is, ze zorgen er alleen voor dat je die code niet meer zelf moet schrijven (of door TypeScript of Coffeescript moet laten schrijven). Het voordeel van het in de engine zelf te verwerken is dat ze daar betere optimalisatie op gaan kunnen doen. Maar onderschat Javascript niet, op sommige vlakken zijn de JIT compilers echt wel snelheidsmonsters.

Als je bijvoorbeeld in de NodeJS community gaat kijken, dan zie je echt wel overwegend mooie Javascript code die snel werkt. Kijk je dan naar de browserkant, dan heb je een overdaad aan amateurs die code schrijven waar ik een kotszakje voor moet bovenhalen. Ligt dat aan de taal? Nope. Als je iemand een hamer geeft en die klopt dan een nagel met de steel in een plank (wat perfect lukt), dan ga je toch ook niet de schuld op de hamer steken?

Er is gelukkig één positief ding aan de evolutie van ECMAScript en daar kan ik me min of meer terugvinden in dat "onvolwassen" bestempelen: alle betrokken partijen zijn eindelijk eens rond tafel gaan zitten om een consensus te vinden en iedereen in dezelfde richting te pushen. Maar we zijn er nog niet, er is nog altijd veel onenigheid en veel van de voorgestelde zaken zoals namespacing, packages en early binding zijn al lang weer van tafel gevaagd. Maar Javascript is verre van de enige specificatie die daaronder te lijden heeft. Da's waar alle open omgevingen mee te maken krijgen: veel inbreng uit alle hoeken met veel verschillende meningen over wat best is. Gesloten omgevingen hebben dat probleem een stuk minder, maar daar hang je dan weer vast aan één partij die beslist wat best voor je is (en niet altijd in de positieve zin).

TheBud

Legacy Member
Een goeie taal is een taal die makkelijk te gebruiken is, leesbaar, modulair. Dat er zoveel mensen zoveel problemen hebben met javascript is toch bewijs genoeg dat er iets schort of niet?

Dat TypeScript uberhaubt nog maar bestaat is het zoveelste bewijs over wat mis is met Javascript. De taal is imo echt een puinhoop, onleesbaar en verschrikkelijk ongebruiksvriendelijk.

Je hebt wel gelijk in je conclusie, er zijn teveel partijen die het eens moeten geraken over de taal, een proprietary taal als C# ontwikkelt zich veel sneller (en beter).

YaMo

Legacy Member
TheBud zei:
Een goeie taal is een taal die makkelijk te gebruiken is, leesbaar, modulair. Dat er zoveel mensen zoveel problemen hebben met javascript is toch bewijs genoeg dat er iets schort of niet?

Dat TypeScript uberhaubt nog maar bestaat is het zoveelste bewijs over wat mis is met Javascript. De taal is imo echt een puinhoop, onleesbaar en verschrikkelijk ongebruiksvriendelijk.

Je hebt wel gelijk in je conclusie, er zijn teveel partijen die het eens moeten geraken over de taal, een proprietary taal als C# ontwikkelt zich veel sneller (en beter).

Zijn Scala en Groovy dan de bewijzen dat Java niet goed is?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan