JS Enabled But No RegExp Support?

[Matt Kruse]

Are there any current browsers that have Javascript support, but not RegExp
support?
For example, cell phone browsers, blackberrys, or other "minimal" browsers?
I know that someone using Netscape 3 would fall into this category, for
example, but that's not a realistic situation anymore.

And if such a condition exists, then how do you guys handle validation using
regular expressions, if the browser lacks them?

For example:

function isDigits(val) {
if (window.RegExp) {
return !(val.search(/^\d+$/)==-1);
}
else {
// No regexp support
// ????
}
}

If no RegExp support, then should brute-force methods be used using indexOf,
substr, etc? (not for this specific method, but the general case).
And if that's the case, then why even include the duplicate regexp code to
begin with?

Or if the brute-force method should not be used, then what should be
returned? undefined? null? Then the method becomes less useful, because it
doesn't return true or false consistently like a user might expect. Having
an "isX" method that returns "I don't know" makes it very difficult to
validate forms, etc :)

Just curious what others have concluded, and if the "js enabled but no
RegExp support" condition is even realistic?

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Kevin Darling]

Matt Kruse wrote:

Are there any current browsers that have Javascript support, but not RegExp
support?
For work, we have to support Windows CE 3.0 handheld devices (aka HPC
Professional) that use pretty much IE 4.01, and no regular expressions.
The current CE has a far better browser, though.
And if such a condition exists, then how do you guys handle validation using
regular expressions, if the browser lacks them?

It was a pain at first, but now we have a library of validation
routines. As you leave each field, a standard function automatically
validates the field (or group of fields) against attributes of that
field (such as <input required="" timeField=""> ) or by calling a
custom validation routine (<input customValidatio n='custom(this) '> ).

But that's our burden to bear :-)
Kev

[VK]

function isDigits(val) {
if (window.RegExp) {
return !(val.search(/^\d+$/)==-1);
}
else {
/* NOP */
// or
// alert("Where did you get this junk?");
}
}

The first is nicer, the second is more informative and stimulating to
the end user.

Also Konqueror 1.x will very probably crash right on the
(window.RegExp) check.

It seems to crash randomly at the moment you're trying to use
JavaScript for DOM access. This alone kills the imperative "Support for
each and every one". An averagely bad browser producer will always win
against of a good developer however good the developer would be.

About PDA and web-phones: it is too early yet to worry about. IMHO you
should wait until it's clear who's dominating. Did you ever try to use
say an Nokia accessory for Siemens? Or a Siemens charger for Ericsson?
That exact situation with the software: a fight to death, only later
the survivers will start to cooperate to keep away newcomers. I passed
this with WML for the first wave of GPRS phones. The first year one
would have to make a separate solution for each and every phone. And
now WML is pretty set (but getting out of use though).

From my personal experience (I'm having Toshiba with Pocket PC 2002,

now Pocket PC 2005) you always can count on Netscape 2.0 JavaScript
(without document.write( ) though) and XML/XSLT The latter is a mistery
to me but any prodicer seems to feel obligated to have it. HTMLDocument
DOM will be most probably in absence or cut to a misery state (another
mistery).
All this based on my personal experience and observations therefore it
can be factually, logically and grammatically incorrect.

[Evertjan.]

Matt Kruse wrote on 01 dec 2005 in comp.lang.javas cript:

return !(val.search(/^\d+$/)==-1);

Your real Q seems to be answered,
but the above line is too complex for me, Mat.

would this do:

return (val.search(/^\d+$/)==0);

or even better[?]

return !/\D/.test(val);


--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Are there any current browsers that have Javascript support, but not
RegExp support?
Probably not.
And if such a condition exists, then how do you guys handle validation
using regular expressions, if the browser lacks them?

For example:

function isDigits(val) {
if (window.RegExp) {
Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents. The proper feature test
(JavaScript 1.1, JScript 1.0, ECMAScript Ed. 1) is

if (typeof RegExp == "function")
return !(val.search(/^\d+$/)==-1);
Try

return (new RegExp("^\\d+$" )).test(val);

I would recommend a RegExp object literal instead of calling
the constructor, but you were asking for a general method where
the latter cannot be assumed.
}
else {
// No regexp support
// ????
}
}

If no RegExp support, then should brute-force methods be used using
indexOf, substr, etc? (not for this specific method, but the general
case).
Yes. For this specific method, I would use a `for' loop,
String.prototyp e.charAt() and String.prototyp e.charCode().
And if that's the case, then why even include the duplicate regexp
code to begin with?
Because it is more efficient than the brute-force method, where supported.
[...]
Just curious what others have concluded, and if the "js enabled but no
RegExp support" condition is even realistic?

According to my findings, RegExp literals are supported since JavaScript 1.3
(NN 4.06, 1998), JScript 3.0 (IE 4.0) and ECMAScript Edition 3 (December
1999); the RegExp object and constructor is apparently supported since
JavaScript 1.2 (NN 4.0, June 1997), JScript 3.0 (IE 4.0) and ECMAScript
Edition 3.
PointedEars

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

Matt Kruse wrote:

return !(val.search(/^\d+$/)==-1);

Try

return (new RegExp("^\\d+$" )).test(val);

Or probably faster

return !(new RegExp("[^\\d]")).test(va l);
PointedEars

[Matt Kruse]

Thomas 'PointedEars' Lahn wrote:

Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents.

Name a single exception - then I might agree with you.

And if that's the case, then why even include the duplicate regexp
code to begin with?

Because it is more efficient than the brute-force method, where
supported.

Perhaps, but the need to write, debug, and test two code paths when a single
code path would work for all cases may over-ride the (very) small
performance increase one might see by using regular expressions.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents.

Name a single exception - then I might agree with you.

I do not require your agreement for my statement to be correct.

And if that's the case, then why even include the duplicate regexp
code to begin with?

Because it is more efficient than the brute-force method, where
supported.

Perhaps, but the need to write, debug, and test two code paths when a
single code path would work for all cases may over-ride the (very) small
performance increase one might see by using regular expressions.

I did not say you have to.
PointedEars

[Patient Guy]

Thomas 'PointedEars' Lahn <Po*********@we b.de> wrote in
news:17******** ********@Pointe dEars.de:

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents.

Name a single exception - then I might agree with you.

I do not require your agreement for my statement to be correct.

From http://www.webreference.com/js/column80/6.html:

"The global object is the browser window object,
the one you query the location of by window.location ()."

For all practical purposes, the global object is the window object.

When you name an actual implementation of the global object that is not
browser window-based, then your statement will be more than just what it is
now: pedantic.

[Thomas 'PointedEars' Lahn]

Patient Guy wrote:

Thomas 'PointedEars' Lahn <Po*********@we b.de> wrote [...]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:
Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents.
Name a single exception - then I might agree with you. I do not require your agreement for my statement to be correct.

From http://www.webreference.com/js/column80/6.html:

"The global object is the browser window object,
the one you query the location of by window.location ()."

Quoting some thing that calls itself "reference" does not prove anything.
For all practical purposes, the global object is the window object.
That depends on what you call "practical purpose". _Client-side_
scripting in a _(X)HTML_ DOM environment: _probably_ yes, due to history.
Client-side scripting in another environment: not necessarily, and there
are examples of the opposite. Server-side scripting: _no_.
When you name an actual implementation of the global object that is not
browser window-based, then your statement will be more than just what it
is
now: pedantic.

No, examples where it does not apply have already been posted here before.
One just needs to be willing to read and learn. And to know the basics:
There are no windows where they cannot be displayed, hence it would be not
reasonable to have a `window' reference there, let alone let it refer the
Global Object.
PointedEars