Theory
Filled in, but nonsense
FestConnect now rejects blank fields. But the sheet still fills with junk: email hello, mobile 12, name asdf123. Every field is filled, so basic validation passed, yet none is usable.
The next layer is format validation: not just 'is there something?' but 'is it the right shape?'. An email must look like an email; a mobile must be ten digits; a name should be letters. The sharpest tool for shape-checking is the regular expression.
Theory
A stencil the answer must fit
A regular expression is a stencil cut in the shape of valid input. You lay the user's text over it: if it fits the cut-out exactly, it passes; if any part poking out does not match, it fails. \d{9} is a stencil slot for exactly nine digits; ^ and $ are the edges of the stencil, forcing the whole answer to fit, not just a corner of it.
At a glance
Common validation patterns
| Field | Rule | Pattern |
|---|---|---|
| Mobile (IN) | 10 digits, starts 6-9 | /^[6-9]\d{9}$/ |
| Name | letters and spaces only | /^[A-Za-z ]+$/ |
| Digits only | one or more digits | /^\d+$/ |
| Email (simple) | text @ text . text | /^\S+@\S+\.\S+$/ |
Practical
FestConnect format checks
// pattern.test(value) returns true/false
function checkFormats(name, email, mobile) {
let namePat = /^[A-Za-z ]+$/; // letters + spaces
let emailPat = /^\S+@\S+\.\S+$/; // x@y.z
let mobilePat = /^[6-9]\d{9}$/; // 10 digits, 6-9 first
if (!namePat.test(name)) { alert("Name: letters only"); return false; }
if (!emailPat.test(email)) { alert("Email looks invalid"); return false; }
if (!mobilePat.test(mobile)){ alert("Mobile: 10 digits"); return false; }
return true;
}
console.log(checkFormats("Aditi Shah", "aditi@x.com", "9876543210")); // true
console.log(checkFormats("asdf123", "hello", "12")); // false
// a number field: reject non-numeric
let age = "20";
console.log(!isNaN(Number(age))); // trueThis example runs in Gri-Learn on the web, where you can edit it and see the output.
Think first
Why the ^ and $?
The mobile pattern is /^[6-9]\d{9}$/. What would go wrong if you dropped the ^ and $, using just /[6-9]\d{9}/ on the input call me 9876543210 today?
Show the answer
Without anchors, the pattern matches if those ten digits appear anywhere in the string, so call me 9876543210 today would pass as a valid mobile, even with all the extra text. ^ pins the match to the start and $ to the end, forcing the entire value to be exactly a 10-digit number and nothing else. Anchors turn 'contains a match' into 'is exactly this shape', which is what validation needs.
Quiz
Which input correctly passes the Indian mobile pattern /^[6-9]\d{9}$/ ?
- 9876543210
- 1234567890 (starts with 1)
- 98765 43210 (has a space)
- 98765432 (only 8 digits)
Show the answer
9876543210
9876543210 is exactly 10 digits and starts with 9, matching [6-9] then nine more digits, anchored start to end (A). 1234567890 starts with 1, which fails [6-9] (B). The spaced version breaks the continuous 10-digit run and the $ anchor (C). Eight digits is too short for \d{9} after the first (D). The pattern enforces all three rules at once: leading digit, exact count, nothing extra.
Watch out
Format validation traps
1. Missing anchors: without ^ and $, a pattern matches a substring, so junk around a valid chunk sneaks through.
2. Over-restricting names: real names have spaces (and sometimes dots or hyphens). A letters-only pattern that forbids spaces rejects 'Aditi Shah'.
3. Trusting the client (again): format checks improve UX but a determined user bypasses them, so the server must re-validate. This is the same rule that has run through the whole unit.
Formula
FestConnect is complete
Trace the journey: Unit 1 built the form and page in HTML+CSS, Unit 2 made it responsive with Bootstrap, Unit 3 added JavaScript logic and events, Unit 4 read and changed the page through objects and the DOM, and Unit 5 wired register() to validate every field, basic then format, before redirecting on success. That full round trip, structure to style to behaviour to validation, is web designing. In an exam, being able to walk through it end to end is worth more than any single class name.
Summary
Key takeaways
- Format validation checks the SHAPE of filled data, not just its presence.
- Use pattern.test(value): email /^\S+@\S+\.\S+$/, name /^[A-Za-z ]+$/, mobile /^[6-9]\d{9}$/, digits /^\d+$/.
- ^ and $ anchor the pattern to the whole string, turning 'contains' into 'is exactly'.
- Indian mobile = 10 digits starting 6-9; do not over-restrict names (allow spaces).
- Numbers: test !isNaN(Number(value)). Client checks are UX; the server must re-validate.
- Memory hook: a regex is a stencil the whole answer must fit.