I've added a couple of tests to the commonCheck routine.
I'd be grateful if you could give it a quick look and see
if there's anything else I've missed.
From the commonCheck function:-
|if (document.getElementById == undefined)
| return true; // older browser - leave validation to the server
|var elem = document.getElementById(ifld);
|if (!elem.firstChild && !elem.innerHTML)
| return true; // older browser
The first thing that struck me about this was the comparison with -
undefined - in the first test. undefined was introduced with JavaScript
1.3 but didn't make it into JScript until 5.0 (or maybe 5.5?). Which
makes me think that it probably should not be used in a test that is
intended to allow the script to degrade cleanly on older browsers, IE 4,
for example, will produce an (unhelpful) "undefined is undefined" error.
There are techniques that render undefined safe to use in any
environment, such as:-
window.undefined = window.undefined;
- or -
this.undefined = this.undefined; //executed in a global context.
- but they are probably not necessary as a type-converting test:-
if (!document.getElementById){
// getElementById cannot be used.
}
- should be sufficient, and avoid any language version issues.
The value returned from the call to getElementById and assigned to the
local variable - elem - is not checked. Because you know that you have
put an element into the document with a corresponding ID attribute it
seems reasonable to assume that the function call will return a
reference to that element. But it doesn't cost much to double check, and
if the element was not returned you can be guaranteed that the message
writing function will not work. So:-
if (!elem || (!elem.firstChild && !elem.innerHTML))
It would also be possible to combine the two tests into one - if -
statement:-
var elem;
if(!document.getElementById ||
((!(elem = document.getElementById(ifld)) ||
(!elem.firstChild && !elem.innerHTML)))){
return true; // leave validation to the server
}
It is worth baring in mind that this is a test to avoid executing the
script on browsers that cannot support it, some of these will be "older
browsers" but others will the latest versions of non-dynamic browsers
such as some of those found on small PDAs and cell phones.
As it stands this test will be executed upon every change made to a
field in the form. If the browser fails on the first attempt it will
also fail on all subsequent attempts so it might be worth ensuring that
the test is not needlessly repeated once it has failed. I notice that
the - commonCheck - function is expecting to have a reference to the
invoking form element passed to it as its - vfld - parameter. As a
result, having identified an unsupporting browser, the onchange handler
for the corresponding form field could be permanently disabled by
assigning null to its onchnge property:-
vfld.onchange = null; //future change events will
//not be calling JavaScript.
(knocking onsubmit out from the FORM element is also an option).
Other alternatives might include replacing the - commonCheck - function
with another that did nothing but return true, short-circuiting all
subsequent testing.
Looking at the ONCHANGE attributes in your HTML to verify the origin of
the - vfld - parameter I notice that you are using an unreliable
accessor to pass the reference to the form element:-
| <INPUT TYPE=text NAME="telnr"
| ID="telnr" SIZE="35" MAXLENGTH="25"
| ONCHANGE="validateTelnr(telnr, 'inf_telnr', true);">
The identifier - telnr - is being used to pass the reference to INPUT
element to the - validateTelnr - function. Many browsers provide the
functions generated with event handling attribute strings with custom
scope handling mechanisms that will resolve the identifier - telnr - as
a named property of the form, others provide named form elements as
named properties of the global object so scope resolution will find the
right object under the name - telnr - at the end of the scope chain.
Unfortunately, these behaviours are non-standardised and inconsistently
implemented, there are also browsers that will do neither and - telnr -
will remain undefined.
However, the JavaScript language requires that when a function is
invoked as a method of an object the - this - keyword is always a
reference to that object, and event handling functions are always
invoked as methods of the element with which they are associated. That
means that event handling attribute code can always refer to the element
to which it is attached with the - this - keyword and so pass on
references to that element, while side-stepping the inconsistencies in
scope resolution from (internally generated) event handling functions:-
ONCHANGE="validateTelnr( this, 'inf_telnr', true);">
Nothing else stands out as potentially problematic, though I don't think
that you should be commenting on people managing to survive for more
than 100 years, I would put the cut-off point at around 125. Anyone who
has made it past 100 is unlikely to appreciate the comment "Getting on a
bit, aren't you?".
Richard.
