ASP.NET MVC 3 and the comma in decimals
Jose M. Aguilar
ASP.NET MVP
Currently Jose M. works as an independent consultant and developer, helping companies and institutions reach their goals using software. He also works with company developer teams providing consultancy services and support in several fields. More about Jose M. in his blog in spanish.
If there is something that I think ASP.NET MVC has poorly solved is localization. Even though you can deploy systems fully adapted to different languages and cultures with some patience, the truth is that those of us who have to use the comma in order to separate decimals from whole numbers are complete castaways.
In the past I have explained how to solve this issue for ASP.NET MVC version 2, which used Microsoft Ajax’s scripting library. Nevertheless, version 3 has replaced by default those components with jQuery Validate and the magnificent validation non-intrusive system. So those old posts are good for nothing now 
The problem lies in that the jQuery Validate plugin only uses the dot as decimal separator. Therefore, the validayion in the client of decimal type, float or double that use the comma will always end up as error and impede sending the form.
However, strictly speaking, it’s not an ASP.NET MVC bug, since validation in the client has been completely left up for the jQuery plugin, and this is the one not considering the internationalization. This issue in Github on jQuery Validate suggests its native integration with jQuery Global.
Therefore, I’m afraid it’s an issue with shared implications (and hence, diverse) among the MVC, jQuery Validate, and maybe some other teams. Let’s hope they can put an end to this issue.
At any rate, those of us who are already developing applications with MVC 3 cannot wait for official solutions and we have to find alternatives that allow us to get along the best way possible.
And that’s what this post is about: several possibilities we have so that client validation of decimal values don’t make our lives miserable. I’m sure there are more, and better ones too, but in any case here are a few options that can help us in scenarios like the one described above.
1. Disable client validation
The issue happens in the client, so if we disable the validations and leave the server in charge of checking that the values of the different fields follow the restrictions imposed by its type, and the data annotations, jQuery Validate’s indifference towards cultural specialties won’t affect us.
We can achieve this in several ways:
- disable the client validation globally, setting to false the clientValidationEnabled property in the web.config, which will leave the entire application without validations in the client. This is actually a quite drastic solution but it is possible.
- disable the client validation locally, only in those forms where the decimal type properties exist, introducing the following Razor code (or its corresponding one in ASPX) before the call to BeginForm():
@{
Html.EnableClientValidation(false);
}
- disable the client validation only in those fields in which we want to, which we can do by entering the following script, imagining that the decimal field in which we want to cancel the client validation has “Height” as identifier:
<script type="text/javascript">
$("#Height").removeAttr("data-val");
</script>
Even though we can use any of these three options, the least violent one is the last one since it allows for validations to work except, and the trouble spot fields are ignored.
2. Editing jQuery Validate
This option is a bit hardcore, I found it surfing the web. At least it solves the problem from the root: edit the jQuery Validate code so it accepts commas instead of dots to separate the decimal numbers form the whole ones, both in mumeric validation as well as in ranges.
In Lenard Gunda’s blog you can find in detail how to to perform changes in the jquery.validate.js file (or in its minimized version). However, there are a couple of details you’ll have to consider if you opt for this solution:
- first, we are moving away from the official distribution of the plugin. If we update the jquery.validate library by, for instance, using Nuget, every change made will be lost, and we’ll have to go back and introduce the change s again.
- secondly, this is not going to be useful with apps adapted to several languages; if we edit the plugin for it to accept commas as a separator, it won’t accept the dot again. A fast solution I can think about for this is to have two library versions (original and edited), and reference the appropriate one for the current culture from the page.
3. Edit the way jQuery Validate parses the decimals
Fortunately, the validation plugin for jQuery is very flexible, and it enables us to introduce custom code for numeric format validation and for range checks. This allows us to solve our problem in a very clean way.
The following code could be a first approach to solving the problem. As you can see, we simply introduce in the $.validator.methods.number and the $.validator.methods.range the functions we want to use to validate numbers and ranges respectively, replacing the comma for the dot before performing any conversion with parseFloat():
$.validator.methods.number = function (value, element) {
value = floatValue(value);
return this.optional(element) || !isNaN(value);
}
$.validator.methods.range = function (value, element, param) {
value = floatValue(value);
return this.optional(element) ||
(value >= param[0] && value <= param[1]);
}
function floatValue(value) {
return parseFloat(value.replace(",", "."));
}
If we include this script in the page when the active culture is one that uses the comma to separate decimals, the problem will be solved.
A more universal formula would be editing floatValue() function, and instead of replacing the characters manually, use the Global plugin to perform the conversion to floating according to the current culture. I’ll leave the details of this for another post.
Summing up, as you can see, there are thousands of approaches to this issue. I hope that the ideas explained here are useful for you until we have an official remedy.
Comments