concatenate in Javascript function? simple field validation funciton not working - needs to concat field name with object

[NotGiven]

I have a field called telephone whose ONBLUR action is to call a javascript
function:
validatePhoneNumber(telephone)

The non-working function is:

function validatePhoneNumber(v)
{
var phone =document.form. + v + .value; //HERE"S WHAT IS
NOT WORKING
var stripped = phone.replace(/[\(\)\.\-\ ]/g, '');
.........//code left out for clarity
document.form. + v + .focus()
}

I want to reuse the function so I need to make it generic. Any ideas?

Many thanks.

[ManoDestra]

The first line in your function is not going to work. Pass in the value of
document.form.v.value directly and work with that.

If you need to make it generic across a site, you could pass in the form
element itself which is what I think you are trying to do here. It would
then become...

var phone = document.form.v.value; (Assuming that your form is called form
and that v is one of the named elements within it).

Personally, I would still go with the first option, pass in the value of the
text field to the function and let the function validate the string.

Peter.

"NotGiven" <no****@nonegiven.net> wrote in message
news:Ge*****************@fe05.atl2.webusenet.com.. .

I have a field called telephone whose ONBLUR action is to call a javascript function:
validatePhoneNumber(telephone)

The non-working function is:

function validatePhoneNumber(v)
{
var phone =document.form. + v + .value; //HERE"S WHAT IS
NOT WORKING
var stripped = phone.replace(/[\(\)\.\-\ ]/g, '');
.........//code left out for clarity
document.form. + v + .focus()
}

I want to reuse the function so I need to make it generic. Any ideas?

Many thanks.

[Evertjan.]

NotGiven wrote on 22 jul 2003 in comp.lang.javascript:

I have a field called telephone whose ONBLUR action is to call a
javascript function:
validatePhoneNumber(telephone)

The non-working function is:

function validatePhoneNumber(v)
{
var phone =document.form. + v + .value; //HERE"S WHAT
IS
NOT WORKING
var stripped = phone.replace(/[\(\)\.\-\ ]/g, '');
.........//code left out for clarity
document.form. + v + .focus()
}

var phone =document.form. + v + .value;

this will never work, because the + only works in a string

var phone ="document.form." + v + ".value";

This should work,
because you need a string as you want to strip it in the next line
var stripped = phone.replace(.....

================

document.form. + v + .focus()

Read: <http://www.litotes.demon.co.uk/js_info/sq_brackets.html>

document.form[v].focus()

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Philip Ronan]

On 03.7.22 7:28 PM, NotGiven wrote:

I have a field called telephone whose ONBLUR action is to call a javascript
function:
validatePhoneNumber(telephone)

Can I just add that it's rather bad manners to use onblur() events to check
form fields.

It's like having someone breathing down your neck the whole time. Put this
in an onsubmit() handler instead.

Phil

--
Philip Ronan
ph***********@virgin.net
(Please remove the "z"s if replying by email)

[Richard Cornford]

"Philip Ronan" <ph***********@virgin.net> wrote in message
news:BB4347AD.16F3E%ph***********@virgin.net...
<snip>

Can I just add that it's rather bad manners to use onblur()
events to check form fields.

It's like having someone breathing down your neck the
whole time. Put this in an onsubmit() handler instead.

I am not sure that validating onBlur itself can be considered bad
manners, it is the possible alert (or similar warning requiring user
interaction) and especially the re-focusing of the form field, trapping
the user into completing that field (if not the entire form) before they
can do anything else, that is objectionable.

Consider, for example, a field for entering your height that is
validated onBlur but all the validation script does is reveal some text
adjacent to the field that reads "Are you really 70 feet tall?" (or
something similar). The user is not prevented from getting on with
whatever they had left the field to do but reviewing the form later they
will be made aware that their entry for that field seems erroneous (and
will probably be rejected by the server if submitted).

Certainly I would prefer to validate a form in its entirety onSubmit as
it is the mechanism provided for that task (at leas I assume that was
the idea behind onSubmit).

Richard.

[Dr John Stockton]

JRS: In article <BB**************************@virgin.net>, seen in
news:comp.lang.javascript, Philip Ronan <ph***********@virgin.net>
posted at Tue, 22 Jul 2003 19:57:33 :-

Can I just add that it's rather bad manners to use onblur() events to check
form fields.

It's like having someone breathing down your neck the whole time. Put this
in an onsubmit() handler instead.

Forms are not necessarily intended to be Submitted.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Lasse Reichstein Nielsen]

Dr John Stockton <sp**@merlyn.demon.co.uk> writes:

Forms are not necessarily intended to be Submitted.

Forms must have an action attribute which represents how to submit
them. I would say that forms *are* intended (by the specification) to
be submitted, even if they somethimes are not by page authors. Those
page authors are the ones giving us, e.g., 'action="javascript:;"'.

If you need input elements but don't need them to be submitted, then
you don't need a form element at all. After all, it has no visible
effect on the page, and if you don't submit, no semantic effect
either, so it might as well not be there. The only reason to include
it is easy access to the input elements (though document.forms[]).

/L 'Just say no to meaningless forms'
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

[Dr John Stockton]

JRS: In article <1x**********@hotpop.com>, seen in
news:comp.lang.javascript, Lasse Reichstein Nielsen <lr*@hotpop.com>
posted at Wed, 23 Jul 2003 20:23:07 :-

Dr John Stockton <sp**@merlyn.demon.co.uk> writes:

Forms are not necessarily intended to be Submitted.
Forms must have an action attribute which represents how to submit
them. I would say that forms *are* intended (by the specification) to
be submitted, even if they somethimes are not by page authors. Those
page authors are the ones giving us, e.g., 'action="javascript:;"'.

The author creates the actual forms!
If you need input elements but don't need them to be submitted, then
you don't need a form element at all. After all, it has no visible
effect on the page, and if you don't submit, no semantic effect
either, so it might as well not be there. The only reason to include
it is easy access to the input elements (though document.forms[]).

There has for me been at least one other reason, although I do not
recall what it was.

It may be, as you suggest, to do with element addressability; or it may
be to do with one or more of the checkers/validators that I have used
insisting that input elements must be in Forms (or at least raising a
complaint that I could only resolve that way). It may be something that
I read here.

However, I can remove the form-enclosure from my js-alarm.htm (apart
from only having one form, it's probably structurally typical of my
pages) and adjust the addressing of controls; it still works in MSIE4,
but I cannot readily check that it works elsewhere.

Forms, as I use them, do split the name-space of the page into separate
scopes, which is certainly useful in pages which have a number of
independent scripted-in/out units. Is there another means of doing
that, known to be widely browser-compatible?

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.