[JS] gebruik van eval

[zoepercavia]

ik heb een form waarin drie keer een adres-blok voorkomt (straat, huisnummer, plaats, postcode). Adressen zijn bijvoorbeeld vakantie adres, thuisadres en werkadres.
Om makkelijk te kunnen formchecken heb ik de namen gestandaardiseerd, bv.

code:

<input type="text" name="vakantieStraat"/><input type="text" name="werkStraat"/>

nu wil ik een functie schrijven die de adresblokken controleert op input, zoiets als dit:

code:

//frm is het formulier
//type is bv. vakantie of thuis
function checkAdres(type, frm) {
alert(frm.eval(type + "Straat").value);
}

dit gaat prima in Mozilla, maar IE pikt het niet (voor de verandering )
hoe moet dit anders, kan ik misschien het gebruik van eval omzeilen?

[Xanthus]

frm.getElementById(type + "Straat").value denk ik.
Misschien is type gereserveerd, maar dat zou ik niet weten.

[crisp]

Probeer eens:

code:

alert(document.forms[frm].elements[type+'Straat'].value);

of (als frm echt al een verwijzing is naar het form, en niet alleen de naam):

code:

alert(frm.elements[type+'Straat'].value);

[zoepercavia]

tx.. crisp.. frm.elements[type+'Straat'].value was goed... en dat is natuurlijk ook veel netter dan eval..

[Clay]

yup. eval heb je eigenlijk nooit nodig, en het maakt je code eigenlijk alleen maar onoverzichtelijker. het kan 99.9% van de gevallen zonder. Ik weet eigenlijk maar 1 reden om eval te gebruiken, en dat is als je dynamisch gegenereerde js code wil uitvoeren. en dat heb je nou niet bepaald vaak nodig

[Verwijderd]

Clay schreef op 13 augustus 2002 @ 14:36:
yup. eval heb je eigenlijk nooit nodig, en het maakt je code eigenlijk alleen maar onoverzichtelijker. het kan 99.9% van de gevallen zonder. Ik weet eigenlijk maar 1 reden om eval te gebruiken, en dat is als je dynamisch gegenereerde js code wil uitvoeren. en dat heb je nou niet bepaald vaak nodig

ja ikke gebruikt dat nog wel eens... alleen weet ik bijgoed niet meer waarin...

een of andere vage euro/gulden calculatie d8 ik

[crisp]

Ik heb vooralsnog geen code kunnen verzinnen waarin een eval vermeden kan worden (ook al maak ik me toch wel eens schuldig aan het gebruik ervan) op dit stukje code om te kijken of een variabele bestaat en een waarde heeft na:

code:

var x = 10;
var y;

showvar('x');
showvar('y');
showvar('z');

function showvar(theVar) {

  try {
    waarde = eval(theVar);
  }
  catch(error) {
    alert('variabele '+theVar+' bestaat niet');
    return;
  }
  if (waarde == undefined) alert('variabele '+theVar+' bestaat, maar heeft geen waarde');
  else alert('variabele '+theVar+' heeft de waarde: '+waarde);
  return;

}

[Clay]

ook dat kan zonder eval

code:

function showvar(theVar) {
   alert(theVar + ((window[theVar] != undefined)? 
      (' bestaat: '+window[theVar]):' bestaat niet'));
}

Een variabele bestaat altijd als array property op string index van het parent object.
Dit werkt dus ook:

code:

<div id="hoi"></div>

<script>
alert( document['getElementById']('hoi') )
</script>

niet dat je dat zou willen, maar dat werkt iig wel.

[[eNeRGy]]

crisp schreef op 14 augustus 2002 @ 00:36:
Ik heb vooralsnog geen code kunnen verzinnen waarin een eval vermeden kan worden (ook al maak ik me toch wel eens schuldig aan het gebruik ervan) op dit stukje code om te kijken of een variabele bestaat en een waarde heeft na:

[..]

Ehm, waarom zou je dit doen ? In je eigen code weet je toch wel zeker of je een object hebt gedefinieerd ?

[drm]

[eNeRGy]:
Ehm, waarom zou je dit doen ? In je eigen code weet je toch wel zeker of je een object hebt gedefinieerd ?

da's natuurlijk irrelevant in deze discussie

[[eNeRGy]]

Vind je ?
Het gaat erom wanneer je eval() nog gebruikt, Crisp geeft aan dat hij dat doet om te kijken of er variabelen aanwezig zijn.. dat snap ik dus niet.

[crisp]

[eNeRGy] schreef op 14 augustus 2002 @ 10:08:
Vind je ?
Het gaat erom wanneer je eval() nog gebruikt, Crisp geeft aan dat hij dat doet om te kijken of er variabelen aanwezig zijn.. dat snap ik dus niet.

Dat was een hypothetisch geval waar ik een eval op z'n plaats vond; natuurlijk zou je van te voren moeten weten of een variabele wel of niet bestaat; zoniet, dan kan je beter een array maken, en kijken of het array-element wel of niet bestaat.

[[eNeRGy]]

mjah, dan heb je me nog steeds niet overtuigd waarom je een eval() zou willen gebruiken

als je wil weten of objecten bestaan dan vergelijk je ze met null, als je wil weten of een variabele wel of niet aanwezig is ben je gewoon fout aan het proggen

[crisp]

[eNeRGy] schreef op 14 augustus 2002 @ 10:20:
mjah, dan heb je me nog steeds niet overtuigd waarom je een eval() zou willen gebruiken

als je wil weten of objecten bestaan dan vergelijk je ze met null, als je wil weten of een variabele wel of niet aanwezig is ben je gewoon fout aan het proggen

Als ik een niet bestaande variabele vergelijk met null krijg ik een foutmelding dat de variabele niet gedefinieerd is, en stopt mijn script
Hence de eval met een try/catch.
Tuurlijk moet je van tevoren weten of je var wel of niet bestaat, maar daar ging het hier niet om...

[oh,when?]

er is volgens mij nog een reden waarom je eval zou gebruiken. check het volgende:

PHP:

function doEval() {
   var str = "function t(o) { alert(o); }";
   eval (str);
   t ("woei");
}

dus dynamisch javascript. Is niet moeilijk om hier een bruikbare toepassing voor te verzinnen.

edit:
owentje moet eens lezen voordat ie post aangezien clay hem voor was

[[eNeRGy]]

oh,when? schreef op 14 augustus 2002 @ 10:37:
er is volgens mij nog een reden waarom je eval zou gebruiken. check het volgende:

[..]

dus dynamisch javascript. Is niet moeilijk om hier een bruikbare toepassing voor te verzinnen.

edit:
owentje moet eens lezen voordat ie post aangezien clay hem voor was

Nee hoor, ik zie het nog steeds niet

Misschien omdat ik alles in de DOM programmeer dat je dan alles al OO doet en je geen mix hebt van html en js en je daardoor dit soort situaties nooit tegenkomt?

Het zal wel aan mij liggen

[oh,when?]

[eNeRGy] schreef op 14 augustus 2002 @ 10:44:
[...]


Nee hoor, ik zie het nog steeds niet

Misschien omdat ik alles in de DOM programmeer dat je dan alles al OO doet

misschien ligt het aan mij maar ten eerste zou ik het benaderen van een DOM nu niet echt vergelijken met OO programmeren, je bent alleen bezig een tree te manipuleren. Daarnaast is ECMAscript nu niet echt OO taal.

Daarnaast is het een contradictie dat je niet bezig bent met html en javascript tegelijk, aangezien je continue bezig bent met de object tree binnen een pagina ( DOM ) en dus bezig bent met de eigenlijke html.

Je spreekt jezelf dus tegen....

just my two cents...

</flame>

[Clay]

Concreet voorbeeld; form validatie (ja, ik moet/zal um nog eens posten)

- Als je in dit veld dat geselcteerd hebt dan moet daar een veld gedisabled worden
- De waarde van dat veld is de som van dat en dat veld

Elke keer als je een formulier maakt (aannemende dat je ueberhaupt de client side validatie inbouwt) zul je er weer een hele bak validatie code tegenaan moeten scripten, dat is tijdrovend, suf en saai. Daarom ben ik ooit begonnen aan een formvalidatie module, die onderandere dat probleem oplost. Je kan dat ding namelijk een "formRule" voeren in een daarvoor verzonnen syntax, en dat wordt omgebouwd naar een uitvoerbaar stuk js code. Bijvoorbeeld:

code:

// waarschuwingen die posten stoppen
validate.setRule('if getvalue termijn:maand then warnuser',
    'waarschuwing blah')
// rekenen en values naar velden schoppen
validate.setRule('if match lening:NUMBER and match termijn:NUMBER then \
   setvalue premie:[(lening*1.05)/termijn]');

De rule wordt dus omgebwoud tot een geldige if statement (waarbinnen je ook met haken en else kan werken) en met een eval uitgevoerd omdat dit behoorlijk dynamische code is (dynamischer kan denk ik niet). Ik meen dat Cheatah trouwens wel met een eval-loze versie bezig was, maar daarvan weet ik de uitkomst niet helemaal

[[eNeRGy]]

oh,when? schreef op 14 augustus 2002 @ 10:51:
[...]


misschien ligt het aan mij maar ten eerste zou ik het benaderen van een DOM nu niet echt vergelijken met OO programmeren, je bent alleen bezig een tree te manipuleren. Daarnaast is ECMAscript nu niet echt OO taal.

Daarnaast is het een contradictie dat je niet bezig bent met html en javascript tegelijk, aangezien je continue bezig bent met de object tree binnen een pagina ( DOM ) en dus bezig bent met de eigenlijke html.

Je spreekt jezelf dus tegen....

just my two cents...

</flame>

Ja, ik wil echt niet beweren dat ecmascript een volwaardige object orientated taal is hoor

En ik vind niet dat ik mij tegenspreek, je bent inderdaad bezig met een HTML pagina, maar het kan ook pdf, xml, xhtml, etc zijn, dat maakt voor de javascript (bijna) niet uit.

Wat ik doe is objecten maken en die in de DOM zetten, dat is heel wat anders dan <div><h1>wow, ik schrijf HTML</h1></div> schrijven vind ik

[drm]

offtopic:

• [b][eNeRGy] 's sig[/b] [b][i]React, een software pakket door mensen die 1 if() programmeren teveel werk vinden |:([/i]

[[eNeRGy]]

bookmarks
bookmarks anders?

Maar dat heeft verder niets met dit topic te maken.

[oh,when?]

drm schreef op 14 augustus 2002 @ 11:19:

offtopic:

• [b][eNeRGy] 's sig[/b] [b][i]React, een software pakket door mensen die 1 if() programmeren teveel werk vinden |:([/i]

kdenk dat het om deze post gaat: bookmarks