Linux中国 Linux中国门户站!
设为主页 设为主页
收藏本站 收藏本站
 
当前位置 :首页 ->编程语言 ->ASP.NET ->正文

深入讲解 ASP+ 验证 (转自ms 一)

来源:Linuxdby.com 作者:Webmaster 时间:2007-04-28 点击: [收藏] [投稿]
深入讲解 ASP+ 验证
Anthony Moore
Microsoft Corporation
2000年10月

摘要:有关使用 ASP+ 验证 Web 控件的详细讲解。

目录


简介
入门
何时发生何事?
服务器端的验证序列
客户端的验证
有效性规则和有用的错误信息
Enabled、Visible 和 Display 属性的作用
CustomValidator 控件
哪些控件可以被验证?
到此为止


--------------------------------------------------------------------------------


简介

这篇文章详细讲解了 ASP+ 验证控件的工作方式。如果要生成其中包含验证控件的复杂页面,或是要扩展验证框架,建议您阅读本文。如果要学习使用验证控件,或是要决定是否使用验证控件,请参见“ASP+ 中的用户输入验证(英文)”。


入门

我们知道,在整个 ASP+ 开发过程中,了解验证非常重要。看看如今的大多数商业 Web 站点,您会发现,这些站点中有许多表单,这些表单明显是通过执行大量手写的代码来执行验证。编写验证代码并不是一件有趣的工作。如果要通过编写代码来显示数据表或动态生成图表,可能会很吸引人,但是没有人可以向他的同事证实这种很“酷”的方法能够禁止在姓名字段中输入空值。

因为其它一些原因,Web 应用程序的验证也是非常麻烦的。HTML 3.2 对您可以控制的内容或可以从用户处得到的反馈的限制很多,因此无法应用在功能更全的客户机上可以使用的技巧,例如禁止用户输入某些字符,或发出嘀声。使用浏览器脚本可能会产生更强大的验证。但是这种方法很难得以证实,因为客户浏览器中并非一定有脚本,并且恶意的用户可以绕过。因此,为了保证站点安全,有必要对服务器进行同样的检查。

在开发 ASP+ 时,我们的初衷是只使用一个控件来处理验证,可能本该是一个能够显示错误的 TextBox 控件。可是到了设计该控件时,却发现无法实现这种愿望。我们研究了大量的数据输入表单,试图找到可以适用于尽可能多的表单的一种解决方案。我们发现,数据输入表单具有许多有趣的特性:

尽管错误信息或图标经常与输入元素相邻,但是它们几乎总是位于表的不同单元格中。
页面中经常会有一个区域来汇总所有错误。
许多站点包含客户端脚本,以便提供更快捷的反馈,同时防止白白地在与服务器之间往返。
许多包含客户端脚本的站点在出现错误时会显示信息框。
不仅会验证文本输入,还会验证下拉列表和单选按钮。
如果某个字段为空,站点通常会显示与该条目无效时不同的信息或图标。

许多有效性检查可以很好地代替常用的表达式。
验证通常是基于两个输入之间的比较结果。
90% 或 90% 以上的验证任务是一些常见的操作,例如检查姓名或邮政编码。大多数站点似乎仍在重复进行这些工作。
因为站点之间的差别通常太大,无法获得一种完美的解决方案来处理每个站点的所有验证任务。
考虑了上述所有情况,最终获得的解决方案包括五个验证器控件、ValidationSummary 控件以及与 Page 对象的集成。同时很明显,该解决方案需要扩展,在客户机和服务器上均需要有一个 API 来配合。

我们在研究进行的各种验证时发现,我们似乎需要一个更大的工具箱。在大多数组件环境中,例如 Microsoft⮠ActiveX⮯𜌦葤𛬥ﯨ㽦𜬦𝥨𛾥𐆦逦𜉩ꌨ𛶧𚄥꟨㽩𛆦营谤𘀤𘪦𛶤𘭯𜌥䄧𐆤𘍥𐌦补𜏤𘋧𚄤𘍥𐌥𑞦ৣ¤𘍨🇯𜌥𙸥彠Microsoft⮠.NET 框架中有神奇的继承性,可以提供一套控件来对特定的属性进行特定的验证,因为派生每个新控件所需的额外工作量非常小。

这些控件所完成的大多数工作均在其公用的父级 BaseValidator 中实现。您也可以从 BaseValidator 或其它控件派生来完成各项工作。实际上,即使 BaseValidator 都懒得实现其自己的 Text 属性,而是从 Label 属性继承。


何时发生何事?

在处理包含验证 Web 控件的页面时,了解事件序列非常有效。如果某个验证条件是可选的,您需要准确了解客户机和服务器上何时进行验证。如果要自己编写验证例程,可能会非常耗时,或者有副作用。同时,了解调用验证例程的时机也很重要。

首先,让我们看一下服务器。


服务器端的验证序列

了解页面的有效期非常重要。如果习惯于在 Visual Basic 或类似功能齐全的客户机工具中处理表单,则需要花一定的时间来了解。页面和页面上的所有对象并非在与用户交互时一直有效,尽管有时表面上是这样。

以下是在第一次访问某个页面时一个简化的事件序列:

基于 ASPX 文件创建页面及其控件。
触发 Page_Load 事件。
页面和控件属性保存在一个隐藏字段中。
页面和控件转换到 HTML。
丢弃所有内容。
现在,当用户单击某个按钮或类似控件时,将返回服务器,然后执行一个类似的事件序列。该序列称为返回序列:


基于 ASPX 文件创建页面及其控件。
从隐藏字段恢复页面和控件属性。
根据用户输入更新页面控件。
触发 Page_Load 事件。
触发更改通知事件。
页面和控件属性保存在一个隐藏字段中。
页面和控件转换到 HTML。
再次丢弃所有内容。
我们为什么不将所有对象保留在内存中呢?因为使用 ASP+ 建立的 Web 站点无法处理数量非常大的用户。因此,服务器的内存中只保留马上要处理的内容。

何时进行服务器端验证?在第一次获取页面信息时,根本不会进行服务器端验证。大多数最终用户都非常认真,我们允许用户自己确认在表单中填写的信息是否正确,然后我们再使用红色的文字通知用户填错的信息。

在返回事件序列中,第 3 步和第 4 步之间会进行验证。也就是说,进行验证是在来自用户的数据装回控件属性后,但在大多数代码执行之前。这意味着在编写用户事件代码时,通常可以利用已经进行的验证。一般情况下,您都会希望这样做。

 如果您对本文有任何疑问或者建议,请到讨论区发表您的意见: >> 论坛入口 <<



上一篇:使用C#控制远程计算机的服务   下一篇:C# 特性(Attribute)入门(一)

文章评论】 【收藏本文】 【推荐好友】 【打印本文】 【我要投稿】 【论坛讨论
更多相关文章
Power by linux-cn.com 粤ICP备05006655号