• Choose a category
• All
• Classic-Fiction

Using the ValidationGroup property is simple; just define it for all the validation controls that you want to group together, and then assign the same name to the ValidationGroup property of the button that you want to fire the validation. Here’s an example:

ValidationGroup="Group1"

ControlToValidate="TextBox1"

ErrorMessage="TextBox1 is mandatory" />

ValidationGroup="Group2"

ControlToValidate="TextBox2"

ErrorMessage="TextBox2 is mandatory" />

ValidationGroup="Group1" />

ValidationGroup="Group2" />

The two RequiredFieldValidator controls belong to distinct validation groups—Group1 and Group2. The first button validates only the controls defined within Group1; the second button takes care of the input associated with Group2. In this way, the validation process can be made as granular as needed.

Important

The ValidationGroup property can also be defined optionally on input controls. This is required only if you use the CustomValidator control as a way to check whether a given input control belongs to the right validation group. Unlike other validators, the CustomValidator control, in fact, is not strictly bound to a specific control.

Validation groups are well reflected on the server-side, where the Validate method of the Page class features an overload that lets you select the group according to which the page must be validated.

Dealing with Validation in Cross-Page Posts

Validation groups are especially helpful when combined with cross-page postbacks. As you saw earlier in the chapter, a cross-page postback allows a button to post the contents of the current form to another page, in a way overriding the single-form model of ASP.NET. In a cross-page posting scenario, what if the original page contains validators? Imagine a page with a text box whose value is to be posted to another page. You don’t want the post to occur if the text box is empty. To obtain this behavior, you add a RequiredFieldValidator control and bind it to the text box:

ControlToValidate="Keyword" Text="*" />

OnClick="Button1_Click" PostBackUrl="doSearch.aspx" />

As expected, when you click the button the page won’t post if the text box is empty; and an asterisk (plus an optional message) is displayed to mark the error. This is because RequiredFieldValidator benefits the client-side capabilities of the browser and validates the input controls before proceeding with the post. Hence, in the case of empty text boxes, the button doesn’t even attempt to make the post.

Is that all, or is there more to dig out?

Let’s work with a CustomValidator control, which instead requires that some server-side code be run to check the condition. Can you imagine the scenario? You’re on, say, crosspage.aspx and want to reach doSearch.aspx; to make sure you post only under valid conditions, though, you first need to make a trip to crosspage.aspx to perform some validation. Add this control, write the server validation handler in crosspage.aspx, and put a breakpoint in its code:

Text="*"

ControlToValidate="Keyword"

OnServerValidate="EnsureValidKeywords" />

Debugging this sample page reveals that posting to another page is a two-step operation. First, a classic postback is made to run any server-side code registered with the original page (for example, server-side validation code or code associated with the click of the button). Next, the cross-page call is made to reach the desired page:

void EnsureValidKeywords(Object source, ServerValidateEventArgs args)