Pattern based test isn't working, but it works elsewhere

[Ted Byers]

The entire contents of the web page in question are dynamic, but there
is only one form, and it isn't working.

The form displays OK, including a drop down select control which has
about 70 items.

The form actually has only three controls: the dropdown selection
control, a test box, and the submit button.

The entire page is computed server side by a cgi script written in
perl, but the HTML is properly generated.

Part of the HTML that is generated is shown below.

Here is the beginning of the form:
<form name='xtra_filters' id='xtra_filters' action='add_filters.cgi'
method='post' onsubmit="return verify_data(this)">
<select name='fcode' id='fcode'><option value='64'>

a large number of options are skipped here, and there is the end of
the form and the Javascript code:
<input type='text' name='fvalue' id='fvalue' size='100'
maxlength='256' />
<input type='submit' />
</form>
<script language="Javascript" type="text/javascript">
function test_nws(x) {
var pattern = /w+/;
return !pattern.test(x);
}
function verify_data(f) {
var f1 = test_nws(f.fvalue.value);
var msg = "";
if (f1) {
msg += "You must provide a value.";
}
if (msg) {
alert(msg);
return false;
}
return true;
}
</script>

</body>
</html>

Now, the function test_nws, when used in a static web page with a much
more complex form, returns true if there are no alphanumeric
characters in the form, and false otherwise. In the static page, this
works as expected, so instead of submitting the form data when there
is required data missing, a dialog pops up to tell the user what data
is missing.

On this dynamic page, this dialog pops up regardless of whether or not
data is provided, and no data is submitted to the server. This code,
like I said, was first tested in a static web page's form, and worked
there (I used the third edition of "JavaScript: The definitive guide"
by David Flanagan as a guide, and a regular expression I'd commonly
used in some of my Perl scripts). So why is test_nws returning true
despite my typing 'pending', without quotes, into the field with the
ID = 'fvalue'?

On a related matter, is there a way to see what parameters are
actually sent to the server (one that does not present a security
risk)? I'd like to be able to compare what the browser thinks it is
sending (and what Javascript thinks it is processing) with what the
server actually receives.

Thanks

Ted

 

[Thomas 'PointedEars' Lahn]

<form name='xtra_filters' id='xtra_filters' action='add_filters.cgi'

Your form likely does not need a name. It may not even need an ID.

method='post' onsubmit="return verify_data(this)">
<select name='fcode' id='fcode'><option value='64'>

a large number of options are skipped here, and there is the end of
the form and the Javascript code:
<input type='text' name='fvalue' id='fvalue' size='100'
maxlength='256' />

Eschew XHTML. HTML 4.01 suffices for most purposes and is much more
compatible (IE does not even support XHTML to date).

<input type='submit' />

You want to use an (i18n'd) `value' attribute here.

</form>
<script language="Javascript" type="text/javascript">

The `language' attribute is deprecated since almost 10 years now, and it was
never really necessary.

function test_nws(x) {
var pattern = /w+/;
return !pattern.test(x);
}
[...] (I used the third edition of "JavaScript: The definitive guide"
by David Flanagan as a guide,

That's a really bad idea.

and a regular expression I'd commonly used in some of my Perl scripts)

It's getting worse. JFYI: ECMAScript does not support PCRE.

So why is test_nws returning true despite my typing 'pending',
without quotes, into the field with the ID = 'fvalue'?

You forgot a `\' before the `w'. That expression isn't going to work as
intended in Perl either, it will match one or more `w', which "pending" does
not contain.

On a related matter, is there a way to see what parameters are
actually sent to the server (one that does not present a security
risk)? I'd like to be able to compare what the browser thinks it is
sending (and what Javascript thinks it is processing) with what the
server actually receives.

You can use the "Live HTTP Headers" extension in Gecko-based browsers.


PointedEars

 

[Thomas 'PointedEars' Lahn]

It's getting worse. JFYI: ECMAScript does not support PCRE.

Isn't that contradicting ECMA-262?
No.

[quote page 141]
The form and functionality of regular expressions is modelled after the
regular expression facility in the Perl 5 programming language.

[/QUOTE]

"Is modelled after" does not equal "implements" or even "is based upon".
You will find that out if you read the ECMAScript Specification more closely
and compare its RegExp definitions with that of the PCRE specification.


PointedEars