I am looking for a way to return the following information from my custom validation code:
public enum ValidationErrorTypeFlags
{
Error_Input = 1 << 0, // a "field specific" error which is checked both clientside and serverside
Error_Input_ServerSide = 1 << 1, // a "field specific" error which can only be checked serverside
Error_General = 1 << 2 // serverside general error
}
Inside the validation code (either an IValidatableObject or a ValidationAttribute), when I detect an error, I would like to be able to associate one of the above error types with the ValidationResult.
Then I want to be able to iterate through the validation errors in either the Controller or the View and distinguish between these error types.
I'm currently using MVC 3 (happy to upgrade to 4).
NB:
ModelState does not preserve ValidationResults AFAIK - you can only access errors in ViewData.ModelState.Values.Items[x].Errors - and these have been converted to System.Web.Mvc.ModelError
It seems that MVC validation only allows you to access [key, 'error message'] type validation results after validation has completed.
The hack I'm using at present is to decorate the error message inside the custom validation code:
var field = new[] { validationContext.DisplayName };
return new ValidationResult("+Invalid format - use yyyy-mm-dd", field);
And then look for error messages which start with +,-,* in the controller.
From custom validation code (no idea how to accomplish from built-in ones) you can do that by creating a custom ValidationResult class by inheriting from the base and return from your custom validation attributes.
public class CustomValidationResult: ValidationResult
{
// additional properties
}
Then from the controller you can cast and check if the validation result is your custom type and act accordingly.
Update:
The above idea don't work because the ValidationResult class is in DataAnnotations assembly and they are converted into ModelValidationResult and that's all we can access in MVC.
It seems passing extra information from the data annotation validations to the MVC looks like not quite easy!
I was going through the source code and found that it is the ValidatableObjectAdapter that converts the IEnumerable<ValidationResult> into IEnumerable<ModelValidationResult>. I don't see much benefit on extending this class but we can easily create a custom ValidatableObjectAdapter by implementing the ModelValidatorand duplicating the Validate code.
We have to create a custom ModelValidationResult and custom ValidationResult(it is this custom ValidationResult we will b returning from validations) and in the ConvertResults method we can put our conversion code that takes care of the additional information.
public class CustomValidatableObjectAdapter : ModelValidator
{
public CustomValidatableObjectAdapter(ModelMetadata metadata, ControllerContext context)
: base(metadata, context)
{
}
public override IEnumerable<ModelValidationResult> Validate(object container)
{
object model = Metadata.Model;
if (model == null)
{
return Enumerable.Empty<ModelValidationResult>();
}
IValidatableObject validatable = model as IValidatableObject;
if (validatable == null)
{
throw new Exception("model is of not type validatable");
}
ValidationContext validationContext = new ValidationContext(validatable, null, null);
return ConvertResults(validatable.Validate(validationContext));
}
private IEnumerable<ModelValidationResult> ConvertResults(IEnumerable<ValidationResult> results)
{
foreach (ValidationResult result in results)
{
// iterate the ValidationResult enumeration and cast each into CustomValidationResult
// and conver them into enumeration of CustomModelValidationResult.
}
}
}
Finally we have to tell the DataAnnotationsModelValidatorProvider use this our CustomValidatableObjectAdapter in the Application_Start event of Global.asax.cs.
DataAnnotationsModelValidatorProvider.RegisterDefaultValidatableObjectAdapterFactory((metadata, context) => new CustomValidatableObjectAdapter(metadata, context));
So you have to create a custom ValidationResult, custom ModelValidationResult and a custom ValidatableObjectAdapter.
I haven't tested this but I hope this will work. I may suggest a better and easier solution than this.
Related
I have not been able to find a definitive answer about this. In asp.net MVC 5, when some fields are required only if some condition is true, we will need to implement a custom validation attribute by inheriting from ValidationAttribute. So, I have this:
public class RegistrationValidationAttribute : ValidationAttribute
{
protected override ValidationResult IsValid(object value, ValidationContext validationContext)
{
RegistrationModel model = (RegistrationModel)value;
if (model.IsNewbie)
{
if (model.SelectedCoachId == 0)
{
return new ValidationResult("Since you are a newbie, you have to select a coach.");
}
if (model.SelectedDominantHand == 0)
{
return new ValidationResult("If you are a newbie, you have to tell us if you are a leftie or rightie.");
}
}
return ValidationResult.Success;
}
}
But, this will only return 1 error message even if the registrant says that he is a newbie and does not select a coach nor specify his dominant hand. I wish that the ValidationResult class had a constructor that takes a collection of error messages.
So, do I have to split this custom validation attribute into 2 custom validation attribute classes, one of which says MustSelectCoachIfNewbieAttribute and the other one says MustSpecifyDominantHandIfNewbieAttribute?
Is it possible to accomplish this in a single custom validation attribute class? Thanks.
I have a Validation Framework set up to automatically validate parameters of Web Api action methods (including OData action methods). However, this does not work for PATCH requests that store the changed properties in a Delta<Entity> type.
I've done some digging around and, as you can see in the ASP.NET source code of Delta, it has the NonValidatingParameterBinding attribute, which means that Delta's are not subjected to validation.
Now an obvious solution would be to apply the delta and then perform manual validation of the resulting entity.
But are there other solutions that do not require applying the patch? Ideally it should happen automatically before the action method is called...
Thanks.
It was an explicit design decision to not validate Delta<Entity>. Reason being, a Delta<Entity> is only a partial entity and by definition could be invalid. As you have guessed, the proper approach is to validate the entity after the Delta<TEntity> is applied on top of it.
Sample code,
public void Patch(Delta<Customer> delta)
{
Customer c = new Customer();
delta.Patch(c);
Validate(c, typeof(Customer));
}
private void Validate(object model, Type type)
{
var validator = Configuration.Services.GetBodyModelValidator();
var metadataProvider = Configuration.Services.GetModelMetadataProvider();
HttpActionContext actionContext = new HttpActionContext(ControllerContext, Request.GetActionDescriptor());
if (!validator.Validate(model, type, metadataProvider, actionContext, String.Empty))
{
throw new HttpResponseException(Request.CreateErrorResponse(HttpStatusCode.BadRequest, actionContext.ModelState));
}
}
Complete sample here.
We too arrived at this problem. However, we are using a custom version of Delta<T> (heavily based on OData).
The core issue (apart from [NonValidatingParameterBinding]) is that the entity is hidden (behind delta.GetEntity()) and hence will not be validated. Also we only want to validate changed properties.
We solved this by adding the IValidateObject interface to our custom Delta class, making the signature as follows:
[NonValidatingParameterBinding]
public class Delta<TEntityType> : DynamicObject, IDelta, IValidatableObject
where TEntityType : class
This can probably also be done in a class inheriting from OData's Delta<T>, but that is not something we have tried.
Implementation of the interface looks like this:
public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
var entity = this.GetEntity();
var innerValidationContext = new ValidationContext(entity);
List<ValidationResult> validationResults = new List<ValidationResult>();
foreach (var propertyName in this.GetChangedPropertyNames())
{
innerValidationContext.MemberName = propertyName;
Validator.TryValidateProperty(EntityType.GetProperty(propertyName).GetValue(entity), innerValidationContext, validationResults);
}
return validationResults;
}
Hope this helps!
/Victor
I have two separate classes derived from the same interface, but have different validation/data annotations assigned. The requirement is that the same data needs to be collected, but on one screen nothing is required (a save screen), but on the other there are some required fields (a submit/finalize screen.)
I've made a PartialView that is to be used in two separate View, one for save, one for final submit.
I've tried using the parent Interface as the View's model, however my validators don't fire (as I expect, I'm guessing that because the Interface itself doesn't have any annotations, nothing will fire.) Is there a way to have the page dynamically choose one class or the other depending on which page I'm using instead of the Interface?
As a side-note, this is being done in ASP.net MVC 3 with Razor.
You can achieve what you want with one class, and a little lateral thinking.
First, create your class, with the validation baked in. Next, create a custom ModelValidatorProvider inheriting from DataAnnotationsModelValidatorProvider, like so:
public class MyMetadataValidatorProvider : DataAnnotationsModelValidatorProvider
{
protected override IEnumerable<ModelValidator> GetValidators(ModelMetadata metadata, ControllerContext context, IEnumerable<Attribute> attributes)
{
var vals = base.GetValidators(metadata, context, attributes);
// check to see if any keys have been inserted
if (context.Controller.ViewData.Keys.Count > 0)
{
// check if we have a key named "NoValidate" with a value of true
// do not return the validtors if we do
if ((bool)context.Controller.ViewData.FirstOrDefault(k => k.Key == "NoValidate").Value)
{
// we do not want to return our validators, return an empty list
return new List<ModelValidator>();
}
}
else
{
// check if the form has a key named "NoValidate" with a value of true
// do not return the validtors if we do
if (context.HttpContext.Request.Form["NoValidate"].ToLowerInvariant() == "true")
{
// we do not want to return our validators, return an empty list
return new List<ModelValidator>();
}
}
// we want to return our validators
return vals;
}
}
Next, register the custom ModelValidatorProvider in Application_Start in Global.asax.cs, like so:
ModelValidatorProviders.Providers.Clear();
ModelValidatorProviders.Providers.Add(new MyMetadataValidatorProvider());
Then, add the following to your view (this will govern whether the validators are returned when the form is POSTed):
#Html.Hidden("NoValidate", ViewData.FirstOrDefault(k => k.Key == "NoValidate").Value)
Finally, add actions like the following:
public ActionResult Index()
{
var model = new MyModel();
// this will set validation to appear
ViewData.Add("NoValidate", false);
// this will suppress validation
ViewData.Add("NoValidate", true);
return View(model);
}
[HttpPost]
public ActionResult Index(MyModel model)
{
// we DO want validation, so let's test for it in addition
// to testing if the ModelState is valid
if (Request.Form["NoValidate"].ToLowerInvariant() != "true" && ModelState.IsValid)
{
ModelState.Clear();
var newmodel = new MyModel();
ViewData.Add("NoValidate", true);
return View(newmodel);
}
ViewData.Add("NoValidate", false);
return View(model);
}
Note that you can control whether the validation appears in your GET action by setting the NoValidate key in ViewData as you want. On the POST, the validation is governed by the form value for NoValidate.
IMPORTANT NOTE: In your action which requires validation, you need to add a test to confirm that the Form does not have the key NoValidate, or its value is not True, in order to enforce that a user cannot avoid the validation.
UPDATE
At first, I had validation only appearing when certain conditions were true. Idecided this was a BAD IDEA, so now validation will only be suppressed if the conditions are true.
Each view should be strongly typed to a separate view model. Each viewmodel then has the validation logic on it (annotations) or inherits from a base that has the required validation on it.
Any logic that cannot be inherited is simply set on your ViewModel itself. If its a small moderl I would consider just copy/paste and two separate viewmodels with their own set of attributes.
You can use AutoMapper to easily map between some concrete object that implements your interface and your ViewModels.
Could you use one class? You can create a filter that allows you to manage the validation errors for an action. In your case you can add an attribute to the Save action and ignore the required errors, but the validations will run for the submit/finalize action. This example will discard all the errors.
public class DontValidateEmailAttribute : ActionFilterAttribute {
public override void OnActionExecuting(ActionExecutingContext filterContext) {
var modelState = filterContext.Controller.ViewData.ModelState;
var incomingValues = filterContext.Controller.ValueProvider;
foreach (var key in modelState.Keys)
modelState[key].Errors.Clear();
}
}
I learnt this technique from Steve Sanderson's Pro ASP NET MVC 3. He uses the technique to validate a model that has required fields but the data entry is a multistep wizard. If the value has not been returned in the form post, he removes the errors for that property.
I have an ASP.NET MVC 2 project in which I've created a data transfer object to receive data from a web page form. The form has two groups of checkboxes on it. I want to validate the object to make sure that at least one of the checkboxes in each group is checked.
I'm doing the validation on the server side so that a user won't be able to hack around any client-side validation. (I will add client-side validation with jQuery later; that's easy.)
My understanding is that I have to create my own custom ValidationAttribute for my data transfer object class, but I don't understand how to create and use one that can accept an arbitrary list of checkbox properties to make sure that at least one of them is true. I am guessing I will have to call the attributes like this:
[AtLeastOneCheckbox("set1check1", "set1check2", "set1check3",
ErrorMessage = "You must check at least one checkbox in set 1.")]
[AtLeastOneCheckbox("set2check1", "set2check2", "set2check3", "set2check4", "set2check5",
ErrorMessage = "You must check at least one checkbox in set 2.")]
public class MyFormDTO
{
...
}
What would the implementation of AtLeastOneCheckboxAttribute look like?
Or is there a different way that I should do this kind of validation?
if you have several checkbox groups, you just need to deine the attribute several times.
[AttributeUsage( AttributeTargets.Class)]
public class AtLeastOneCheckboxAttribute : ValidationAttribute
{
private string[] _checkboxNames;
public AtLeastOneCheckboxAttribute(params string[] checkboxNames)
{
_checkboxNames = checkboxNames;
}
protected override ValidationResult IsValid(object value, ValidationContext validationContext)
{
var propertyInfos = value.GetType().GetProperties(BindingFlags.Public | BindingFlags.Instance)
.Where(x=>_checkboxNames.Contains(x.Name));
var values = propertyInfos.Select(x => x.GetGetMethod().Invoke(value, null));
if (values.Any(x => Convert.ToBoolean(x)))
return ValidationResult.Success;
else
{
ErrorMessage = "At least one checkbox must be selected";
return new ValidationResult(ErrorMessage);
}
}
}
UPDATE
as you have found out, class-level validation is called only after all properties pass. In order to get the error, just use empty string as the key.
Your DTO, which is I'm guessing your ViewModel can ihert IDataErrorInfo.
Then you can do your validation like this (note I didn't compile this)
//I'm guessing you have a list of checkboxes
IEnumerable<bool> checkBoxes1;
IEnumerable<bool> checkBoxes2;
public class MyFormDTO : IDataErrorInfo
{
public string this[string prop]
{
get
{
if(prop == "checkBoxes1")
{
if(checkBoxes1.Any(x => x == true))
{
return "Error: You need to select atleast one checkbox from set1";
}
}
else if(prop == "checkBoxes2")
{
if(checkBoxes2.Any(x => x == true))
{
return "Error: You need to select atleast one checkbox from set2";
}
}
return null;
}
}
public string Error { get { return null; } }
}
I am exploring Sharp Architecture and I would like to know how to
access the validation results after calling Entity.IsValid().
I have two scenarios e.g.
1) If the entity.IsValid() return false, I would like to add the
errors to ModelState.AddModelError() collection in my controller.
E.g. in the Northwind sample we have an EmployeesController.Create()
action when we do employee.IsValid(), how can I get access to the
errors?
public ActionResult Create(Employee employee) {
if (ViewData.ModelState.IsValid && employee.IsValid()) {
employeeRepository.SaveOrUpdate(employee);
}
// ....
}
[I already know that when an Action method is called, modelbinder
enforces validation rules(nhibernate validator attributes) as it
parses incoming values and tries to assign them to the model object
and if it can't parse the incoming values then it register those as
errors in modelstate for each model object property. But what if i
have some custom validation. Thats why we do ModelState.IsValid
first.]
2) In my test methods I would like to test the nhibernate validation
rules as well. I can do entity.IsValid() but that only returns true/
false. I would like to Assert against the actual error not just true/
false.
In my previous projects, I normally use a wrapper Service Layer for
Repositories, and instead of calling Repositories method directly from
controller, controllers call service layer methods which in turn call
repository methods. In my Service Layer all my custom validation rules
resides and Service Layer methods throws a custom exception with a
NameValueCollection of errors which I can easily add to ModelState in
my controller. This way I can also easily implement sophisticated
business rules in my service layer as well. I kow sharp architecture
also provides a Service Layer project. But what I am interested in and
my next question is:
How I can use NHibernate Vaidators to implement sophisticated custom
business rules (not just null,empty, range etc.) and make
Entity.IsValid() to verify those rules too ?
"How I can use NHibernate Vaidators to implement sophisticated custom business rules (not just null,empty, range etc.) and make Entity.IsValid() to verify those rules too ?"
You have to create a custom validation attribute:
here is an example:
[AttributeUsage(AttributeTargets.Field | AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
public sealed class LoginUniqueAttribute : ValidationAttribute
{
private static readonly string DefaultErrorMessage = MUI.LoginNameInUse;
public LoginUniqueAttribute()
: base(DefaultErrorMessage)
{
}
public override string FormatErrorMessage(string name)
{
return DefaultErrorMessage;
}
public override bool IsValid(object value)
{
if (string.IsNullOrEmpty((string)value))
{
return true;
}
var userService = IoC.Resolve<IUserService<User>>();
return userService.GetByLogins(new[] { (string)value }).Count() == 0;
}
}
and usages into a UserInput dto
[Required]
[LoginUniqueAttribute]
[RegularExpression("^[A-Za-z0-9.'\\s]+$", ErrorMessage = "Only characters and digits are allowed")]
[DisplayNameLocalized(typeof(MUI), "LoginName")]
public string LoginName { get; set; }
also do not forget to initialize the validation in your global.asax.cs file on Application_Start:
private void InitializeValidator()
{
var provider = new NHibernateSharedEngineProvider();
NHibernate.Validator.Cfg.Environment.SharedEngineProvider = provider;
}