Reading Form Input in ASP.NET Web Pages
In ASP.NET Web Pages, a form's fields are read directly from the incoming request rather than through a code-behind event model. A Razor page checks IsPost to distinguish between the initial GET request and the form submission, then pulls values with Request["fieldName"] or the strongly typed Request.Form collection. Because the page itself is both the form renderer and the handler, the same .cshtml file typically contains the <form method="post"> markup, the C# logic that processes it, and the confirmation message shown afterward, all wired together with @{ } code blocks and inline @Request expressions.
Cricket analogy: A batsman checks the scoreboard before deciding whether to go for a run, the same way a Razor page checks IsPost before deciding whether to render the blank form or process submitted data, much like Rohit Sharma reading the field before a big shot.
The Validation Helper
The Validation helper class centralizes server-side rule checking so a page does not have to hand-write null and length checks for every field. Calling Validation.RequireField("Email", "Email is required") registers a rule tied to a specific field name, and more complex constraints use Validation.Add with a Validators collection such as Validators.Regex(pattern) for email format or Validators.Range(min, max) for numeric bounds. After the form posts, checking Validation.IsValid() before running the database insert guarantees invalid data never reaches persistence logic, and failed rules populate Validation.Errors for the page to render back to the user.
Cricket analogy: A third umpire reviewing a run-out only signals out once every angle satisfies a checklist of conditions, comparable to Validation.IsValid() only returning true once every registered rule, like Validators.Regex on an email field, has passed.
Displaying Validation Messages
Once rules have been registered and checked, the page renders feedback next to each offending field using Validation.For("FieldName") inside the markup, which outputs an inline error message only when that specific field failed. Validation.Summary() produces a consolidated list at the top of the form, useful for fields validated with cross-field rules that don't map cleanly to one input box. Razor's HTML encoding of these helper outputs happens automatically, so a user typing markup into a form field cannot inject a script tag through the error message display.
Cricket analogy: A stadium's electronic scoreboard flashing a specific dismissal reason like 'LBW' right next to the batsman's name is like Validation.For("FieldName") showing an inline error tied to exactly one field that failed.
Server-Side vs Client-Side Validation
Web Pages can layer client-side validation on top of server checks by calling Validation.EnableClientValidation() so the same rule definitions also emit jQuery Validation attributes on the generated inputs, giving users instant feedback before a round trip occurs. This client validation is a usability convenience, not a security boundary, because a request can always be crafted and posted directly to the server bypassing any JavaScript; consequently every rule registered with Validation.RequireField or Validation.Add must still be re-checked with Validation.IsValid() on the server after the page reloads.
Cricket analogy: A batsman shadow-practicing a shot in the dressing room before walking out to face a real delivery is like client-side validation giving instant feedback, but the umpire's final decision on the field, the server check, is what truly counts.
@{
var email = "";
var message = "";
if (IsPost) {
email = Request["Email"];
Validation.RequireField("Email", "Email is required.");
Validation.Add("Email", Validators.Regex(
@"^[^@\s]+@[^@\s]+\.[a-zA-Z]{2,}$",
"Enter a valid email address."));
if (Validation.IsValid()) {
var db = Database.Open("StarterSite");
db.Execute("INSERT INTO Subscribers (Email) VALUES (@0)", email);
message = "Thanks, you're subscribed!";
}
}
}
<form method="post">
<input type="text" name="Email" value="@email" />
@Validation.For("Email")
<input type="submit" value="Subscribe" />
</form>
@Validation.Summary()
<p>@message</p>Never trust client-side jQuery validation as your only safeguard. Because Request.Form values can be posted directly with a tool like curl or Postman, bypassing the browser entirely, Validation.IsValid() must always be re-checked on the server before any data reaches the database.
- IsPost distinguishes the initial GET render from a form submission within the same .cshtml file.
- Request["fieldName"] and Request.Form read posted values directly, without a code-behind event model.
- Validation.RequireField and Validation.Add register server-side rules, including Validators.Regex and Validators.Range.
- Validation.IsValid() must pass before any database write happens.
- Validation.For("FieldName") shows an inline error next to one field; Validation.Summary() lists all errors together.
- Razor automatically HTML-encodes validation output, preventing script injection through error messages.
- Validation.EnableClientValidation() adds jQuery hints for usability, but server-side checks remain mandatory.
Practice what you learned
1. In ASP.NET Web Pages, what does the IsPost property indicate?
2. Which method registers a required-field rule for the Validation helper?
3. What must happen before form data is written to the database in a well-built Web Pages form?
4. Why is client-side validation via Validation.EnableClientValidation() not sufficient on its own?
5. What is the difference between Validation.For("FieldName") and Validation.Summary()?
Was this page helpful?
You May Also Like
Database Access in Web Pages
Learn how the WebMatrix.Data.Database helper connects ASP.NET Web Pages to SQL databases with lightweight Query, Execute, and parameterized SQL methods.
Security in Web Pages
Explore the WebSecurity helper for authentication and roles, and the built-in protections ASP.NET Web Pages provides against XSS and CSRF.
Web Pages vs MVC
Compare ASP.NET Web Pages' page-centric model against ASP.NET MVC's Controller/Model/View separation to understand routing, testability, and when to choose each.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics