How can I disable the built-in validation for a property of float type?
We have our own custom validation attributes that work fine.
But we have this scenario where we want a float property to accept ( .1 ) as a valid float number. Which obviously means ( 0.1 ), but this number is not accepted by the built-in validation.
Basically I want to disable validation on property-by-property bases and still enforce my own custom validations.
Use a nullable type in your viewmodel property e.g:
float? MyProp {get; set;}
This stops the built in validation from occurring but will still use your custom validation. Obviously as you have now made the property nullable, you may want to put a Required validation attribute on the property to ensure you get a value.
Turns out that .3 is actually accepted by the default model binder. The problem is actually with the client validation implementation. If client validation isn't important to you, you can solve this problem by opening the web.config and changing ClientValidationEnabled to false within AppSettings.
Related
If I put [Required] attribue over a property in a model then the <input> helper tag will throw out a validation error if no value is provided, but also it will be affecting database structure.
However does this
modelBuilder.Entity<CartItem>(e =>
{
e.Property(e=>e.Quantity).IsRequired();
}
do the same? Meaning is this causing somehow dynamically adding [Required] attribute to a property so <input> tag helper can notice it?
"Meaning is this causing somehow dynamically adding [Required]
attribute to a property so tag helper can notice it?"
Yes, exactly it is. IsRequired and the [Required] will eventually have the same impact on database schema as it will add a non-nullable constrain on the table column. Means the property would be mandatory. The key difference is we only can use fluent API validation code first's approach while [Required] all approach.
In fact, while using e.Property(e=>e.Quantity).IsRequired() attribute fluent API instead of annotations to get the same client side & server side validation. Rather than use Required. The thing is validation errors thrown based on the Fluent API configurations will not automatically reach the UI, but you can capture it in code and then respond to it accordingly.In addition, you can check the official document here
Both validators are no real validators, rather they can change an attribute value. If such pseudo validators are used in model rules, do they have any effect on other real validators?
For example, when a default and a required validator are used for the same attribute, will the required validator never fail?
Or are there any precedences with such validators? Or is the order of the validation rules crucial?
The pseudo validators alter the values of attributes. Thus any subsequent validators on the same attributes will validate against the altered values.
The order is crucial. The validators are created from rules() using \yii\base\Model::createValidators() in the order they appear in rules().
For your specific example, when the required rule is first, validating against it will return false. However, when the default rule is first, the attribute already has a set value thus the validation for required will return true.
We use the Grails scaffolding for our internal part of our web app. Now we have the requirement to modify some values in the before validate method. The Problem is, that these fields are blank: false or nullable: true
It's no problem to modify these values in the beforeValidate method, but the problem is, that the scaffolding adds a required attribute to the html form, and so we can't submit it with these empty fields.
Is there a way to disable the scaffolding validation on a specific view for a specific class?
Greetings
The short answer is "No, there isn't a way to turn of validation for a specific domain class in scaffolding."
However, you can always generate the views for the domain class and edit the GSPs to remove the required attributes on the fields in question.
grails generate-views com.somewhere.MyDomainClass
Scaffolding is to get you a starting point to work from, not continued use and customization.
As far as I understand a callback is a constraint that you can customise and set to any field for any type of validation.
A custom validation constraint overrides the base constraint class (creating any type of validation on any field)
I'm just not sure what the difference is, why would I use one and not the other?
Are there any performance differences too?
I haven't researched the Form Component that much to be aware of any performance differences, but besides that, why you should choose one over the other:
Callbacks
It is meant to customize the whole validation process, not just the Constraint. For instance, you can set where the error needs to be displayed;
The target is always a class, you can't use it on a property;
You can't reuse it, it is only available on that class/entity.
Custom Validator Constraints
You can reuse it everywhere (as said by #MrGlass, you can even use services as constraint);
It can be used on a class and property target;
You can only customize when something fails, not what is done after it fails.
As part of our ASP.NET MVC3 project, we have implemented some custom validation. On a particular entity e.g. UniqueMandatoryCode, we have got [Required] and our [CustomValidationDataAnnotation].
They both work but I would like to know what is happening under the hood in terms of the order of execution for validation. The issue I have is that our CustomValidation code is hit before the [Required] validation. This poses problems when we pass empty values.
So the question is, how do I control the order of validation i.e. first go through the [Required] validation and then the [CustomValidationDataAnnotation] validation.
I guess the validation order cannot be easily controlled.
The common technique is to ignore the empty/unspecified case in all other validators (ignore = you treat it as valid). You will anyway add a required validator if the value is mandatory that will handle that case. If the value is optional, why would you apply the custom validation rule on an empty/unspecified value?