Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #17188

Re: JavaScript Case Project 3-1: The dreaded NaN error

Message-ID <1660368.mReO0LyTN9@PointedEars.de> (permalink)
From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization PointedEars Software (PES)
Date 2012-11-12 11:49 +0100
Subject Re: JavaScript Case Project 3-1: The dreaded NaN error
Newsgroups comp.lang.javascript
References <055e7215-93ba-40a9-81f3-312ea0e4f5e2@googlegroups.com> <k7qdb9$a45$1@dont-email.me>
Followup-To comp.lang.javascript

Followups directed to: comp.lang.javascript

Show all headers | View raw


Gregor Kofler wrote:

> Am 2012-11-11 17:28, dmn2004404@gmail.com meinte:
> 
> [snip]
> 
>> <head>
>> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

This line is meaningless in XHTML unless parsed as text/html.  The XHTML 
document has to be well-formed before this line is parsed.

>> <title>Untitled Document</title>

Pardon?

>> <script type="text/javascript">
>> var purchasePrice = txtPurchasePrice.value, shippingAndHandling,
>> totalCost;

Should be

  var purchasePrice = txtPurchasePrice.value;
  var shippingAndHandling, totalCost;

to keep the code readable to begin with.
 
> Should already throw an error (reference error), since txtPurchasePrice
> is undefined at this point and txtPurchasePrice.value can't be evaluated.

The correct explanation for a ReferenceError exception at this line would be 
that no object in the scope chain has a `txtPurchasePrice' property.  
(Accessing a property of `undefined' would throw a TypeError exception 
instead.)

The former would be the case here because the element named 
`txtPurchasePrice' further below in this HTML document, which could create a 
corresponding property on the Global or window objects, both of which are in 
the scope chain in a browser context, the latter for backwards 
compatibility, has not been parsed yet.

Such referencing is error-prone to begin with, of course.  Form controls 
should be referenced through the `elements' collection of an item of the 
`forms' collection of object implementing the HTMLDocument interface, such 
as that referred to by `document' or `window.document' in browsers …

>> function calculateShipping() {
> 
> Something like
> 
> var purchasePrice =
> parseFloat(document.forms["form1"].elements["txtPurchasePrice"].value)
> 
> *in* the function should do the trick.

… as can be seen here.
 
> (Multiplying a "float-like" string with a float will also result in a
> float).

Whereas all Number values are floating-point values in these languages.

>>      if (purchasePrice <= 25)

This is _not_ Valid XHTML because the content model of the XHTML `script' 
element is PCDATA, and `<' is considered a markup special character (Start 
TAG Open [STAGO] delimiter) there.  Either mark up the content of the 
`script' element as CDATA (using single-line comments to hide it from script 
engines when the markup is not parsed as XHTML) –

  <script type="text/javascript">
  //<![CDATA[

  //]]>
  </script>

or do not declare, and do not use XHTML.

>>          shippingAndHandling = 1.50;
>>      else
>>          shippingAndHandling = purchasePrice * .10;
>>      totalCost = purchasePrice + shippingAndHandling;
>> window.alert('Purchase price plus shipping and handling is $' +
>> totalCost); }

window.alert() should not be used to convey purely informational messages.

>> </script>
>> </head>
> 
>> For the record, I've also tried changing "txtPurchasePrice.value" to
>> "document.getElementById('txtPurchasePrice').value"
> 
> Depends *when* you try to reference the element.

And with unqualified references on which rendering mode is used.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Back to comp.lang.javascript | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

JavaScript Case Project 3-1: The dreaded NaN error dmn2004404@gmail.com - 2012-11-11 08:28 -0800
  Re: JavaScript Case Project 3-1: The dreaded NaN error "Mel Smith" <med_cutout_syntel@aol.com> - 2012-11-11 10:08 -0700
    Re: JavaScript Case Project 3-1: The dreaded NaN error dmn2004404@gmail.com - 2012-11-11 09:34 -0800
      Re: JavaScript Case Project 3-1: The dreaded NaN error "Mel Smith" <med_cutout_syntel@aol.com> - 2012-11-11 10:56 -0700
        Re: JavaScript Case Project 3-1: The dreaded NaN error dmn2004404@gmail.com - 2012-11-11 10:07 -0800
        Re: JavaScript Case Project 3-1: The dreaded NaN error dmn2004404@gmail.com - 2012-11-11 10:52 -0800
          Re: JavaScript Case Project 3-1: The dreaded NaN error JJ <jaejunks@glegooilma-swapit.com> - 2012-11-11 20:15 +0000
            Re: JavaScript Case Project 3-1: The dreaded NaN error dmn2004404@gmail.com - 2012-11-11 12:45 -0800
          Re: JavaScript Case Project 3-1: The dreaded NaN error JJ <jaejunks@glegooilma-swapit.com> - 2012-11-11 20:11 +0000
        Re: JavaScript Case Project 3-1: The dreaded NaN error dmn2004404@gmail.com - 2012-11-11 12:15 -0800
          Re: JavaScript Case Project 3-1: The dreaded NaN error Osmo Saarikumpu <osmo@weppipakki.com> - 2012-11-12 10:10 +0200
  Re: JavaScript Case Project 3-1: The dreaded NaN error Gregor Kofler <usenet@gregorkofler.com> - 2012-11-12 09:51 +0100
    Re: JavaScript Case Project 3-1: The dreaded NaN error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-12 11:49 +0100

csiph-web