如何针对多个验证组进行验证?
我有两个验证组:父验证组和子验证组
我有一个添加按钮,只需验证子验证组,这很容易完成。保存按钮需要针对客户端和服务器端的父验证组和子验证组进行验证。我想我知道如何通过为每个组调用 Page.Validate("groupname") 方法来在服务器端完成此操作,但是如何在客户端完成此操作?
I have two validation groups: parent and child
I have an add button that needs to only validate the child validation group which is easily done. The save button needs to validate against the parent and child validation groups, both client side and server side. I think I know how to do it server side by calling the Page.Validate("groupname") method for each group, but how can it be done client side?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您应该能够通过创建一个使用 Page_ClientValidate 然后让按钮调用该函数
You should be able to accomplish this by creating a javascript function that uses Page_ClientValidate and then having the button call that function
CAbbott 答案的问题在于,在调用验证“子”组之后,不会显示“父”组中发生的验证错误。 Oleg 的答案的更小问题是,在“父”组准备就绪之前,不会发生“子”组的验证。
要允许同时对多个组进行客户端验证,我们真正需要做的就是重写 Javascript IsValidationGroupMatch 方法,该方法确定是否将某个控件包含在当前正在验证的集合中。
例如:
The problem with CAbbott's answer is that validation errors that occur in the "parent" group will not be displayed after the call to validate the "child" group. The more minor problem with Oleg's answer is that validation of the "child" group will not occur until the "parent" group is ready.
All we really need to do to allow client-side validation of more than one group at the same time is to override the Javascript IsValidationGroupMatch method which determines whether or not a control is to be included in the current set being validated.
For example:
如果调用 Page_ClientValidate(..) 两次,则只会显示最后一次的验证结果,并且可以正常,而第一次则不行。因此,仅当第一个调用返回 true 时才应进行第二个调用
If you call Page_ClientValidate(..) twice, only the last validation result will be shown and it can be OK while the first is not. So the second call should be made only if the first has returned true
无论您采用哪种方式,都需要进行一些黑客攻击才能绕过 ASP.Net 的假设,即您不会尝试这样做。我赞成采用可重用的方法,该方法明确涉及所涉及的黑客行为。
Whatever way you do it requires some hacking to get round ASP.Net's assumption that you wouldn't try to do this. I favour a reusable approach which is explicit about the hackery involved.