This project is read-only.

ValidationGroup

Jan 20, 2010 at 1:05 AM

Hi,

I've noticed that "ModelValidator" has ValidationGroup property, but I don't think it is working, at least not on client side script. Is it known issue? More, I think "EnableClientScript" property does not make any difference too.

Thanks!

Jan 20, 2010 at 1:22 PM

There is still one issue with validation groups ([workitem:4581]). If you have multiple groups on the same page and you have a ValidationSummary for each of them, only the first ValidationSummary will work. Is that the issue you are having?

Another thing you may need to do is add the ValidationGroup property to your input controls (TextBox, DropDownList, etc). Take a look at DefaultVG.aspx in the xVal.WebForms.Demo.WebSite project for an example.

Jan 23, 2010 at 1:02 AM

Not really, I had only one ValidationGroup with 2 buttons for testing. All my inputs and one button were assigned ValidationGroup. But regardless which button I will click, at least client side validation will kick in. So I had one ValidationSummary, few inputs all set to same ValidationGroup, and one button w/o ValidationGroup set. So when you click on that button validation will still happen and inputs will show the error.

EnableClientScript does not affect either, it will still raise client side validation.

Another thought... It makes sense to have Validators separate and not like Manager you have right now, because otherwise formatting and placing validation messages where you want will be a challenge. :) Maybe you should have both options available.

Jan 23, 2010 at 3:32 PM

Thanks for the information. I'll try to reproduce the ValidationGroup issue. Its probably related to the existing issue.

I've added a work item for EnableClientScript: [workitem:5259]

As for separate validation controls, that was my original idea. But having one validation control per model made running the DataAnnotationsValidationRunner a lot easier. I'll take that into consideration. I think the Validation Application Block operates this way (but does not support client side validation).

Jan 23, 2010 at 11:23 PM
jrummell wrote:

I've added a work item for EnableClientScript: [workitem:5259]

This is fixed in change set 40682.

Jan 24, 2010 at 8:20 AM

Thanks for a quick reply and fix. :)

In regards to VAB, in reality it uses same method as a regular validation, so one server tag per control (EntLibValidators:PropertyProxyValidator). It might seem not logical at the beginning, but again, you need to accomodate UI design issues too, and for that it is easier to have separate control, otherwise you will have limited abilities in placing error message.

I was just wondering...are you using some wrapper over xVal, so whenever they improve their code you get those changes?

Jan 24, 2010 at 3:40 PM
haypet wrote:

In regards to VAB, in reality it uses same method as a regular validation, so one server tag per control (EntLibValidators:PropertyProxyValidator). It might seem not logical at the beginning, but again, you need to accomodate UI design issues too, and for that it is easier to have separate control, otherwise you will have limited abilities in placing error message.

You are absolutely correct. Separate validators for each property does make more sense from a UI perspective. Thanks for pointing out something that should have been obvious to me! Perhaps I'll add a ModelPropertyValidator in the next release.

haypet wrote:

I was just wondering...are you using some wrapper over xVal, so whenever they improve their code you get those changes?

We use xVal to generate jQuery Validation rules from your model's DataAnnotations attributes. So if xVal adds support for new attributes, then yes. But that's about all we can do with it since its very specific to MVC.

I'm starting to wonder if it would be better to create normal ASP.NET validators from your model's DataAnnotations attributes instead. jQuery is all the rage right now and with MVC it makes perfect sense. But why re-invent the wheel for WebForms?

Jan 24, 2010 at 3:42 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jan 26, 2010 at 7:49 PM
jrummell wrote:
haypet wrote:

In regards to VAB, in reality it uses same method as a regular validation, so one server tag per control (EntLibValidators:PropertyProxyValidator). It might seem not logical at the beginning, but again, you need to accomodate UI design issues too, and for that it is easier to have separate control, otherwise you will have limited abilities in placing error message.

You are absolutely correct. Separate validators for each property does make more sense from a UI perspective. Thanks for pointing out something that should have been obvious to me! Perhaps I'll add a ModelPropertyValidator in the next release.

haypet wrote:

I was just wondering...are you using some wrapper over xVal, so whenever they improve their code you get those changes?

We use xVal to generate jQuery Validation rules from your model's DataAnnotations attributes. So if xVal adds support for new attributes, then yes. But that's about all we can do with it since its very specific to MVC.

I'm starting to wonder if it would be better to create normal ASP.NET validators from your model's DataAnnotations attributes instead. jQuery is all the rage right now and with MVC it makes perfect sense. But why re-invent the wheel for WebForms?

I am glad to help. :) Working right now as a Front End Developer helps to look at things differently.

If you can find a way to integrate some ready jQuery validation library (like http://bassistance.de/jquery-plugins/jquery-plugin-validation/) into client side validation, then you will not need xVal at all, and will have a complete solution. While you can live w/o client side validation, I think having it adds a lot of benefits. But things like ValidationGroup are important for Web Forms. If I get some free time I will look into source.

Jan 26, 2010 at 11:38 PM

A fresh perspective is always nice, thanks.

xVal actually uses the jQuery Validation plugin you mentioned. But I need to become much more familiar with the javascript before I can attempt to generate the rules without xVal. If you do have an opportunity to look over the source, I'd be glad to hear your input.

Jan 30, 2010 at 12:24 AM

Well, I think if you remove client side validation, then there is almost nothing left. I think it will be great to properly integrate jQuery Validation and maybe implement some more common Data Annotation validation rules. I will try to look at source this few days.