Text Validation?

[al]

Greetings,

I trying to validate user input to only alphabet [a-zA-Z] or '\w', but
it is not working for me.

Code:

if (document.all("txtName").value == [a-zA-Z])

//valiation is OK..Rest of code

else{

alert("Please enter only alphabet!");
document.all("txtName").value == "";
}

MTIA,
Grawsha

 

[kaeli]

Greetings,

I trying to validate user input to only alphabet [a-zA-Z] or '\w', but
it is not working for me.

Code:

if (document.all("txtName").value == [a-zA-Z])

IE only?
Not so good.

function isAlpha(str)
{
var re = /^[A-Za-z ]+$/;
return re.test(str);
}

if (! isAlpha(document.forms["formname"].elements["elementname"].value))
{
alert("wrong");
return false;
}
--

 

[Lasse Reichstein Nielsen]

I trying to validate user input to only alphabet [a-zA-Z] or '\w', but
it is not working for me.

Code:

if (document.all("txtName").value == [a-zA-Z])

document.all is a proprietary Microsoft invention and
doesn't work in all browsers. You could use
document.forms['formName'].elements["txtName").value
instead.

The "expression" [a-zA-Z] is parsed as :
A list containing a subtraction of the variables "zA" and "Z"
from the variable "a".
Probably not what you meant .

To test for an all-alphanumeric string, use a regular expression:

if( /^\w*$/.test(someString) ) ...
or
if ( someString.match(/^\w*$/) ) ...

Now put the reference to the form control value into the match

alert("Please enter only alphabet!");
document.all("txtName").value == "";

I recommend against clearing the field. If the user had a long input
with a single error, he will have to write it from scratch instead
of just fixing the error. Highly annoying. Instead, I would put focus
on the element, and perhaps even select the contents:

var elem = document.forms['formName'].elements['txtName'];
elem.focus();
elem.select();

/L

 

[Cycloneous Echevarria]

You must use reg exps, which is what you are doing but your codes needs
some tidying up. Also, you are using IE specific javascript which will
render your code non-DOM compliant, so I fixed up the references.

// created 2 reg exp object instances

var exprOne = /[a-zA-z]/;
var expTwo = /[0-9]/;

var data = document.FormName.txtName.value; // don't use document.all,

// test for text only

if(exprOne.test(data) && !expTwo.test(data)){

// valiation is OK..Rest of code

} else {

document.FORMNAME.txtName.value = "";

}

Cycloneous

 

[Randy Webb]

You must use reg exps, which is what you are doing but your codes needs
some tidying up. Also, you are using IE specific javascript which will
render your code non-DOM compliant, so I fixed up the references.

No, you do not "must" use reg exps. I can, very simply, write an over
bloated function that will check for a-z and A-Z and never use a regex.
Yes, its a lot more efficient but is *not* required, which is what your
"must" implied.

As for "non-DOM compliant", thats balderdash. document.all is *very*
"DOM compliant" with the DOM in IE, its just not compliant with other
DOM's in other browsers/UA's.

 

[Lasse Reichstein Nielsen]

As for "non-DOM compliant", thats balderdash. document.all is *very*
"DOM compliant" with the DOM in IE, its just not compliant with other
DOM's in other browsers/UA's.

That makes any feature (or bug) "DOM compliant" on the version of the
browser it runs on
But yes, for precission, it is not W3C DOM compliant, which is the only
non-browser-specific DOM.

/L

 

[Randy Webb]

That makes any feature (or bug) "DOM compliant" on the version of the
browser it runs on
Precisely.

But yes, for precission, it is not W3C DOM compliant, which is the only
non-browser-specific DOM.

I am still not convinced that writing "W3C DOM compliant" code is all
that great. Yes, it goes by the spec but if its not implemented in the
Browser and/or UA, then its still worthless

Code that works is still better than code that is "compliant". Yanno?

 

[Lasse Reichstein Nielsen]

I am still not convinced that writing "W3C DOM compliant" code is all
that great. Yes, it goes by the spec but if its not implemented in the
Browser and/or UA, then its still worthless

I'll agree if you mean the browser is worthless

Writing *only* W3C DOM compliant code will not work, since there are
still worthless browsers in wide use. Writing W3C DOM compliant code
as the primary branch, and then having fallbacks for non-compliant
browsers, is the safest way to script. It has the advantage of working
with any new browser that appears, since they are bound to be W3C DOM
compliant (or at least close). No other way of scripting will give you
forwards compatability (effectively demonstrated by all the "it works
in IE but not in Netscape, what should I do" posts).

Code that works is still better than code that is "compliant". Yanno?

And code that works both today and tomorrow is better than code that
only works today. At least if I have to maintain it

/L

 

[Randy Webb]

I'll agree if you mean the browser is worthless

That depends. I find it a lot easier to dynamically load js files in IE
than any other browser. Simply because it supports the proprietary
method of changing the .src of a script tag with an id. The advantage is
that you aren't continually adding script elements to the document, as
you do when using createElement, although createElement is "W3C DOM".

Which way I do something, whether proprietary then W3C, or W3C and then
proprietary, depends directly on which one is more efficient. Sometimes,
its more efficient to use the proprietary features.

My, or anyone elses, opinion of IE aside, its simply a lot simpler to
script for than other browsers, if for no other reason than its
tolerance of errors.

Writing *only* W3C DOM compliant code will not work, since there are
still worthless browsers in wide use. Writing W3C DOM compliant code
as the primary branch, and then having fallbacks for non-compliant
browsers, is the safest way to script. It has the advantage of working
with any new browser that appears, since they are bound to be W3C DOM
compliant (or at least close). No other way of scripting will give you
forwards compatability (effectively demonstrated by all the "it works
in IE but not in Netscape, what should I do" posts).

Being "W3C DOM Compliant" does not make a browser "non-worthless" nor
does being non-Compliant make it worthless.

And code that works both today and tomorrow is better than code that
only works today. At least if I have to maintain it

That still doesn't always make "compliant code" the most efficient nor
the easiest to maintain. It can be written either way, whether it goes
like this:

if (document.all){

}else
{if (document.getElementById){

}
}
or this:

if (document.getElementById){

}else
{if (document.all){

}
}

It will *still* work tomorrow, the difference is in efficiency. So I
guess I should have said "Efficient proprietary code is better than
less-efficient W3C Dom Compliant code" and I prefer efficiency to
"compliance".

 

[Dr John Stockton]

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

My, or anyone elses, opinion of IE aside, its simply a lot simpler to
script for than other browsers, if for no other reason than its
tolerance of errors.

If one is able to choose the browser that the readers of one's stuff
will use - which is possible if one is an IT manager with an intranet,
but is unreasonable when authoring for the Web - then it is expedient to
choose a tolerant browser and enable shoddy work. There's no guarantee,
of course, that the next issue of the same browser will give the same
result with incorrect but tolerated code.

But a Web author, writing for a diversity of browsers, is best helped by
using a strict browser in design and authoring; ideally, one would never
need to use HTML validators (or accessibility testers), since those
functions would be incorporated in the development browser itself.

A Web author - the default assumption here - should not write "for a
specific browser".