/
index.html
729 lines (653 loc) · 33.1 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head><title>Referencing Forms and Form Controls</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="../../faq.css" rel="stylesheet" type="text/css">
<link href="../notes.css" rel="stylesheet" type="text/css">
<style type="text/css">
.commentJS {
background-color: #FFFFCC;
color: #004800;
}
P CODE {
background-color: #FFFFDD;
color: #000000;
padding: 0ex;
margin: 0ex;
}
</style>
</head>
<body>
<h1 id="faHead">Referencing Forms and Form Controls</h1>
<div id="faqNav">
<a href="../../">FAQ</a> > <a href="../">FAQ Notes</a>
</div>
<ul>
<li><a href="#faInt">Introduction</a>
<ul>
<li><a href="#faInF">Forms</a></li>
<li><a href="#faInC">Form Controls</a></li>
</ul>
</li>
<li><a href="#faShrt">Shortcut Accessors</a></li>
<li><a href="#faComMis">The Most Common Mistake</a></li>
<li><a href="#faAnon">Anonymous Form References</a></li>
<li><a href="#faBut">Radio Button and Other Control Collections</a></li>
<li><a href="#faEff">Efficient use of Form Accessors</a></li>
</ul>
<h2 id="faInt">Introduction</h2>
<h3 id="faInF">Forms</h3>
<p id="faInF_1">
When the W3C defined the <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DOM specification much of what they included
represented a formalisation of existing browser behaviour. In particular they
defined "convenience" properties on the <code>HTMLDocument</code>
interface that reproduce document level collections common in preceding
browsers. Of specific interest here is the <code>document.forms</code>
collection, which makes all of the <code>FORM</code> elements on a page
available as (zero based) indexed members of the collection. Allowing,
for example, the second <code>FORM</code> element on a page to be
referenced as:-
</p>
<pre id="faInF_ex1">
var formElement = document.forms[1];
</pre>
<p id="faInF_2">
<span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> (but not necessarily XHTML) <code>FORM</code> elements are allowed
<code>NAME</code> attributes and the <code>document.forms</code> collection
also makes <code>FORM</code> elements with <code>NAME</code> attributes
available as named members, under a property name that corresponds with
value of the <code>NAME</code> attribute. So given a form with the
attribute <code>name="myForm"</code> the form can be referenced
as:-
</p>
<pre id="faInF_ex2">
var formElement = document.forms.myForm;
<span class="commentJS">/* - or - */</span>
var formElement = document.forms["myForm"];
<span class="commentJS">/* The latter, bracket notation, does not impose the same restrictions
on the character sequence used for the name as is imposed by the
preceding dot notation, which is restricted to only using character
sequences that would fulfill the ECMAScript definition of an
identifier.
Bracket notation is often preferred when accessing form elements as
it helps to document itself by making it clear in the source code
which property names originate in the <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> rather than the DOM.
*/</span>
</pre>
<p id="faInF_3">
The <code>document.forms</code> collection had exhibited this behaviour
in all of the preceding browsers that implemented it (which included
all the browsers that understood what a form was) and as a result
represents the most cross-browser method of accessing <code>FORM</code>
elements. It is both W3C <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DOM standard compliant and
back-compatible with pre-existing browsers.
</p>
<p id="faInF_4">
The W3C went on to require <code>FORM</code> elements with
<code>ID</code> attributes to also be made available as named properties
of the <code>document.forms</code> collection. That represented a
formalisation of behaviour already exhibited in IE 4 but not by
Netscape 4 (and earlier). Referencing <code>ID</code>ed <code>FORM</code>
elements as named properties of the <code>document.forms</code> collection
should work reliably in all W3C <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DOM compliant browsers but some
back-compatibility will be sacrificed if <code>ID</code>s are used instead
of <code>NAME</code>s (though not nearly as much as would be lost if
<code>ID</code>ed form elements were referenced using the
<code>document.getElementById</code> method).
</p>
<p id="faInF_5">
When writing <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> that conforms to a DTD that allows <code>FORM</code>
elements to have <code>NAME</code> attributes it is possible to also give
the <code>FORM</code> element an <code>ID</code> attribute that corresponds
with its <code>NAME</code> attribute (so long as the <code>ID</code> is
unique on the page). The form will appear as a member of the
<code>document.forms</code> collection under a property name that
corresponds with the value of the <code>NAME</code> and <code>ID</code>
attributes (as they are identical).
</p>
<h3 id="faInC">Form Controls</h3>
<p id="faInC_1">
Traditionally browsers that implemented the <code>document.forms</code>
collection also made the controls within a form available as a
collection accessible as a property of the <code>FORM</code> element
under the name <code>elements</code>. The W3C <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DOM also formalised
this collection in the <code>HTMLFormElement</code> interface.
Controls within a form can be referenced as integer indexed members of
that collection:-
</p>
<pre id="faInC_ex1">
var formElement = document.forms["myForm"];
var controlElement = formElement.elements[2]; <span class="commentJS">//Third control in the form.</span>
</pre>
<p id="faInC_2">
Controlls with <code>NAME</code> attributes are again made available as
named properties of the collection. So a control with
<code>name="myControl"</code> can be referenced as:-
</p>
<pre id="faInC_ex2">
var controlElement = formElement.elements["myControl"];
</pre>
<p id="faInC_3">
Again the W3C also specified that controls with <code>ID</code>
attributes should be made available as named members of the
elements collection under their <code>ID</code>s (with the same
implications for back-compatibility with really ancient browsers).
All official (x)<span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DTDs allow form controls to have
<code>NAME</code> attributes because without a <code>NAME</code>
attribute the value of the control cannot be sent as a
name/value pair when the form is submitted.
</p>
<h2 id="faShrt">Shortcut Accessors</h2>
<p id="faShrt_1">
In addition to making named <code>FORM</code> elements available
as named properties of the <code>document.forms</code> collection
web browsers also make them available as named properties of the
<code>document</code> object. So:-
</p>
<pre id="faShrt_ex1">
var formElement = document.myForm;
</pre>
<p id="faShrt_2">
-will reference the same FORM element as:-
</p>
<pre id="faShrt_ex2">
var formElement = document.forms.myForm;
</pre>
<p id="faShrt_3">
And the same is true using bracket notation:-
</p>
<pre id="faShrt_ex3">
var formElement = document["myForm"];
<span class="commentJS">/* instead of:- */ </span>
var formElement = document.forms["myForm"];
</pre>
<p id="faShrt_4">
The W3C did not include this shortcut in the <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DOM specifications
so code that uses it cannot be described as standards compliant and,
while nobody has been able to name an <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> browser where the shortcut
accessors do not work when referencing named <code>FORM</code>
elements, it would still be possible for a future standards compliant
browser not to support the shortcut accessors.
</p>
<p id="faShrt_5">
<code>FORM</code> elements that only have <code>ID</code> attributes
cannot be accessed as properties of the <code>document</code> object
under a property name that corresponds with their <code>ID</code>
attributes. While by W3C <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DOM specification (but not necessarily
on older browsers) <code>ID</code>ed forms are made available as named
properties of the <code>document.forms</code> collections under a
property name that corresponds with the <code>ID</code>.
</p>
<p id="faShrt_6">
Form controls can be referenced as named properties of the
<code>FORM</code> element that contains them with a shortcut accessor:-
</p>
<pre id="faShrt_ex4">
var formControl = formElement.myControl;
<span class="commentJS">/* instead of :- */</span>
var formControl = fromElement.elements.myControl;
</pre>
<p id="faShrt_7">
But in the case of form controls, elements with <code>ID</code>
attributes may be available as properties of the <code>FORM</code>
element under a property name that corresponds with their
<code>ID</code> (at least on more recent browsers).
</p>
<p id="faShrt_8">
The main argument in favour of using shortcut accessors (apart from the
reduced amount of typing) is that they are resolved fractionally quicker
than accessors that employ the <code>forms</code> and
<code>elements</code> collections. That follows from the fact that fewer
object references need to be resolved before the reference to the element
of interest is returned.
</p>
<p id="faShrt_9">
While arguments against the shortcut accessors point out that named image,
embed and other elements are also made available as named properties of
the <code>document</code> object, making it ambiguous when reading the
source code whether the shortcut accessor is referring to a form or some
other named property of the <code>document</code> object. When a
<code>FORM</code> element is referenced as a member of the
<code>document.forms</code> collection, or a control as a member of the
<code>elements</code> collection, there can be no doubt while reading
the source code as to the type of element that is the subject of the
reference.
</p>
<h2 id="faComMis">The Most Common Mistake</h2>
<p id="faComMis_1">
The most common mistake made when defining the form <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> that a script
will interact with follows from the existence of the shortcut accessors
for form controls. It is to give the control a <code>NAME</code> (or
possibly <code>ID</code>) that corresponds with an existing property of
<code>FORM</code> elements. And the most common example of that is an
<code>INPUT</code> element of <code>type="submit"</code> with
the <code>NAME</code> "submit". Because the named controls are
made available as named properties of the <code>FORM</code> element this
<code>INPUT</code> element is made available under the property name
<code>"submit"</code>. Unfortunately <code>FORM</code> elements
already have a property with the name <code>"submit"</code>, it
is the <code>submit</code> method that can be used to submit the form
with a script. The misguided choice of name for the <code>INPUT</code>
element effectively renders the form's <code>submit</code> method
unscriptable. And the same is true for all controls with names that
correspond any with existing <code>FORM</code> element properties.
</p>
<p id="faComMis_2">
Because ECMAScript is case sensitive it may only be necessary to
capitalise the name of the <code>INPUT</code> element to avoid the
conflict. However, it would probably be safest to adopt a naming
convention for form controls that ensured that they do not
correspond with existing properties of the <code>FORM</code> elements
regardless of case. Especially as theW3C <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> specification implies
that referring to named properties of collections can be case
insensitive in <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span> DOMs. In reality I don't know of any
implementations in which it is but it would be better to err on the side
of caution.
</p>
<p id="faComMis_3">
Another naming conflict that should be avoided would arise if named form
controls had names that correspond with the string representations of
integers, such as <code>name="1"</code> as they will almost
certainly result in inconsistent results (across browsers) when being
referenced because the controls are already available by integer index
and it would become unclear which control was being referenced by
accessors such as <code>formElement.elements[1]</code> or
<code>formElement.elements["1"]</code> (by the ECMAScript
specification the preceding two property accessors are equivalent).
Unless the control with the name <code>"1"</code> also
happened to be the control with the index 1. This problem would also
apply to <code>FORM</code> elements within the <code>document.forms</code>
collection.
</p>
<p id="faComMis_4">
Generally it is best to only give form controls names that cannot
conflict with existing properties of <code>FORM</code> elements
and <code>FORM</code> elements names that cannot conflict with
existing properties of the <code>document.forms</code> collection
or the <code>document</code> object.
</p>
<h2 id="faAnon">Anonymous Form References</h2>
<p id="faAnon_1">
Because <code>FORM</code> elements are available as integer indexed
member of the <code>document.forms</code> collection it is not
necessary to know the name of a form (or for the form to have a
name) to acquire a reference to it. While being able to refer to a
form anonymously with its index might seem like a good approach
towards making more general/flexible functions for form validation
and the like, in practice referring to forms by their index actually
makes code less flexible and harder to maintain. As soon as the
number or layout of forms on a page is changed their indexes also
change, requiring that all of the references by index be located
and altered.
</p>
<p id="faAnon_2">
One method of avoiding having to know the name of a <code>FORM</code>
element within a function that is to act upon a form is to pass a
reference to the form object as an argument in the function call.
This is easiest achieved from the code provided as the value for
an event handling attribute because that code is used by the browser
to create an event handling function that is assigned as a method of
the element to which it is attached. And in any function executed as
a method of an object the <code>this</code> keyword is a reference to
the object with which the execution of the method is associated. The
most common need to anonymously pass a reference to a <code>FORM</code>
element is as an argument to a form validation function in the
onsubmit handler of the form. In that case the event handling function
is a method of the <code>FORM</code> element so the <code>this</code>
keyword refers to the form directly:-
</p>
<pre id="faAnon_ex1">
function validateForm(formRef){
<span class="commentJS">/* Use the reference to the form passed as the formal
parameter - formRef - to acquire a reference to the form
control with the name "textField":
*/</span>
var el = formRef && formRef.elements["textField"];
<span class="commentJS">/* If the control reference exists return its value property
converted to a boolean value (false if empty, true otherwise)
else return true so the form is submitted and the server can
do the validation:
*/</span>
return !el || Boolean(el.value);
}
...
<form action="http://example.com/somePage.asp"
onsubmit="return validateForm(this);">
<input type="text" name="textField" value="">
<input type="submit" name="Submit_Button" value="Submit">
</form>
</pre>
<p id="faAnon_3">
Because the above function receives the reference to the form that it
is to validate as an argument when it is called it can also be used
with any number of other forms. Although in the case of the above
function each of those forms would need to contain a field called
<code>"textField"</code>, but that string name could also be
passed as an argument, making the function more general.
</p>
<p id="faAnon_4">
Form control objects all have a property named
<code>"form"</code> that holds a reference to the
<code>FORM</code> element that contains them. As a result the event
handling functions attached to form controls can pass an anonymous
reference to the form that contains them as <code>this.form</code>.
Obviously a function called from an event handler on a control can
be passes an anonymous reference to the control itself as
<code>this</code>.
</p>
<h2 id="faBut">Radio Button and Other Control Collections</h2>
<p id="faBut_1">
Radio button controls work to provide a selection of one item of many
when each of the radio button alternatives has the same
<code>NAME</code> attribute. But it is also possible to give other types
of control the same <code>NAME</code> attribute.
</p>
<p id="faBut_2">
When controls that share the same <code>NAME</code> attribute they can
still be accessed as integer indexed members of the <code>FORM</code>
element's <code>elements</code> collection but when the member of the
<code>elements</code> collection is accessed using the <code>NAME</code>
attribute value as a property name browsers return a collection all of
the elements with the corresponding NAME attributes. So given the <span class="initialism" title="HyperText Mark-up Language"><abbr title="HyperText Mark-up Language">HTML</abbr></span>:-
</p>
<pre id="faBut_ex1">
<form name="testForm" action="http://example.com/somePage.jsp">
<ul style="list-style-type:none;">
<li><input type="radio" name="radioSet" value="R1">option 1</li>
<li><input type="radio" name="radioSet" value="R2">option 2</li>
<li><input type="radio" name="radioSet" value="R3">option 3</li>
<li><input type="radio" name="radioSet" value="R4">option 4</li>
</ul>
<input type="submit" name="Submit_Button" value="Send">
</form>
</pre>
<p id="faBut_3">
A property accessor referring to the member of the <code>FORM</code>'s
<code>elements</code> collection by the property name
<code>"radioSet"</code> will not return a reference to any one
of the named radio buttons but instead returns a collection of all of the
like-named radio controls.
</p>
<p id="faBut_4">
The individual radio buttons within that collection are referred to as
integer indexed members of that collection. So to find the button that
is checked one might loop through all of the members of the collection
of like-named radio buttons and copy a reference to the button with its
<code>checked</code> property set to boolean <code>true</code>.
</p>
<pre id="faBut_ex2">
var radioCollection, checkedButton;
var frm = document.forms["testForm"];
if(frm){
radioCollection = frm.elements["radioSet"];
if(radioCollection){
<span class="commentJS">/* The collection of like-named radio buttons has a length
property and that is used to limit a for loop:-
*/</span>
for(var c = 0;c < radioCollection.length;c++){
<span class="commentJS">/* The individual radio buttons are accessed as indexed
members of the collection using the loop counter - c
- from the for loop:
*/</span>
if(radioCollection[c].checked){
<span class="commentJS">/* When a radio button element is found with its
checked property set to boolean true a reference
to that element is assigned to the local variable
- checkedButton - and the loop is terminated with
the - break - statement as only one button in a set
of like-named radio buttons will be checked at a
time, so any remaining buttons in the collection
must have checked properties set to false:
*/</span>
checkedButton = radioCollection[c];
break;
}
}
if(checkedButton){
<span class="commentJS">/* Do something with the reference to the checked radio
button (if any).
*/</span>
...
}
}
}
</pre>
<p id="faBut_5">
It is not unusual when a form is generated by a server-side script that
some forms may have one or more like-named controls. If there is only
one control inserted in the form then accessing a member of the
<code>elements</code> collection with its name will return a reference
to that one control, but if there are multiple elements the returned
reference will be to a collection of such controls. While it may be
possible to branch client-side code that wants to interact with those
controls to handle the two alternatives it adds an unnecessary
maintenance burden to do so.
</p>
<p id="faBut_6">
As handling a returned collection usually involves looping through that
collection the simplest way of implementing the client-side code to
deal with both collections and individual controls being returned by
named properties of the <code>elements</code> collection is to
normalise the references to individual controls so that they can be
handled as if they were a collection. Looping through a collection
involves using the <code>length</code> property of the collection to
limit the loop statement and accessing the controls within the
collection by integer index. This is exactly the way in which code
would loop through the elements of an <code>Array</code>. To allow a
script to handle both possibilities with the same code the return of
a reference to an individual control could be detected and then that
reference used to create a one-element <code>Array</code>. Subsequent
code would then treat the <code>Array</code> as if it was a collection and
loop through it, but as there is only one element the loop body would
only be executed once.
</p>
<pre id="faBut_ex3">
var radioCollection, checkedButton;
var frm = document.forms["testForm"];
if(frm){
radioCollection = frm.elements["radioSet"];
if(radioCollection){
<span class="commentJS">/* But the returned reference might not be a collection in this
case. Instead it may be a reference to just one control if
there is only one in this form with the name "radioSet".
If it is a reference to an individual control it is going to
be necessary to normalise it. Because radio button controls
do not have - length - properties and collections do that is
the property that is going to be tested:
*/</span>
if(typeof radioCollection.length != "number"){
<span class="commentJS">/* The length property is not a number so this cannot be a
collection and must be normalised so that the following
loop statement can handle it correctly. Normalisation is
done by making a reference to the control currently
referred to by the - radioCollection - local variable
into the first (and only) element of a new Array object
and then assigning a reference to that array to the -
radioCollection - local variable:
*/</span>
radioCollection = [radioCollection];
}
<span class="commentJS">/* The execution of the body of the - for - loop is limited by
the - length - property of the collection/Array.
*/</span>
for(var c = 0;c < radioCollection.length;c++){
<span class="commentJS">/* The individual radio buttons are accessed as indexed
members of the collection/Array using the loop counter
- c - from the for loop:
*/</span>
if(radioCollection[c].cheked){
checkedButton = radioCollection[c];
break;
}
}
if(checkedButton){
<span class="commentJS">/* do something with the reference to the checked radio
button (if any).
*/</span>
...
}
}
}
</pre>
<p id="faBut_7">
While it is normal for radio button controls to be like-named it is
also possible for all other controls to be included in a form with
multiple controls of the same type and like names. The same
referencing techniques can be used with any type of control (even
mixed types with like-names, though that is almost never done). But
deciding whether a reference needs to be normalised by making it into
the only element of an <code>Array</code> by testing the
<code>length</code> property of that reference to see if it doesn't
exist will not work with <code>SELECT</code> elements as they have
a <code>length</code> property of their own. It also would not help
to be testing some other characteristic of a collection, such as their
<code>item</code> method, as <code>SELECT</code> elements usually have
all of the methods and properties of a collection as they are
implemented as collections of <code>OPTION</code> elements.
</p>
<p id="faBut_8">
Turning the problem around and testing a returned reference to see if
it has the characteristics of a <code>SELECT</code> element (such as
an <code>options</code> property) would be better but some collection
implementations have all of the properties and methods of the first
element within that collection as well as the properties and methods
of a collection (e.g. on IceBrowser 5). That means that it would not be
easy to distinguish a collection of <code>SELECT</code> controls
from an individual <code>SELECT</code> control. However, a more
elaborate test might go:-
</p>
<pre id="faBut_ex4">
<span class="commentJS">/* Normalise a reference that may be an individual from control
(including SELECT elements) or may be a collection of controls
into a form that can be handled in a - for - loop controlled with
its - length - property and accessed by integer index.
*/</span>
if((typeof contrlCollection.length != "number")|| <span class="commentJS">//no length propety:</span>
<span class="commentJS">/* or:- */</span>
((contrlCollection.options)&& <span class="commentJS">//it has an options colleciton and:</span>
((!contrlCollection[0])|| <span class="commentJS">//no object at index 0 - not a collection</span>
<span class="commentJS">/* or:- */</span>
(contrlCollection[0] == contrlCollection.options[0])))){
<span class="commentJS">/* The object at index 0 in contrlCollection is the same object
as is at index 0 in contrlCollection.options so this must be
an individual SELECT element not a collection of them because a
collection of SELECT elements would not have an OPTION element
at index zero.
*/</span>
contrlCollection = [contrlCollection];
}
</pre>
<h2 id="faEff">Efficient use of Form Accessors</h2>
<p id="faEff_1">
Code that interacts with <code>FORM</code> elements and controls
through the <code>document.forms</code> collection and the form's
<code>elements</code> collection usually does not do enough work to
make the efficiency of the code significant. But with large forms with
many controls an inefficiently coded validation function (or some other
interaction, like keeping running totals) can negatively impact on the
user's experience. It can also be argued that considering the
efficiency of implementation is a worthwhile habit even when it would
make no perceivable difference.
</p>
<p id="faEff_2">
A significant aspect of the efficient coding of form interacting code
is the re-resolving of references to various objects. This trivial
example code copies the values of 5 <code>INPUT</code> elements to
local variables:-
</p>
<pre id="faEff_ex1">
var txt1 = document.forms["formName"].elements["field1"].value;
var txt2 = document.forms["formName"].elements["field2"].value;
var txt3 = document.forms["formName"].elements["field3"].value;
var txt4 = document.forms["formName"].elements["field4"].value;
var txt5 = document.forms["formName"].elements["field5"].value;
</pre>
<p id="faEff_3">
The shortcut accessors require the resolution of fewer object
references:-
</p>
<pre id="faEff_ex2">
var txt1 = document["formName"]["field1"].value;
var txt2 = document["formName"]["field2"].value;
var txt3 = document["formName"]["field3"].value;
var txt4 = document["formName"]["field4"].value;
var txt5 = document["formName"]["field5"].value;
</pre>
<p id="faEff_4">
But their use still involves re-resolving the form object each time a
form control is accessed. It would be unnecessary to re-resolve this
reference if a reference to the form was assigned to a local variable:-
</p>
<pre id="faEff_ex3">
<span class="commentJS">/* Assign a reference to the form object to the local variable - frm -
and then make subsequent control references relative to that local
variable:
*/</span>
var frm = document.forms["formName"];
var txt1 = frm.elements["field1"].value;
var txt2 = frm.elements["field2"].value;
var txt3 = frm.elements["field3"].value;
var txt4 = frm.elements["field4"].value;
var txt5 = frm.elements["field5"].value;
</pre>
<p id="faEff_5">
The effect would be much the same as when a reference to the form
object has been passed to a function and control references are
accessed relative to the parameter holding the form reference.
</p>
<p id="faEff_6">
It is still not optimum to be re-resolving the <code>elements</code>
collection, and it is practical to assign a reference to that object
to a local variable instead of a reference to the form object:-
</p>
<pre id="faEff_ex4">
<span class="commentJS">/* Assign a reference to the form's elements collection to the local
variable - frmEls - and then make subsequent control references
relative to that local variable:
*/</span>
var frmEls = document.forms["formName"].elements;
var txt1 = frmEls["field1"].value;
var txt2 = frmEls["field2"].value;
var txt3 = frmEls["field3"].value;
var txt4 = frmEls["field4"].value;
var txt5 = frmEls["field5"].value;
</pre>
<p id="faEff_7">
With the original long form accessor the resolution starts with
resolving the <code>"document"</code> identifier. The
identifier is first looked for among the local variables of the
function (as a named property of the internal
"Variable" object, by ECMA specification),
when it is not found the scope chain is searched, object by object
down the chain, for a property with the corresponding name. When the
scope resolution for <code>"document"</code> gets to the
global object (at the end of the scope chain) it will find a property
called <code>"document"</code>, a reference to the
<code>document</code> object, and the first identifier in the accessor
will have been resolved. The next identifier is
<code>"forms"</code> and that is located as a property of the
<code>document</code>. Then the <code>"formName"</code>
property is identified in the <code>forms</code> collection. Next the
<code>"elements"</code> property of the form is located,
followed by the control name in that object and finally the
<code>"value"</code> property of the control is returned.
</p>
<p id="faEff_8">
When a reference to the <code>elements</code> collection is assigned to
a local variable the first identifier in the property accessor is
identified as that local variable, the control name is identified as a
property of the <code>elements</code> collection referenced and the
<code>"value"</code> property of the control is returned.
</p>
<p id="faEff_9">
Obviously there is a big difference in the amount of work involved in
acquiring the <code>value</code> of the control in each case. That
difference will not be that significant if only a couple of values are
accessed, but even with as few as half a dozen control property
accesses the second approach will obviously be much more efficient,
and with increasing numbers of controls the difference could easily
become apparent to the user.
</p>
</body>
</html>