- File: genericValidation.js (excerpt).
- We’re going to step through all the form elements and check only the ones our validation set has regular expressions for:.
- if (frm.elements[i].name &&.
- validationSet[frm.elements[i].name]).
- it’s the same as the code we used in checkValid.
- validationSet[failedE.name]['error'];.
- If you look at this code closely, you’ll see that we’re not only grabbing the message associated with the field: we’re also adding the content of the field’s label to the error message.
- That will tie what the user sees on the screen with what they see in the error message..
- Sadly, there is no document.getLabelElementsByForValue , so we are forced to iterate through each label element on the page and compare its htmlFor 6 property with the id of the given form element.
- or similar, to the end of the error message for that field.
- The join method of the errText array is used to combine the collected error messages into a single string, separated by line breaks ( \n ) for readability..
- Of course, if any errors were caught, we don’t want the form to submit.
- In addition to cancelling the event, this code sets a submitAllowed property on the form to indicate whether the submission should go ahead.
- If we didn't do this, this handler would prevent the form from submitting when the previous form submission attempt failed due to a validation error..
- Note also the use of this to reference the form element in this event handler..
- Don’t be fooled into doing the same in a modern DOM event listener— this usually just points to the window object in an event listener.
- "http://www.w3.org/TR/html4/strict.dtd">.
- <title>Client-side form validation</title>.
- src="exampleValidation.js".
- ></script>.
- href="exampleValidation.css">.
- <h1>Client-side form validation</h1>.
- <p><label for="email">Email address</label>.
- id="email">.
- class="errormessage"></span></p>.
- <p><label for="phone">Phone number</label>.
- id="phone"></p>.
- <p><label for="country">Country code</label>.
- id="country".
- maxlength gt;</p>.
- <p><input type="submit".
- value="submit"></p>.
- The first sets up the validationSet object for the form(s) on this page:.
- File: exampleValidation.js.
- 'It should be of the form
[email protected].'.
- So that you have it all in one place, here’s the complete listing of this script:.
- File: genericValidation.js.
- if (!formField.form.validateSubmit.
- formField.form.onsubmit = fV.checkSubmit.
- Safari formField.form.validateSubmit = true;.
- frm.elements[i].name);.
- target.name);.
- alert(validationSet[failedE.name]['error']);.
- if (!field.value).
- var re = validationSet[field.name]['regexp'];.
- This page also uses a style sheet to provide styling for the form.
- Figure 6.1 shows how the page displays if the first two fields receive bad data..
- Figure 6.2 shows the same form after the user hits the submit button..
- As Figure 6.2 shows, when the form is submitted, the error messages are collated together into one dialog.
- It’s easy for the reader to work out the fields to which the error messages apply..
- The validationSet object would need to have an extra property to hold the IDs of the elements alongside which the in-page messages should be added.
- It’s a fairly simple enhancement: experiment with it yourself..
- Let’s briefly look at the other half of the validation story: server-side validation..
- Client-side validation is very useful, but at the risk of belaboring the point, it’s extremely important that you don’t rely on it.
- Your client-side code provides a better interface for your users, but the server-side code is the bit that must be right.
- The server-side page that actually generates the form should integrate neatly with the client-side code.
- We can store a list of the regular expressions appropriate to each field in the server code.
- The server code can write these expressions into the JavaScript section of the generated page, and use the expressions to check the fields when the page is submitted.
- As such, the required regular expressions can be specified once and used on both the server side and the client side..
- a field does not match its regular expres- sion), the server-side page generator writes the form out again, placing the error text in the appropriate span element..
- The key benefit here is that changing the field validation is as simple as changing the regular expression list in the server code: this automatically makes the client- side code work, without any extra effort.
- In that case, either the client-side code will allow some values that the server code will not (which is a usability problem), or the client-side code will correctly block some values that the server does not.
- First, here’s the HTML starting point:.
- We could simply put all the code that generates the page in this one file, but splitting the form generation code into the included serverValidation.php file makes the code simpler to read, and concentrates all the form technology in one place.
- generate the form content with in-page error messages } else.
- Generate the form content normally.
- The $form_variables variable will contain our regular expressions and error messages.
- The last set of if s perform the form submission logic, generating one of three separate pages depending on what’s happening.
- Here’s the full listing, a piece at a time:.
- <script type="text/javascript">.
- method="post">.
- <p>.
- <label for="email">Email address</label>.
- id="email".
- value="{$data['email']}">.
- </p>.
- <label for="phone">Phone number</label>.
- id="phone".
- value="{$data['phone']}">.
- <label for="country">Country code</label>.
- id="country".
- value="{$data['country']}">.
- The rest of the function specifies the HTML’s form content, inserting any retained form data and any required error messages.
- tags, which include a reference to the client-side validation library ( genericValidation.js ) we built earlier in this chapter..
- Finally, here’s the section that generates the page:.
- Now generate the form or POST response page if ($_POST).
- Redisplay the form.
- Inside the first if , the code loops through the form’s submitted data and tests each item using the PHP copies of the regular expressions for the form.
- Otherwise, the form is processed without complaint..
- Enter some bad data, and the client-side JavaScript will catch the errors, preventing the form from being submitted.
- Next, turn JavaScript off in your browser and reload the form.
- One of the downsides of this approach is the set of widgets—buttons, drop-down lists, text boxes, and radio buttons—that make up HTML forms.
- The problem of HTML form widgets not being quite as fancy as those in normal client-side applications is well known, and numerous widget enhancements have already been developed with DHTML..
- A popular enhancement to text boxes in client-side applications is an entry history:.
- typing into the text box will autocomplete those values.
- Figure 6.5 shows this calendar at work..
- The instructions are, therefore, available to non-JavaScript-capable browsers (as they’re located in the label element), but are placed in the text box itself in DOM browsers, as can be seen in Figure 6.6 and Figure 6.7 below..
- Text box labels with DHTML..
- Text box labels without DHTML..
- Equally, a key feature of legacy scripting techniques is the use of the document.all and document.layers properties