Form Validation (revisited)

Roger Price

Thank you to Yang (Is that your first name?) and Andy for your suggestions.

I am 99% of the way there but now cannot get the "Reset" button to work.

I have included the whole of my code and would appreciate it if someone
could explain where I am going wrong.

TIA

Roger

<?php
$message="";
if (isset($HTTP_POST_VARS['submit']))
{

$re =
"^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.([a-z]){2,3})$" ;

if (eregi($re,$HTTP_POST_VARS['emailAddress'])){
$a = true;
$message = "<font color=\"green\"><b>Hooray - The email address you entered
was valid!</b></font>";
}else{
$a = false;
$message = "<font color=\"red\"><b>It Sucks! - The email address you entered
was NOT valid. Please try again!</b></font>";
}
}else{
$HTTP_POST_VARS['emailAddress']="Enter Here";
$HTTP_POST_VARS['submit']= false;
}
?>
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title></title>
<meta name="description" content="" />
<meta name="keywords" content="" />
<meta name="author" content="Institute of Criminology" />
<meta name="generator" content="AceHTML 5 Pro" />
</head>
<body>

<?php if($message){
print ("$message <br />\n");
}else{
print("<font color=\"red\"><b>You didn't enter anything. Please try
again!</b></font><br />");
}
?>

<form name="myForm" action="email.php" method="post">
<table cellpadding="5" border="1" class="text-align: center">
<tr>
<td>Enter your email address</td>
<td><input type="text" name="emailAddress" value="<?php echo
$HTTP_POST_VARS['emailAddress']?>"></td>
</tr>
<tr>
<td colspan="2" align = "center">
<input type="submit" name="submit" value="SUBMIT">
 
<input type="reset" name="reset" value="RESET">
</td>
</tr>
</table>
</form>
</body>
</html>

Jul 17 '05 #1

Subscribe Post Reply

2390

John Dunlop

Roger Price wrote:

I am 99% of the way there but now cannot get the "Reset" button to work.
First off, this has nothing to do with PHP; rather, reset buttons are
a function of browsers. Whether they "work" or not depends on the
browser. Secondly, reset buttons are generally worse than useless.
And last but not least, please describe your supposed problems in
more detail -- a "doesn't work"-type statement won't help anyone.
I have included the whole of my code
Please make the effort to present your problems using only a minimal
amount of code. I'd hope the reasons for that are obvious.
and would appreciate it if someone could explain where I am going wrong.

Probably in your expectations, for some reason or another. That's my
quasi-educated guess anyway.

A reset button's job is a simple one (emphasis added): "When
activated, a reset button resets all controls to their *initial*
values." (HTML4.01 sec. 17.2.1).

--
Jock

Jul 17 '05 #2

Geoff Berrow

I noticed that Message-ID:
<MP************************@News.Individual.NET> from John Dunlop
contained the following:

A reset button's job is a simple one (emphasis added): "When
activated, a reset button resets all controls to their *initial*
values." (HTML4.01 sec. 17.2.1).

Meaning you can't use it.

Put a submit button in a form of its own, label it reset and have the
action call the original page.

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Jul 17 '05 #3

Roger Price

Jock and Geoff

Thank you for your responses.

I am completely new to PHP and only began studying it last Thursday so
please forgive my naivety!

I am trying to validate an email address - I know that JavaScript is better
for this (I did that last week).

The passing of variables between the form and the PHP script has caused me a
few headaches.

I have attempted to do this using a recursive form call with a conditional
statement that check to see whether the $HTTP_POST_VARS['submit'] is TRUE
or FALSE.

If it is TRUE then is should run through the second imbedded "if" statement
and validate the string from the "emailAddress" input against the reg expr
string.

When displayed for the first time the array $HTTP_POST_VARS['emailAddress']
used to show an unassigned error so that is why I set it to "ENTER HERE" in
the event that "submit" was false.

Upon "submit" the page refreshes and displays the appropriate message with
the field showing the entered string. However if I press "reset" the field
neither returns to "" or "ENTER HERE". Why is this? Is it because I am
intercepting and subsequently processing the "submit" value?
in article MP************************@News.Individual.NET, John Dunlop at
jo*********@johndunlop.info wrote on 7/2/04 2:53 pm:

Roger Price wrote:
I am 99% of the way there but now cannot get the "Reset" button to work.
First off, this has nothing to do with PHP; rather, reset buttons are
a function of browsers. Whether they "work" or not depends on the
browser. Secondly, reset buttons are generally worse than useless.
And last but not least, please describe your supposed problems in
more detail -- a "doesn't work"-type statement won't help anyone.

See above

I have included the whole of my code
Please make the effort to present your problems using only a minimal
amount of code. I'd hope the reasons for that are obvious.

I apologise for breaching the etiquette of this list and will try not to
make the same mistake again. However I posted an earlier part of this
problem and it was evident from the responses that I had not supplied
sufficient code.

While trying to achieve what must seem to you to be a really trivial thing I
have discovered that even minor error can have a disproportionate effect to
different part of the page.
and would appreciate it if someone could explain where I am going wrong.
Probably in your expectations, for some reason or another. That's my
quasi-educated guess anyway.

My expectation is that when I hit the "reset" button that the values revert
to their initial value as you state. This may be where I am going wrong!
The initial value is set as $HTTP_POST_VARS['emailAddress'] which would
initially be null as the array element has not at that stage been defined -
this generated an error!

I suppose I could trap "$HTTP_POST_VARS['reset'] == true" at the top of the
page and set the field back to "" but it would be helpful to understand why
this should be necessary!
A reset button's job is a simple one (emphasis added): "When
activated, a reset button resets all controls to their *initial*
values." (HTML4.01 sec. 17.2.1).
I suppose it all depends on what is meant by *Initial* values!
--
Jock
Geoff

in article 8n********************************@4ax.com, Geoff Berrow at
bl******@ckdog.co.uk wrote on 7/2/04 3:07 pm:
Meaning you can't use it.

Put a submit button in a form of its own, label it reset and have the
action call the original page.

As I have stated above the form has been set up to call itself recursively
upon reset to validate the email address. Calling a submit button "reset" is
not going to return the field to its initial state.

Kindest regards

Roger

Jul 17 '05 #4

John Dunlop

Roger Price wrote:

I am trying to validate an email address - I know that JavaScript is better
for this (I did that last week).
You might like to read the past discussions on that topic.
Upon "submit" the page refreshes and displays the appropriate message with
the field showing the entered string. However if I press "reset" the field
neither returns to "" or "ENTER HERE". Why is this? Is it because I am
intercepting and subsequently processing the "submit" value?
Basically, yes. :-)
My expectation is that when I hit the "reset" button that the values revert
to their initial value as you state. This may be where I am going wrong!
Perhaps your definition of "initial value" wasn't in accordance with
the specification's. "Initial value" is a defined term in the
HTML4.01 spec. For an INPUT, the initial value is always that of its
value attribute, if present. A control's initial value does not
change. A reset button will simply change the "current value" to
equal the initial value. Nothing more; nothing less.
I suppose I could trap "$HTTP_POST_VARS['reset'] == true" at the top of the
page and set the field back to "" but it would be helpful to understand why
this should be necessary!
I suspect there's some confusion here. Most browser don't send reset
buttons' names and values as part of the form data set, i.e. reset
buttons aren't "successful". Activating a reset button doesn't
initiate an HTTP request. A reset button only resets controls'
current values to their initial values. It's entirely client-side.
I suppose it all depends on what is meant by *Initial* values!
You got it! :-)
Calling a submit button "reset" is not going to return the field to its
initial state.

Calling a submit button "reset" would be a usability blunder.

--
Jock

Jul 17 '05 #5

Roger Price

Jock

Your response was very helpful
I in most instances I both understand your comments and agree. The question
of "initial values" however is still causing me a little confusion. In the
example code I posted the "value" of the input "emailAddress" was a PHP
array element $HTTP_POST_VARS['emailAddress'] which when the page is first
served is unassigned. It is necessary therefore to either set it to null or
give it a value before it is displayed to prevent an error.

Filth suggested the following which work really well:

<input type="text" name="emailAddress" value="<?php if (isset
($HTTP_POST_VARS['emailAddress'] )){echo $HTTP_POST_VARS['emailAddress'];}
?>">
in article MP************************@News.Individual.NET, John Dunlop at
jo*********@johndunlop.info wrote on 7/2/04 6:28 pm:

Roger Price wrote:
I am trying to validate an email address - I know that JavaScript is better
for this (I did that last week).

You might like to read the past discussions on that topic.
Upon "submit" the page refreshes and displays the appropriate message with
the field showing the entered string. However if I press "reset" the field
neither returns to "" or "ENTER HERE". Why is this? Is it because I am
intercepting and subsequently processing the "submit" value?

Basically, yes. :-)
My expectation is that when I hit the "reset" button that the values revert
to their initial value as you state. This may be where I am going wrong!

Perhaps your definition of "initial value" wasn't in accordance with
the specification's. "Initial value" is a defined term in the
HTML4.01 spec. For an INPUT, the initial value is always that of its
value attribute, if present. A control's initial value does not
change. A reset button will simply change the "current value" to
equal the initial value. Nothing more; nothing less.
I suppose I could trap "$HTTP_POST_VARS['reset'] == true" at the top of the
page and set the field back to "" but it would be helpful to understand why
this should be necessary!

I suspect there's some confusion here. Most browser don't send reset
buttons' names and values as part of the form data set, i.e. reset
buttons aren't "successful". Activating a reset button doesn't
initiate an HTTP request. A reset button only resets controls'
current values to their initial values. It's entirely client-side.
I suppose it all depends on what is meant by *Initial* values!

You got it! :-)
Calling a submit button "reset" is not going to return the field to its
initial state.

Calling a submit button "reset" would be a usability blunder.

I did resolve the "reset" problem by doing just that. I reset the type from
"reset" to "submit" but left the name as "reset" I then set a contitional at
the top of the script to set the attribute value to "" when a submit
occurred with a name of "reset". It may be a bit unorthadox - but what the
heck it worked just fine.

Kindest regards

Roger

Jul 17 '05 #6

Geoff Berrow

I noticed that Message-ID: <BC***********************@btinternet.com>
from Roger Price contained the following:

Jock

Your response was very helpful
I in most instances I both understand your comments and agree. The question
of "initial values" however is still causing me a little confusion. In the
example code I posted the "value" of the input "emailAddress" was a PHP
array element $HTTP_POST_VARS['emailAddress'] which when the page is first
served is unassigned. It is necessary therefore to either set it to null or
give it a value before it is displayed to prevent an error.
Yes, but the second time the page is served it has a value. As far as
the form is concerned, this value is now the initial value. By the way,
unless you are using a very old version of PHP you might like to use
$_POST[] instead of $HTTP_POST_VARS[]

Roger Price wrote:
I am trying to validate an email address - I know that JavaScript is better
for this (I did that last week).

You might like to read the past discussions on that topic.
In summary - JS is the work of the devil :-)
Also the only true way of validating an email address is to send mail to
it. If you get a reply it's valid. :-)
My expectation is that when I hit the "reset" button that the values revert
to their initial value as you state. This may be where I am going wrong!
They do. They revert to their value the last time the page was served.

Calling a submit button "reset" is not going to return the field to its
initial state.

Calling a submit button "reset" would be a usability blunder.

Got a better idea?

You either do that of have a text or graphic link back to the original
page. The only other way of using a button would require JS

I did resolve the "reset" problem by doing just that. I reset the type from
"reset" to "submit" but left the name as "reset" I then set a contitional at
the top of the script to set the attribute value to "" when a submit
occurred with a name of "reset". It may be a bit unorthadox - but what the
heck it worked just fine.

Yeah, it works for me too.
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Jul 17 '05 #7

John Dunlop

Geoff Berrow wrote:

I noticed that Message-ID: <BC***********************@btinternet.com>
from Roger Price contained the following:
[John Dunlop wrote:]
Calling a submit button "reset" would be a usability blunder.
Got a better idea?

Yes. Remove all reset buttons and don't disguise submit buttons as
reset buttons. I can't see why a single-INPUT form would be an
exception to the general rule that reset buttons are worse than
useless. But Roger's not disguising submit buttons as reset buttons
apparently...
I reset the type from "reset" to "submit" but left the name as "reset"

So the submit button's *value* isn't "reset". It is the value
attribute that normally corresponds to the text of the button.
Setting a submit button's value attribute to "reset" was the
usability blunder I was talking about.

I'm having difficulty following what is going on. The original
article concerned a supposed non-functioning reset button. I've
offered my views on that, and explained why the reset button does
function properly. I'm not aware of another supposed problem.

--
Jock

Jul 17 '05 #8

Geoff Berrow

I noticed that Message-ID:
<MP************************@News.Individual.NET> from John Dunlop
contained the following:

I'm having difficulty following what is going on. The original
article concerned a supposed non-functioning reset button. I've
offered my views on that, and explained why the reset button does
function properly. I'm not aware of another supposed problem.

And I'm not sure what you mean by 'usability blunder'.

He has a form. When submitted the entries are validated. If they fail
he now has it so that the values are redisplayed.

If he wants to allow the user to clear all the input boxes, he cannot
use reset - it won't work.

The only way to do it is to re display the original form.

Having a separate form with the action pointing to the original URL will
do it. He could always label that button 'clear all fields'. Would
that work for you?

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Jul 17 '05 #9

John Dunlop

Geoff Berrow wrote:

And I'm not sure what you mean by 'usability blunder'.
The fact that a submit button (which causes a request to be made) is
disguised as a reset button (which doesn't cause a request to be
made) is a usability blunder IMO. A submit button with a value of
"reset" looks to the average user like a run-of-the-mill reset
button. But it's not. That's apparently not happened here though.
He has a form. When submitted the entries are validated. If they fail
he now has it so that the values are redisplayed.
Right. I'm not sure of the reason behind displaying failed values in
the INPUT though. Why would a user wish to recheck a value she's
discovered is invalid only moments before?
If he wants to allow the user to clear all the input boxes, he cannot
use reset - it won't work.
Ah, that's where our wires crossed I think. The reset button
certainly won't clear the INPUT if a value attribute is specified.
The only way to do it is to re display the original form.
Which'd be overkill IMO.
Having a separate form with the action pointing to the original URL will
do it. He could always label that button 'clear all fields'. Would
that work for you?

Well, that'd avoid my "usability blunder", yes. :-) But I don't see
the point in it.

--
Jock

Jul 17 '05 #10

Geoff Berrow

I noticed that Message-ID:
<MP************************@News.Individual.NET> from John Dunlop
contained the following:

He has a form. When submitted the entries are validated. If they fail
he now has it so that the values are redisplayed.
Right. I'm not sure of the reason behind displaying failed values in
the INPUT though. Why would a user wish to recheck a value she's
discovered is invalid only moments before?

It may be invalid by only one character. It may be a comment field that
has a maximum length of 255 characters exceed by just one. You would
have them retype the lot? There could be lots of reasons. We need not
question the logic of why the OP wants to do this.
If he wants to allow the user to clear all the input boxes, he cannot
use reset - it won't work.

Ah, that's where our wires crossed I think. The reset button
certainly won't clear the INPUT if a value attribute is specified.
The only way to do it is to re display the original form.

Which'd be overkill IMO.

It may be. It may not be. That would depend on the nature of the form.
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Jul 17 '05 #11

Roger Price

Geoff & Jock

I do appreciate the "conversation" that you have been engaging on my behalf
which I have found most informative.

I should say that the page I am working with is part of an assignment for
the "Internet Programming Module" of an on-line MSc in IT run by the
University of Liverpool.

The purpose of the page is to demonstrate my understanding of PHP (very
limited though it is).

The page is called "email.php" and <form action="email.php"> so the submit
button initiates a recursive call.

I check at the top of the page to using "isset" so see if $_POST['submit']
(Geoff thank you for this shorter var name) is true in which case I test
the value of emailAddress against my "regexp" string.

In the event that the "reset" button is pressed (it is of type "submit" but
with the name "reset" - I similarly test for that and reset "emailAddress"
to "".

So you see that there is no "initial page" to return to really.

In the real world I would never consider using PHP for this purpose but
validate (I know that this is not really a validation - just a check to see
that the email address has been entered in the correct format) using JS
(work of the Devil notwithstanding).

I now understand where you are both coming from re "usability blunders" and
I will bear your comments in mind when creating a "real" webpage.

I originally requested help an a specific problem but have had the benefit
of a "seminar" on the subject for which I am very grateful.

Next week we will be using PHP to read and write to an MS Access database (
no don't even ask... I would have chosen MySQL as it seems more appropriate
to what the rest of the web community is doing) so I am sure I will have
even more queries. We also have to use IIS 5 instead of Apache - strange
choice, but I now have a much greater respect for Apache.

Thanks for all your advice

Roger

in article MP************************@News.Individual.NET, John Dunlop at
jo*********@johndunlop.info wrote on 8/2/04 9:36 am:

Geoff Berrow wrote:
And I'm not sure what you mean by 'usability blunder'.

The fact that a submit button (which causes a request to be made) is
disguised as a reset button (which doesn't cause a request to be
made) is a usability blunder IMO. A submit button with a value of
"reset" looks to the average user like a run-of-the-mill reset
button. But it's not. That's apparently not happened here though.
He has a form. When submitted the entries are validated. If they fail
he now has it so that the values are redisplayed.

Right. I'm not sure of the reason behind displaying failed values in
the INPUT though. Why would a user wish to recheck a value she's
discovered is invalid only moments before?
If he wants to allow the user to clear all the input boxes, he cannot
use reset - it won't work.

Ah, that's where our wires crossed I think. The reset button
certainly won't clear the INPUT if a value attribute is specified.
The only way to do it is to re display the original form.

Which'd be overkill IMO.
Having a separate form with the action pointing to the original URL will
do it. He could always label that button 'clear all fields'. Would
that work for you?

Well, that'd avoid my "usability blunder", yes. :-) But I don't see
the point in it.

Jul 17 '05 #12

Geoff Berrow

I noticed that Message-ID: <BC***********************@btinternet.com>
from Roger Price contained the following:

I should say that the page I am working with is part of an assignment for
the "Internet Programming Module" of an on-line MSc in IT run by the
University of Liverpool.
Fascinating. I did the taught modules of an MSc in ICT at Keele
University in 2000
The purpose of the page is to demonstrate my understanding of PHP (very
limited though it is).

The page is called "email.php" and <form action="email.php"> so the submit
button initiates a recursive call.
I check at the top of the page to using "isset" so see if $_POST['submit']
(Geoff thank you for this shorter var name) is true in which case I test
the value of emailAddress against my "regexp" string.

In the event that the "reset" button is pressed (it is of type "submit" but
with the name "reset" - I similarly test for that and reset "emailAddress"
to "".
Seems a bit long winded. See below.
I'm not sure quite why the isset is required. It will work without
<html>
<head>
<title>Mail checker</title>
</head>
<body>
<table width="60%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="70%">
<form name="form1" method="post" action="email.php">
Enter email
<input type="text" name="email" size="20" value="<?php print
$_POST['email']; ?>">
<input type="submit" name="submit" value="Send it">
</form></td>
<td width="30%">
<form name="form2" method="post" action="email.php">
<input type="submit" name="reset" value="Reset">
</form></td>
</tr>
</table>
<?php
if($_POST['submit']){
if (!strpos($_POST['email'],"@"))//reg exp here instead of my
simple test
{
print "try again, email addresses must contain \"@\"";
}
else{
print "That's a fine email address!";
}
}
?>
</body>
</html>

So you see that there is no "initial page" to return to really.

In the real world I would never consider using PHP for this purpose but
validate (I know that this is not really a validation - just a check to see
that the email address has been entered in the correct format) using JS
(work of the Devil notwithstanding).
It's more reliable than JS but both methods are meaningless if the
address is simply made up.

Next week we will be using PHP to read and write to an MS Access database (
no don't even ask... I would have chosen MySQL as it seems more appropriate
to what the rest of the web community is doing) so I am sure I will have
even more queries. We also have to use IIS 5 instead of Apache - strange
choice, but I now have a much greater respect for Apache.

Hmm that does seem odd, since the biggest part of Access it it's
interface, which you will not use. Ho hum...
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Jul 17 '05 #13

Form Validation (revisited)

Similar topics