The Compare Validator Control

Referring back to Login.aspx, in Listing 5-1, you'll see that logic is used to compare the e-mail address and password entered to hard-coded values. If the e-mail and password don't match what's expected, another label on the form will be set to a message requesting the user to try again. We haven't seen that message yet, because when we clicked the Login button, the client-side validators fired and displayed those red asterisks before the form was submitted. Because the client-side validators didn't indicate that the page was valid, a round-trip to the server wasn't necessary.

ASP.NET includes a CompareValidator control to compare two values. Using a CompareValidator control could be useful for creating, for example, a password change page, on which the new password must be entered correctly twice to ensure that the password is set to the value the user intended. Suppose that we wanted to use the CompareValidator control rather than the Login_Click server-side logic. For the password, we could change the RequiredFieldValidator control to a CompareValidator control, as follows:

<asp:CompareValidator id="comp1"


ValueToCompare = "password"

Type="String" runat="server"/> The ValueToCompare attribute is one way to specify what is to be compared in a CompareValidator control, but another possible way is to use the CompareToControl attribute. Set this attribute to the ID of another control on the form, and the CompareValidator control will instead compare the value of the ControlToValidate attribute to the value of the control pointed to by CompareToControl. If you use the ValueToCompare attribute, an unfortunate side effect can occur. For example, if you use the previous CompareValidator code, the following code would replace the CompareValidator code and be returned to the client:

<span id="comp1"




style="color:Red;visibility:hidden;"></span> This is almost certainly not what you would want to do. In the generated HTML returned to the client browser, the <SPAN> tag contains, in clear text, the ValueToCompare attribute. This example is obviously contrived, but in the real world, you'll certainly encounter situations in which you'd prefer not to expose so much to the client. One solution is to change the clienttarget attribute of the Page directive. Listing 5-1 didn't have a Page directive, but you could add the following line:

<%@ Page Language="c#" clienttarget=downlevel %>

When this directive is added to the Login.aspx code shown in Listing 5-1, rather than the HTML code shown in Listing 5-2, the browser sees the code shown in Listing 5-3. Listing 5-3 The HTML sent to the browser when Login.aspx in Listing 5-1 has the clienttarget=downlevel attribute added to the Page directive

<form name="_ctl0" method="post" action="login.aspx" id="_ctl0"> <input type="hidden"


value="dDwxMDgxMzYzOTAxOzs+" />

<font face="Verdana" color=blue>Login Page</font> </h3> <table> <tr> <td>

<input name="UserEmail" id="UserEmail" type="text" size="30" /> </td> <td>

&nbsp; </td> </tr> <tr> <td>

<input name="UserPass" id="UserPass" type="password" size="30" /> </td> <td> &nbsp;

<td colspan=3 align="center"> <input type="submit" name="_ctl3" value="Login"

onclick="if (typeof(Page_ClientValidate) == 'function') Page_ClientValidate(); "

language="javascript" /> <p>

<span id="Msg"> <font face="Verdana" color="Red" size="2"> </font> </span> </td> </tr> </table> </center> </form>

Note With the current build of ASP.NET, using the clienttarget=d ownlevel attribute/value pair in the

Page directive also causes the emitted HTML code to drop to HTML 3.2 compatible level, with potentially undesired results. Hopefully, future versions of ASP.NET will offer a finer grain of control over the level of HTML sent to the client.

Using clienttarget=downlevel certainly results in much cleaner HTML code! If I were using an older browser, or possibly any browser other than Microsoft Internet Explorer 4.0 or later, the code sent to the browser would look more like that in Listing 5-3, even if clienttarget=downlevel wasn't set. One of the most noticeable differences in the code is that the table cell that previously held the <SPAN> tags for the validators now holds just a nonbreaking space (&nbsp).

One other consequence of changing the client target to a downlevel browser is what happens when you actually submit the form. For instance, clicking the Login button with both fields not filled in results in the page shown in Figure 5-6.

litifi:.'.- km alhju ,-farmtmA11 lBgruripa: Hr ru>ulfc lUfJi-'ll- '■•■ jm. ■

litifi:.'.- km alhju ,-farmtmA11 lBgruripa: Hr ru>ulfc lUfJi-'ll- '■•■ jm. ■

' -t Ji)

i -i- -i

trfj "

Login Page


EoaL |

Piifwvri f"

Layi |

Invalid Credential: PleiJt try agam

Figure 5-6 : The page that appears after clicking Login with both fields blank, and the page targeted at downlevel browsers

Figure 5-6 looks a little different from the page that appeared when we clicked Login without targeting downlevel browsers (shown in Figure 5-4). This page contains a message that reads "Invalid Credentials: Please try again". What's significant is that this message comes from the server-side Login_Click function. Because this code has fired, we know that this page was generated after a round-trip to the server. Using a downlevel browser, or targeting your page for a downlevel browser, will result in more round-trips to the server, but in some cases it's worth the cost.

Several additional attributes are available for the CompareValidator control. MSDN has the complete documentation, but the Type and Operator attributes can be quite useful so we'll look at these in more detail here.

The Type attribute allows you to specify the data type when performing the comparison. The following values are allowed for the Type attribute:

■ String Specifies a string comparison

■ Integer Specifies a whole number numeric comparison

■ Double Specifies a floating-point number comparison

■ Date Specifies a date comparison

■ Currency Specifies a comparison of currency values

The Operator attribute can be used to control the type of comparison that takes place. The examples in this chapter use the default value for Operator, Equal. In this case, we're checking for equality between the control being validated and either some other control specified by ControlToCompare or a constant value specified as ValueToCompare. The other relational operators are listed here and perform the expected comparison:

■ GreaterThan

■ GreaterThanEqual

■ LessThanEqual

There's another allowed value for Operator: DataTypeCheck. By using DataTypeCheck, the control indicates whether the input is the same or can be converted to the type specified by the Type attribute.

Using DataTypeCheck might not seem useful until you think about the checking you must do to ensure that users enter, for example, a valid date where a date value is expected. The following code shows an example of how to ensure that a valid date is entered in a text box:

<asp: TextBox id=txtDate runat="server"/> <asp:CompareValidator ControlToValidate="txtDate" Operator="DataTypeCheck" Type="Date" runat="server"> Must input a date </asp:CompareValidator>

This data type checking is much simpler than what you might need to do on a classic ASP page, and the validator properly handles generation of client-side code, where appropriate (unless you explicitly set clienttarget to downlevel).

0 0

Post a comment