I would like use data annotations to handle validation in my Silverlight app. The built-in validation attributes (primarily StringLength and Required) are great, and make life very easy. However, they seem to have one critical flaw. If my locale is set to fr-CA, for example, the validation exceptions are still in English - 'The Name field is required', 'The field Name must be a string with a maximum length of 20', etc.
This is a major problem. It means that if I want localized error messages for the built-in validation attributes, I have to manually add ErrorMessage/ErrorMessageResourceType to every validation attribute on every validatable property in my business layer, and manually add translated strings for every error message.
So... am I missing something here? Is there a way to automatically have the built-in validation attributes localized? Or some other easier way of doing this? Or am I just completely out of luck, and stuck with the manual route?
Any comments or thoughts would be appreciated.
Ok, I got around this by simply subclassing the built-in validation attributes. Problem solved!
internal class LocalizedStringLengthAttribute : StringLengthAttribute
{
public LocalizedStringLengthAttribute(int maximumLength)
: base(maximumLength)
{
}
public override string FormatErrorMessage(string name)
{
return String.Format(CultureInfo.CurrentUICulture, LanguageResources.Resource.Error_StringLength, name, MaximumLength);
}
}
Related
Data validation should occur at the following places in a web-application:
Client-side: browser. To speed up user error reporting
Server-side: controller. To check if user input is syntactically valid (no sql injections, for example, valid format for all passed in fields, all required fields are filled in etc.)
Server-side: model (domain layer). To check if user input is domain-wise valid (no duplicating usernames, account balance is not negative etc.)
I am currently a DDD fan, so I have UI and Domain layers separated in my applications.
I am also trying to follow the rule, that domain model should never contain an invalid data.
So, how do you design validation mechanism in your application so that validation errors, that take place in the domain, propagate properly to the client? For example, when domain model raises an exception about duplicate username, how to correctly bind that exception to the submitted form?
Some article, that inspired this question, can be found here: http://verraes.net/2015/02/form-command-model-validation/
I've seen no such mechanisms in web frameworks known to me. What first springs into my mind is to make domain model include the name of the field, causing exception, in the exception data and then in the UI layer provide a map between form data fields and model data fields to properly show the error in it's context for a user. Is this approach valid? It looks shaky... Are there some examples of better design?
Although not exactly the same question as this one, I think the answer is the same:
Encapsulate the validation logic into a reusable class. These classes are usually called specifications, validators or rules and are part of the domain.
Now you can use these specifications in both the model and the service layer.
If your UI uses the same technology as the model, you may also be able to use the specifications there (e.g. when using NodeJS on the server, you're able to write the specs in JS and use them in the browser, too).
Edit - additional information after the chat
Create fine-grained specifications, so that you are able to display appropriate error messages if a spec fails.
Don't make business rules or specifications aware of form fields.
Only create specs for business rules, not for basic input validation tasks (e.g. checking for null).
I want to share the approach used by us in one DDD project.
We created a BaseClass having fields ErrorId &
ErrorMessage.
Every DomainModel derive from this BaseClass & thus have a two extra fields ErrorId & ErrorMessage available from
BaseClass.
Whenever exception occurs we handle exception(Log in server, take appropriate steps for compensating logic & fetch User Friendly message from client location based localized Resource file for message ) then propagate data as simple flow without raising or throwing exception.
At client side check if ErrorMessage is not null then show error.
It's basic simple approach we followed from start of project.
If it's new project this is least complicated & efficient approach, but if you doing changes in big old project this might not help as changes are big.
For validation at each field level, use Validation Application Block from Enterprise Library.
It can be used as :
Decorate domain model properties with proper attributes like:
public class AttributeCustomer
{
[NotNullValidator(MessageTemplate = "Customer must have valid no")]
[StringLengthValidator(5, RangeBoundaryType.Inclusive,
5, RangeBoundaryType.Inclusive,
MessageTemplate = "Customer no must have {3} characters.")]
[RegexValidator("[A-Z]{2}[0-9]{3}",
MessageTemplate = "Customer no must be 2 capital letters and 3 numbers.")]
public string CustomerNo { get; set; }
}
Create validator instance like:
Validator<AttributeCustomer> cusValidator =
valFactory.CreateValidator<AttributeCustomer>();
Use object & do validation as :
customer.CustomerNo = "AB123";
customer.FirstName = "Brown";
customer.LastName = "Green";
customer.BirthDate = "1980-01-01";
customer.CustomerType = "VIP";
ValidationResults valResults = cusValidator.Validate(customer);
Check Validation results as:
if (valResults.IsValid)
{
MessageBox.Show("Customer information is valid");
}
else
{
foreach (ValidationResult item in valResults)
{
// Put your validation detection logic
}
}
Code example is taken from Microsoft Enterprise Library 5.0 - Introduction to Validation Block
This links will help to understand Validation Application Block:
http://www.codeproject.com/Articles/256355/Microsoft-Enterprise-Library-Introduction-to-V
https://msdn.microsoft.com/en-in/library/ff650131.aspx
https://msdn.microsoft.com/library/cc467894.aspx
I want to use custom error messages for validation constraints on dozens of fields in my project.
I do not want to set the message on every one of these, because that would be a blatant violation of DRY. Repeating the same string in every declaration like: #NotNull(message="custom msg") would mean that if I decide to change the message in the future I'd have to hunt them all down replace them, but even worse I might use the wrong string on some of them and be inconsistent.
How do you deal with this?
Is the best option really to extend every symfony stock constraint and set my default there, and use my own custom annotation class?
Please note that using the translator is not an option for me, so I am looking for a solution that does not include the symfony translation component.
Thanks a lot for the help in advance.
Assuming you are working with English as the app's language, and you've configured translator: { fallback: en }, you can override these constraint messages universally. Start by creating this file: app/Resources/translations/validators.en.yml
And use the following translation format:
This value should not be blank.: Your custom message here
Whatever the standard message is.: Another custom message
This also works for any other language setting, assuming you've made a validators.lang.yml for it!
You can also place this file in your bundle directory under Resources/translations, and a few other places.
You can read more about this here!
Gah.. I have spent way to long on this, but I believe I have found the problem.
Essentially I have a hidden field which is populated when a user clicks on an image.
It is required that the user has clicked the image but I do not want the generic form error message for a 'required' check with the CI form validation class.
As such I quickly made a image_required function in my extended form validation class, and set a rule such that this rule was applied to the hidden field.
function image_required($str)
{
$CI =& get_instance();
$CI->form_validation->set_message('image_required','Please click the image above.');
if($str != '')
{
return TRUE;
}
else
{
return FALSE;
}
}
If the hidden field was blank no error was being called.
I am led to believe now that this is because CI says this field is empty yet it is not 'required', therefore we will ignore all the other validation rules for the field. Is this correct?
If so how can i go about requiring this field be set but having a custom error message?
bangs head
Thanks
If you look at the source code (v2.1.3) for the '_execute' routine (system/libraries/Form_validation.php) you will see on line 486
// If the field is blank, but NOT required, no further tests are necessary
So you are correct, it needs to be required and then it will process your rule.
In order to fix it so you can have a non-required blank field that still processes rules, you should override the '_execute' method by creating a file called 'MY_Form_validation.php' in the application/libraries folder (I think, you might need to check exactly how you extend an existing library) and then copy the '_execute' method and alter the code to continue on a non-required but blank entry.
I do love CI, but I have to say this does not allow the flexibility required. It is perfectly reasonable to have a field that cannot be empty, but is NOT required. As in, you wouldn't enforce "user MUST enter a value", but they cannot submit a blank. I think someone got confused between EMPTY and REQUIRED.
1) REQUIRED: User MUST put a value in the field and it cannot be empty (i.e. '')
2) EMPTY: User does not HAVE to enter a value, BUT, if they do, it's cannot be empty. This not the same as REQUIRED... Looks like I'll be using a callback again.
REQUIRED incorporates two logical steps (1->Must enter a value, and 2->Cannot be empty) these two steps should be separated logically to allow either / or.
In constraint terms it would be either, REQUIRED, NOT NULL. Or NOT REQUIRED, NOT NULL.
I'm early in a project and I've created some basic functionality, including a custom callback validator (validates end date is after start date). I've since started refactoring to enable translation. I've so far had no issues... until I started looking at translating my custom callback validation.
I read a post online that claimed that I could put my translation key value as my error message and Symfony will automatically translate... but this doesn't seem to be the case for me. Can someone tell me how, or provide a link to documentation, to enable translations in my custom validations?
Here's my current validation code with the translation key included:
<?php
namespace CG5\BFG\CoreBundle\Validators;
use Symfony\Component\Validator\ExecutionContext;
class EndDateValidator
{
static public function isEndDateValid($entity, ExecutionContext $context)
{
if ($entity->getEndDate() <= $entity->getStartDate())
$context->addViolationAtSubPath('endDate', 'validation.invalid.enddate', array(), null);
}
}
I got the same problem. Because symfony2 looks in the "validators" Catalogue for those messages, you have to put your custom error message also in that Catalogue. For example under app/Resources/translations/validators.en.yml.
You need to clear the cache for it to work.
I have a model for an ASP.NET MVC view containing several properties:
Subject
Message
Id
While subject and message are required, Id isn't required (it's hidden and only set
for an existing entry). Unfortunately, MVC validates it as required ( The If field
is required) even though I haven't set the Required attribute.
Has someone a solution? Haven't found a solution here, maybe just searching wrong...
Kind regards,
Sascha
If Id is an Int... you can try making it Int? (nullable Int).
If it is nullabe, I think MVC will not validate it.
Another way, would be place a default value in that hidden, lets say a "-1"... and on the controller you can check it.
By default, ASP.Net Mvc will treat non-nullable properties as 'required' - even if you do not add the [Required] attrtibute to the property. If your id is of type int - it is not-nullable and therefore required.
You have basically two options:
Change your Id property to int? - ie a nullable int.
Change the default setting for MVC to not regard non-nullable attributes as required.
Option 1 is straight-forward. For option 2 add the following to the Application_Start method in your global.asax
DataAnnotationsModelValidatorProvider.AddImplicitRequiredAttributeForValueTypes = true;