Disable Drop-box Based On Users Selection

B

Blnukem

Hi All

I'm new to javascript and was wondering if someone can help me with
this I want to disable my second and third drop-box if the first one
is selected to "Closed" I think I'm close but just cant get it to work
here is my code:


<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">

<script>
function DisableMondayDropdown(bool)
{
if(document.Monday.Hours == "Closed"){
document.Monday.Hours1.disabled=bool;
document.Monday.Hours2.disabled=bool;
}
}
</script>

<form name=Monday onChange="DisableMondayDropdown(true)">
<select name=Hours>
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>

<select name=Hours1>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

<select name=Hours2>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

</form>

</body>
</html>

If you can help thanks in advance
Blnukem
 
M

Michael Winter

Hi All

I'm new to javascript and was wondering if someone can help me with
this I want to disable my second and third drop-box if the first one
is selected to "Closed" I think I'm close but just cant get it to work
here is my code:


<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">

<script>
Click to expand...

The type attribute is required in SCRIPT elements. You should change this
to

function DisableMondayDropdown(bool)
{
if(document.Monday.Hours == "Closed"){
Click to expand...

I would normally recommend here that you change the above form reference to

document.forms['Monday'].elements['Hours']

however, I'm sure Mr Webb would have something to say about it[1], so I'll
just say that in some circumstances (certainly when id attributes are
involved), the above syntax will work with more browsers.
document.Monday.Hours1.disabled=bool;
document.Monday.Hours2.disabled=bool;
}
}
</script>
Click to expand...

I certainly recommend that you enclose all attribute values in quotes.
<form name=Monday onChange="DisableMondayDropdown(true)">
Click to expand...

The FORM element doesn't have an onchange intrinsic event. However, SELECT
elements do, and that's where you want to place the attribute.
<select name=Hours>
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>
Click to expand...

<snip>

Once you make those alterations, you'll be closer to your goal. However,
you'll notice that there's no way to re-enable the controls you disabled.
Below is a function that you can use instead (renamed to fit its new
functionality).

function toggleMondayDropdown() {
// Get a reference to the form
var mondayForm = document.forms['Monday'];
// If Hours is 'Closed', disable the controls (state is true)
var state = ('Closed' == mondayForm.elements['Hours'].value);

/*
The assignment to state, above, could also be written as:

var state;

if( 'Closed' == mondayForm.elements['Hours'].value )
{
state = true;
} else {
state = false;
}

if that makes the expression any clearer.
*/

mondayForm.elements['Hours1'].disabled = state;
mondayForm.elements['Hours2'].disabled = state;
}

Hope that helps,

Mike


[1] To Mr Webb: I concede that you have a point, but I still think my
reasoning is valid. Yes, one could use getElementById() when id attributes
are involved, but as not all browsers in use support it (that argument is
rapidly diminishing) and, in the case of form-enclosed controls, there
exists an alternative way to access id'd controls, I'll continue to use
the collection syntax. :)

If you prefer that I stop recommending it in cases where references use
names, not ids, then I shall (provided that the shortcut syntax *will*
work in all such cases when compared to the collection syntax).
 
J

Jarmo

Blnukem said:
Hi All

I'm new to javascript and was wondering if someone can help me with
this I want to disable my second and third drop-box if the first one
is selected to "Closed" I think I'm close but just cant get it to work
here is my code:


<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">

<script>
function DisableMondayDropdown(bool)
{
if(document.Monday.Hours == "Closed"){
document.Monday.Hours1.disabled=bool;
document.Monday.Hours2.disabled=bool;
}
}
</script>

<form name=Monday onChange="DisableMondayDropdown(true)">
<select name=Hours>
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>

<select name=Hours1>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

<select name=Hours2>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

</form>

</body>
</html>

If you can help thanks in advance
Blnukem
Click to expand...

Minor changes:

1. compare value, not element, with "Closed"
2. apply onchange handler to the correct element (the select, not the form)

function CheckMondayDropdown()
{
//alert("In change handler");
document.Monday.Hours1.disabled=(document.Monday.Hours.value == "Closed");
document.Monday.Hours2.disabled=(document.Monday.Hours.value == "Closed");
}
</script>

<form name=Monday>
<select name=Hours onChange="CheckMondayDropdown()">
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>
....

PS a handy tip is to add alerts e.g. alert("In change handler"); Had you
done that you would have seen that control was not reaching your onchange
handler.
 
R

Randy Webb

Michael said:
{
if(document.Monday.Hours == "Closed"){
Click to expand...


I would normally recommend here that you change the above form reference to

document.forms['Monday'].elements['Hours']

however, I'm sure Mr Webb would have something to say about it[1], so
I'll just say that in some circumstances (certainly when id attributes
are involved), the above syntax will work with more browsers.
Click to expand...

I don't have a problem with people saying something like this:

If your form uses ID's, then you are safer using this syntax.

Or:

For future compatibility, start learning to use this syntax.

But, to say that its "better" than the other, when used with a name
attribute, is plain wrong.

This code:

<form id="myForm" action="">
<input type="text" value="my value" id="myInput">
<input type="button" value="Show Me"
onclick="alert(document.forms['myForm'].elements['myInput'].value)"</form>

Is utterly useless in NN4.xx and as long as its around (yes, its still
around), then the ID attribute shouldn't be used with a Form. Give it a
name, access it either way, and move on.


[1] To Mr Webb: I concede that you have a point, but I still think my
reasoning is valid. Yes, one could use getElementById() when id
attributes are involved, but as not all browsers in use support it (that
argument is rapidly diminishing) and, in the case of form-enclosed
controls, there exists an alternative way to access id'd controls, I'll
continue to use the collection syntax. :)
Click to expand...

I never said your reasoning for using the same syntax system wide was
flawed. I said your reasoning that document.forms['formName']..... was
better than document.formName...... when named forms are present was flawed.
If you prefer that I stop recommending it in cases where references use
names, not ids, then I shall (provided that the shortcut syntax *will*
work in all such cases when compared to the collection syntax).
Click to expand...

Until a browser is found where it doesn't work, then either is valid
when used with a name.

How about something like this:
<FAQENTRY>
Q. How do I acces a form element?
A. If the elements have an ID, then use the forms collection:
document.forms[formID].elements[elementID]
Note: This fails in older browsers.

If the elements have a NAME attribute then you can use the forms
collection or the short cut syntax:

document.forms['formName'].elements['elementName']
or:
document.formName.elementName
</FAQENTRY>
Maybe in an expanded 4.13?

Richard:
Is it too late to get something like this incorporated in this round of
revisions to the FAQ? It seems to be coming up a lot recently.
 
L

Lasse Reichstein Nielsen

Randy Webb said:
But, to say that its "better" than the other, when used with a name
attribute, is plain wrong.
Click to expand...

I like to think of "following the W3C DOM specification" as being better
than not. But yes, "better" is always subjective.
How about something like this:
<FAQENTRY>
Q. How do I acces a form element?
A. If the elements have an ID, then use the forms collection:
Click to expand...

The problem is not that it has an ID. The problem is that it doesn't
have a name. If it has both, you can use both methods.

So, it should be: If the element *only* has an ID.
If the elements have a NAME attribute then you can use the forms
collection or the short cut syntax:

document.forms['formName'].elements['elementName']
or:
document.formName.elementName
Click to expand...

I see no reason for recommending the second, except that it is shorter,
which I don't count as a qualification at all. If at all, I would
prefer to recommend:
document['formName']['elementName']
since that will get rid of the questions with " my input is called
'foo[]'".

But to keep the FAQ short, I would prefer to recommend only one
notation: the full, W3C DOM compliant, square-bracketed notation. If
people use it, it *will* work, and you won't need to mention the
exception at all ... and all are happy (I wish!).

Actually, I prefer to only refer to the form through the "form"
property of its controls, which again are captured as the "this"
property on handlers assigned to them. I only very rarely need
to refer to a from except from inside itself.

/L
 
R

Richard Cornford

I don't have a problem with people saying something like this:

If your form uses ID's, then you are safer using this syntax.

Or:

For future compatibility, start learning to use this syntax.
Click to expand...

I am not so sure that future-compatibility is going to be a worthwhile
argument, depending on which future is being talked about. With XHTML,
currently Mozilla seem very resistant to implementing the HTMLDocument
(from W3C HTML DOM) on the document object in their XHTML DOM (though
they are implementing the rest of the HTML DOM on the objects under it).
Without that interface all the convenience properties of the document
are gone including the forms collection.

Opera 7, OTOH have implemented HTMLDocument on their XHTML document but
I don't think we will know the shape of the XHTML DOM we will be using
until IE produce a browser that implements it (if ever). If they
implement HTMLDocument Mozilla will probably have to give in and follow
suite, if not then the convenience properties will no longer be usable.

In practice the XHTML future is still a long way off and given the
considerable differences between HTML scripting and XHTML scripting
(namespaces probably being the most significant) I don't see much point
in attempting to designing HTML scripts with compatibility with XHTML
DOMs in mind. Probably better to consider the transition to XHTML as a
watershed and leave worrying about the technicalities until XHTML
becomes practical (which means: supported by the majority of browsers,
if not all).
But, to say that its "better" than the other, when used
with a name attribute, is plain wrong.
Click to expand...

Personally (and other issues aside) I like the:-

document.forms['myform'].elements['myEl']

- style of accessor for the clarity it brings to the source code.
Looking at it there is no question that the subject of the code is a
form and an element of that form. While a named property of the document
might be an image, an applet, an expando or a non-standard browser
feature. Also, I hadn't formalised my reasons for preferring square
bracket notation where the form and element names are concerned but
Lasse described the practice as keeping the separate namespaces
(HTML/DOM) distinct, which describes my feelings on the subject.

For those reasons I think that the longer form property accessors using
the collections are better, but that is a personal opinion.

... NN4.xx and as long as its around (yes, its still
around), then the ID attribute shouldn't be used with
a Form. Give it a name, access it either way, and move on.
Click to expand...

Yes, their is no good excuse for writing code that interacts with forms
in an HTML document in a way that is not compatible with every browser
that understands forms, and certainly all of the browsers in use. It is
probably still the one area of browser scripting where one pattern can
fit all.

<FA ... Y>
Q. How do I acces a form element?
A. If the elements have an ID, then use the forms collection:
document.forms[formID].elements[elementID]
Note: This fails in older browsers.

If the elements have a NAME attribute then you can use
the forms collection or the short cut syntax:

document.forms['formName'].elements['elementName']
or:
document.formName.elementName
</FA ... Y>
Maybe in an expanded 4.13?

Richard:
Is it too late to get something like this incorporated in this
round of revisions to the FAQ? It seems to be coming up a lot
recently.
Click to expand...

I don't want to encourage people to inundate me with new FAQ requests at
this point but currently nothing is final and I am happy to entertain
additional suggestions.

Generally I agree with Lasse and think that:-

<draft>
4.nn How do I access a form element?
Named form elements may be referred to as named properties of
the document.forms collection and named form elements as named
properties of the form's elements collection in HTML documents.

document.forms['formName'].elements['elementName']
<link to something with more details on the issues>
</draft>

- might be the most that would be worth putting in the FAQ on the
subject as that will work. The other issues: anonymous forms/elements,
radio button collections, IDs, combining IDs and NAME attributes, XHTML
and getElementById and W3C HTML DOM compliance probably need to be
referred to in other documents else the posted FAQ risks becoming
enormous.

It would be nice to be able to incorporate this in 4.13 because the FAQ
in general is moving away form direct Netscape 4 support and currently
4.13 is specifically about that browser. Unfortunately changing 4.13 too
much is going to break every reference to it in all the articles in the
archives. I don't really want to do that. A compromise might be to make
it more general:-

<draft>
4.13 How do I get the value of a form element?
Named form elements may be referred to as named properties
of the document.forms collection and named form elements as
named properties of the form's elements collection in HTML
documents:

var el=document.forms['formname'].elements['elementname'];

The value property of such elements can be read directly
from the element:-

var value = el.value;

Except when the element is a SELECT element where it is
necessary to read the value property from the currently
selected OPTION element whenever compatibility with older
browsers (like NN 4) may be necessary:-

var value = el.options[el.selectedIndex'].value;
<link to something with more details on the issues>
</draft>

My suggestion for reconciling the need to keep the posted FAQ small and
the desire to provide the necessary detail, caveats and explanation is
to create a second document of notes on the FAQ and link to it from the
FAQ as necessary. I was thinking that whoever edited the FAQ would also
edit that document but anyone who perceived the need to write a note on
any part of the FAQ could contribute to it (even maybe reproduce some of
the more detailed explanations posted to the group (with the authors
permission) as notes). So if anyone feels like contributing an
explanation of the issues around this subject please do so.

Richard.
 
R

Randy Webb

Richard said:
Randy Webb said:
But, to say that its "better" than the other, when used
with a name attribute, is plain wrong.
Click to expand...


Personally (and other issues aside) I like the:-

document.forms['myform'].elements['myEl']

- style of accessor for the clarity it brings to the source code.
Click to expand...

Clarity is not always the #1 issue. A lot has been said in the last few
years about speed.
Looking at it there is no question that the subject of the code is a
form and an element of that form. While a named property of the document
might be an image, an applet, an expando or a non-standard browser
feature. Also, I hadn't formalised my reasons for preferring square
bracket notation where the form and element names are concerned but
Lasse described the practice as keeping the separate namespaces
(HTML/DOM) distinct, which describes my feelings on the subject.
Click to expand...
I don't want to encourage people to inundate me with new FAQ requests at
this point but currently nothing is final and I am happy to entertain
additional suggestions.
Click to expand...

I agree, I know you have a ton of work on your hands as it is.

Generally I agree with Lasse and think that:-

<draft>
4.nn How do I access a form element?
Named form elements may be referred to as named properties of
the document.forms collection and named form elements as named
properties of the form's elements collection in HTML documents.

document.forms['formName'].elements['elementName']
<link to something with more details on the issues>
</draft>
Click to expand...

Let me start by saying that I made the following page as a test. Which
ever one was the fastest, I was prepared to start using. It didn't
surprise me that shorthand was faster though, to be honest.
<URL:
http://members.aol.com/_ht_a/hikksnotathome/formSpeedTest/index.html />

Is the test page I made to test ShortHand versus LongHand.

I am going to tinker with it some more as its doing 100,000 iterations.
Probably bring it back to 10,000 and loop it 10 times to get an average.
And if it turns out that longhand wins, I will start recommending it.

IE 6.0 - Shorthand
Opera 7 - Shorthand
K-Meleon - Shorthand
Netscape 7 - Long Hand
Mozilla 1.4 - Shorthand

Now, do we recommend clarity, or speed?

Personally, I prefer speed over any gain in clarity. If I need clarity,
I can comment it :)
 
R

Richard Cornford

document.forms['myform'].elements['myEl']

- style of accessor for the clarity it brings to the source code.
Click to expand...

Clarity is not always the #1 issue. A lot has been said in
the last few years about speed.
Click to expand...

And a fair bit of it by me, so I have no right to dismiss the point. And
speed could be a reasonable criteria for "better".
^^^^^^^^^^^^^^^^^^^
That should have read "named forms".

... . It didn't surprise me that shorthand
was faster though, to be honest.
Click to expand...

Nor me.

And if it turns out that longhand wins,
I will start recommending it.
Click to expand...

I don't think the longer version can win. It should take, on average, as
long to resolve - document.forms - as it would to resolve -
document.myForm - because they are both named properties of the same
object. So the additional forms.myForm resolution must always be on top
of that.

Now, do we recommend clarity, or speed?
Click to expand...

I think we start with reliable. From there on we are clearly into the
realms of opinion, and we have:-

1. W3C HTML DOM conformance favouring the longer version
(though it is ambiguous whether it should allow the
shorthand of referring to the elements as named members
of the form, I still think it should).

2. Clarity in source code, favouring the longer version.

3. Execution speed due to the time taken to resolve the
references, favouring the shortcut version.

While I like to promote efficient code, and will even attempt to squeeze
every ounce of performance out of some scripts (mostly DHTML stuff), I
find it difficult to be concerned about the difference in the time it
would take to resolve the longer version against the shorthand. I would
habitually store a form reference in a local variable anyway so it is a
difference that would only apply once (per validation attempt or
whatever). It is also not often you see a form so big that even if each
and every element reference was absolute the difference between the two
property accessors would add up to half a second.

If it became a case where I had to pick one to go into the FAQ (which is
the case if it goes in at all) then it is still going to be the long
version (with bracket notation). The entry could have additional notes
mentioning that there are practical alternatives and that the shorthand
version is faster to resolve (along with all the other points). At this
moment I am not feeling motivated to write those notes, that may change
(or someone else might decide to save me the effort).

I notice that you didn't quote the modified 4.13, do I take that as
implying that you would prefer not to merge this with the existing 4.13
question? (I quite liked that idea)
Personally, I prefer speed over any gain in clarity. If I need
clarity, I can comment it :)
Click to expand...

Richard.
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
Richard Cornford
Generally I agree with Lasse and think that:-

<draft>
4.nn How do I access a form element?
Named form elements may be referred to as named properties of
the document.forms collection and named form elements as named
properties of the form's elements collection in HTML documents.

document.forms['formName'].elements['elementName']
<link to something with more details on the issues>
</draft>

- might be the most that would be worth putting in the FAQ on the
subject as that will work.
Click to expand...


In reading this newsgroup, I see that many incomers seem substantially
ignorant of modularisation and collecting common code; perhaps they are
paid by the yard (an antique measurement, 0.9144m) of code.

ISTM, therefore, that it would be well to give the above as
Frm = document.forms['formName']
Ele = Frm.elements['elementName']
or similar, to give the clue that Frm can be used for getting other
elements.

Re FAQ 4.13 link : IIRC, that was a good one; or, more globally, the
third link in 3.2, http://devedge.netscape.com/library/manuals/2000/java
script/1.3/reference/, is/was good - better than the 1.5 version,
provided that it is used with care.

I suspect that it may be worth-while using a links-checker on the FAQ
from time to time; those not found can be given a temporary "where is
it" mark.


If the FAQ is getting a complete make-over, ISTM that it might be worth
classifying the contents of Sec. 4 by topics (which wasn't necessary
when it started). Possible topics include windows, strings, DOM, maths,
miscellaneous. One might, to avoid confusion, put the repositioned
answers in Sec 6, replace Sec 4 by its own index as at the top, and
change those links to lead to the answers in Sec 6.
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
Personally, I prefer speed over any gain in clarity. If I need clarity,
I can comment it :)
Click to expand...

Remembering that comment slows transmission and interpretation.


ISTM that one only rarely needs to use // for anything other than
comment-to-end-of-line, or /* for other than comment to next */.

String and RegExp literals, maybe; and easily avoidable in strings.

Could a Web page be written with two textareas and a button between,
such that a general or slightly restricted valid page could be copied
into the first, with the button causing a version without comment,
indentation, or multiple newlines to appear in the second?

(The impossible reverse would be very useful, though an indenter should
be possible).
 
L

Lasse Reichstein Nielsen

Randy Webb said:
Now, do we recommend clarity, or speed?
Click to expand...

In a FAQ: Clarity, without exception.
Speed at most gets a foot note.
Personally, I prefer speed over any gain in clarity. If I need
clarity, I can comment it :)
Click to expand...

In your own code, you are free to do as you prefer. :)

/L
 
R

Randy Webb

Lasse said:
In a FAQ: Clarity, without exception.
Speed at most gets a foot note.
Click to expand...

Then why do we recommend +varName to convert to a number when
parseInt/parseFloat(varName) is more concise?

http://www.jibbering.com/faq/#FAQ4_21

And yes, + is the preferred/recommended way.

Which is it? Clarity or Speed?
In your own code, you are free to do as you prefer. :)
Click to expand...

And I prefer to teach the most efficient/fastest method. See above.
 
R

Randy Webb

Richard said:
<snip>
Click to expand...

I think we start with reliable. From there on we are clearly into the
realms of opinion, and we have:-
Click to expand...
1. W3C HTML DOM conformance favouring the longer version
(though it is ambiguous whether it should allow the
shorthand of referring to the elements as named members
of the form, I still think it should).
Click to expand...

Fair enough, even though I personally thing too much weight/discussion
2. Clarity in source code, favouring the longer version.
Click to expand...

See my reply to Lasse, with regards to + versus parseInt. Every one of
us is quick to point out that its "better" to use + because it is
marginally faster.

Now, we are all saying "No, faster isn't better, clarity is" ???
3. Execution speed due to the time taken to resolve the
references, favouring the shortcut version.

While I like to promote efficient code, and will even attempt to squeeze
every ounce of performance out of some scripts (mostly DHTML stuff), I
find it difficult to be concerned about the difference in the time it
would take to resolve the longer version against the shorthand. I would
habitually store a form reference in a local variable anyway so it is a
difference that would only apply once (per validation attempt or
whatever). It is also not often you see a form so big that even if each
and every element reference was absolute the difference between the two
property accessors would add up to half a second.
Click to expand...

In reality, none of the speed matters. Not with +, form references, or
any other methods. Not even eval <shudder>. If any one of us made a
simple test page that used all of the available ways to convert from a
string to a number, one time, none of us could see a difference. But
thats beside the point (Or not at least until you get into real heavy
dHTML apps).
If it became a case where I had to pick one to go into the FAQ (which is
the case if it goes in at all) then it is still going to be the long
version (with bracket notation). The entry could have additional notes
mentioning that there are practical alternatives and that the shorthand
version is faster to resolve (along with all the other points). At this
moment I am not feeling motivated to write those notes, that may change
(or someone else might decide to save me the effort).
Click to expand...

As long as notes are made that with a NAME attribute that either way
works and that the shorthand is marginally faster, its fine.
I notice that you didn't quote the modified 4.13, do I take that as
implying that you would prefer not to merge this with the existing 4.13
question? (I quite liked that idea)
Click to expand...


I think you are asking if I like the idea of merging the two, and I do.
Might be better in 4.39 where it already discusses bracket notation though.

Either place, or even linked to a website about it. I just think it
should be explained (both ways, along with both ways
advantages/drawbacks) how to access a form and its elements in the FAQ.
And then let the script author decide whether they want clarity or speed.
 
R

Randy Webb

Lasse said:
parseInt and parseFloat are not more concise because you have to tell
about the exceptions: the radix on parseInt and the acceptance of
garbage after the number on both.
Click to expand...

Very true.
The appropriately named Number function (part of the "conversion
family" also including Boolean and String) is easier to recognize
and understand. It does exactly the same as the prefix plus, and
the only difference is that it is one function call slower and
five characters longer.
Click to expand...

Slower yet more concise. Which is exactly my point.
I would use Number there, for clarity. And maybe add a footnote saying
that prefix plus is equivalent and slightly faster, but should be used
with care to avoid writing "++" by accident.
Click to expand...

Wait now, the FAQ (which is what this is all about) says to use +
because its faster but we want a new entry that uses a slower technique
for clarity?

But I tend to agree with you, in a sense, that 4.21 might benefit from a
little expansion into the clarity/speed side.
 
R

Richard Cornford

Fair enough, even though I personally thing too much
weight/discussion is given to W3C, ECMAScript, or any
other "regulating body". <shrug>
Click to expand...

I don't think we can get away from ECMA 262, its algorithms define what
is "correct" for the language. Not that there is much that can be done
if an interpreter is identified as objectively wrong. There are also
job/task specifications that vaguely call for coding to conform to
"applicable web standards" so there is some value in knowing what those
standards are, and their implications.
See my reply to Lasse, with regards to + versus parseInt.
Every one of us is quick to point out that its "better" to
use + because it is marginally faster.
Click to expand...

Incidentally, for clarity I usually wrap unary + operations in
parenthesise.
Now, we are all saying "No, faster isn't better, clarity is" ???
Click to expand...

I think we are saying that when initially presenting the subject clarity
is better. But from then on an explanation including aspects like
efficient use (possibly of alternatives) would not be out of place.
Giving people enough to make informed decisions for themselves seems
like the ideal approach, unfortunately that will usually be impractical
within the quick answers section of the FAQ.

In reality, none of the speed matters.
Click to expand...

I don't think I would consider it good style to write inefficient code
without some other definite justification for doing so. But the
comprehensibility for collages[1] of the resulting code would be one
justification, so long as the result wasn't ridiculously inefficient.
Not with +, form references, or any other methods.
Not even eval <shudder>. If any one of us made a simple test
page that used all of the available ways to convert from a
string to a number, one time, none of us could see a difference.
Click to expand...

Human reaction time is about 0.4 seconds so anything that happens
quicker than that is going to be difficult to perceive. With code the
relevance of efficiency comes down to how all of the individual
imperceptibly fast statements add up.
But thats beside the point (Or not at least
until you get into real heavy dHTML apps).
Click to expand...

Maybe the value in discussing and promoting fast implementation in
JavaScript is so that bad habits that are insignificant in form
validation code are not carried over into DHTML where they might serve
to cripple the code on slower systems?

As long as notes are made that with a NAME attribute that
either way works and that the shorthand is marginally
faster, its fine.
Click to expand...

If you are satisfied with those conditions I will have a go at writing
those notes.
I think you are asking if I like the
idea of merging the two, and I do.
Click to expand...

I was, and good! That is the way I will go, unless anyone objects.
Might be better in 4.39 where it already
discusses bracket notation though.
Click to expand...

My page, linked to from 4.39, has an example of the shortcut form
accessor. At the time I didn't want to use that example but I needed a
common and recognisable accessor that wasn't too complex for the
example. But I don't think 4.39 (and the related document) is
appropriate for a discussion about forms and accessing them
specifically. Better if it sticks with the square bracket syntax in
general.
Either place, or even linked to a website about it. I just
think it should be explained (both ways, along with both ways
advantages/drawbacks) how to access a form and its elements in
the FAQ. And then let the script author decide whether they want
clarity or speed.
Click to expand...

I didn't want to get into writing notes on form access because of all of
the other issues that equally deserve coverage. The alternative
accessors and their merits/drawbacks are relatively easy in comparison
with the ID/XHTML issues, but it looks like I am going to have to.

Richard.

[1] That only applies to colleges who would understand JavaScript
anyway. Colleges who understand only other languages have no right to
expect me to write:-

var divStyle = (div && div.style) ? div.style : div;

- instead of -

var disStyle = (div && div.style) || div;

-just because in their languages the result of the second expression
would be boolean not an object reference. Even though the code that
followed the second statement would be initially incomprehensible to a
programmer only familiar with, say, Java, as they would be surprised to
find the boolean result they expected being treated as an object.
 
R

Richard Cornford

ISTM, therefore, that it would be well to give the above as
Frm = document.forms['formName']
Ele = Frm.elements['elementName']
or similar, to give the clue that Frm can be used for
getting other elements.
Click to expand...

In most cases when I want to reference multiple form elements (might
have to start calling them controls in the FAQ from now on) I assign a
reference to the form's elements collection to a local variable so that
it does not need to be re-resolved as a member of the form.
Re FAQ 4.13 link : IIRC, that was a good one; or, more globally,
the third link in 3.2, http://devedge.netscape.com/library/manuals/
2000/java script/1.3/reference/, is/was good - better than
the 1.5 version, provided that it is used with care.
Click to expand...

That's a good point. I will try and keep the reference to the 1.3 doce
in somewhere.
I suspect that it may be worth-while using a links-checker on
the FAQ from time to time; those not found can be given a
temporary "where is it" mark.
Click to expand...

Jim's scripts check the references when they build the page (and
apparently style them differently in the HTML version if not found). But
I will be (have been) verifying them anyway ( I have already found that
the second in 2.3 is apparently no longer there).
If the FAQ is getting a complete make-over, ISTM that it might
be worth classifying the contents of Sec. 4 by topics (which
wasn't necessary when it started).
Click to expand...

Unfortunately it isn't that simple as reordering section 4 would throw
off all of the references to it in the archives (the anchors are
generated dynamically from the order in the XML) and on the whole I
think that sacrificing the usefulness of the archives is something I
don't want to do right now.

Given enough time it might be possible to re-do the scripts and XML
format to avoid that problem, but I should probably get this revision
complete first.

Richard.
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
Then why do we recommend +varName to convert to a number when
parseInt/parseFloat(varName) is more concise?
Click to expand...

They can seem more concise only to those who do not know the meaning of
the word, as given by Oxford & Webster. They might be considered more
explicit.

It seems impossible to express an action more concisely than by a single
character; and + is easy to explain because the whole operand is a
standard number (or 0x<hex>) and there is no need to go into the
termination condition.
 
J

Jim Ley

Unfortunately it isn't that simple as reordering section 4 would throw
off all of the references to it in the archives (the anchors are
generated dynamically from the order in the XML) and on the whole I
think that sacrificing the usefulness of the archives is something I
don't want to do right now.
Click to expand...

This was a severe oversight on my part, in retrospect I should not
have used numbers, but named faq's for the quick answers when I took
over.

Jim.
 
R

Randy Webb

Dr said:
JRS: In article <[email protected]>, seen in



They can seem more concise only to those who do not know the meaning of
the word, as given by Oxford & Webster. They might be considered more
explicit.
Click to expand...

Point taken, and I will make note of it next time, to look up all words
that I use in the dictionary.

As for a definition, the dictionary I use defines explicit as:

1 a : fully revealed or expressed without vagueness, implication, or
ambiguity : leaving no question as to meaning or intent <explicit
instructions>

And you are indeed correct that its a more explicit word to use.
It seems impossible to express an action more concisely than by a single
character; and + is easy to explain because the whole operand is a
standard number (or 0x<hex>) and there is no need to go into the
termination condition.
Click to expand...

Your argument is that +varName leaves less question as to meaning than
using Number(varName) does?

The plus sign has two uses in javascript, the Number function only has
one. Fewer uses means less confusion, less confusion leads to explicity.
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
Your argument is that +varName leaves less question as to meaning than
using Number(varName) does?
Click to expand...

No. Perhaps you still have not looked up "concise".
The plus sign has two uses in javascript, the Number function only has
one. Fewer uses means less confusion, less confusion leads to explicity.
Click to expand...

The second sentence, apart from having an unknown word, is generally
true. The plus sign has three distinct uses : binary, with at least one
string operand, is concatenation; binary, with two numbers, is addition;
unary is return a number.

But the binary operator + is very well known in arithmetic - it is
probably still taught in schools - and the unary is almost as well
known; the presence, in code, of a + that can only be a unary + should
cause no difficulty whatsoever in the second and subsequent occasions
when one is seen.

On the first occasion, there may be surprise; but, on the presumption
that it serves a purpose, there is only one reasonable interpretation :
that the result is a number.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Survey details won't go through using php, ajax, Mysql 0
Uncaught ReferenceError: item is not defined at HTMLButtonElement.onclick in the: <button onclick="item.inserir()">Inserir dados</button> 1
I dont get this. Please help me!! 2
Need Help, Both submit button works same, i need both submit button works differently, the one button override other button 3
Very Basic CC Validation Javascript 0
HCaptcha - How to stop page from refreshing on submit if captcha is not checked/validated 1
Limit selection in list Box 4
How do I get the if statement correct in the lines that has it in the program? 2

Members online

No members online now.
Total: 51 (members: 0, guests: 51)
Robots: 63

Forum statistics

Threads
473,774
Messages
2,569,600
Members
45,179
Latest member
pkhumanis73

Latest Threads

Top