Feedback Request for Next Release please !!!

Jan 26, 2009 at 9:10 PM
Edited Jan 27, 2009 at 8:15 AM
I want to broaden the feature set and appeal of VA for the next release. I've identified the following three areas where I may be able to achieve this:
  1. Support other aspect frameworks such as Unity Interception and Castle.DynamicProxy2.
  2. Build for different platforms such as Silverlight and the Compact Framework.
  3. Add to the current set of built-in validators.
But I’m guessing - I’d love some feedback - what else could be added or enhanced. Please let me know what’s important to you.
  • If you are using VA, what are the features you would like to see implemented? Are there any general case validators that you would find useful - validators beyond the typical set? How about "FileExists" or "DateBefore"?
  • If VA doesn't offer what you need, what are the features that you require? What don't you like about it?
  • In regard to what VA currently offers, what would you like improved? Is the exception formatting approach good for you? Are the default exception messges good to go? What features could do just a little bit more for you? Is there anything that is confusing about the api or the wiki documentation?
Please reply on this thread, raise a new issue, vote on an issue, or email me. I would very much appreciate any feedback you may have.

many thanks
Jan 27, 2009 at 4:01 PM
... in terms of aspect frameworks et al, you might want to consider LinFu 2.0: . Here is a good introduction article: .

"If you're already using another IOC container such as Castle, Ninject, StructureMap, or AutoFac (and even Spring.NET), you might be wondering how LinFu.IOC compares to the other containers. You can think of LinFu as the "Swiss Army knife" of IOC containers. It is not only an IOC container (per se), it is also a general implementation of the Factory Pattern on steroids ... "
Feb 11, 2009 at 10:17 AM
Perhaps allow the developer to provide a custom error message when decorating with the validator attribute (i.e. an additional constructor on validator attribute that takes a string or looks up from a resource file).
Feb 11, 2009 at 11:17 AM
Can you provide a little more info on this - how would the content on the error message in the attribute differ from the content of the custom exception message? Thanks
Feb 11, 2009 at 11:42 AM
I think it would be handy an error message defined via the attribute would be used for the custom exception message.

For example, I could define the following:
[InRange(0.0, 100.0, "The value for total must be between zero and one hundred.")]
public decimal Total{ get; set; }
So when the validation exception is thrown it would then contain that string as the message, and then that error message could be shown in the UI. Hope that makes sense!
Feb 11, 2009 at 12:33 PM
This is achieved by configuring the exception message. Have you looked at the [Exception Formatting] page on the wiki? Setting a custom exception message means you only need to do customization/localization once for each validator rather than on every application of the validation.
Feb 11, 2009 at 1:31 PM
Yes, but that assumes that you want all error messages for a validator to be in a similar format (i.e. {propertyname} is required) which I guess is fine as a default. But say the property name was "FirstAndLastName", then the message would read "FirstAndLastName is required", which may not match the text box label in the UI. For a better user experience, I would personally prefer the option of having a message such as "A first name and last name is required" provided as the custom error message.

It seems that currently if I change the custom error message for NotNull, it is going to affect all validators and there is no way to override this? I think truly 'user friendly' error messages should be object specific and not governed by a global rule set.  Defining the message along with the validator attribute just seems like a more natual fit (ala ASP.Net Validator controls).

PS - Some built-in date validators would be good (i.e. NotMinDate, Between, Before, After etc).
Feb 11, 2009 at 1:54 PM
I understand your point but I need to state that because validation exception message formatting is done by a function which is provided with the context of where validation failed (type/property/method/parameter), the message is 'object specific' and not a general global rule.

For most of the validators I use functions that query the context for the presence of a property. If it exists I want to format the message something like "{Property.Name} is required.". I localize all validation messages in resx files. If I was to use a "FirstAndLastName" property (which in reality is "Name"), I would look up the property name in the resx to get the localized name, so I could output "A first name and last name is required" using this system.
Feb 11, 2009 at 2:28 PM
Edited Feb 11, 2009 at 2:44 PM
Well the "FirstAndLastName" was just an example of a property name that I wouldnt want to see in the UI :) , but I now better understand how to leverage the resx system to get the friendly messages that I am after. Thanks for the explanations!