5 Answers, 1 is accepted
In order for the Date and numeric values to be parsed correctly we recommend using matching cultures on the client and server. Please examine the article below that describes the approach in more detail.
Regards,
Viktor Tachev
Progress Telerik

My first impression is that such coupling would be wrong pratice.
For example in my case I don't call an MVC action but post data to a web api which expect culture-neutral data. I'll check if specifying a culture per request is a standard REST specification.
An alternative approach would be to intercept the values before sending them to the server. This way the date can be converted to the required format.
Regards,
Viktor Tachev
Progress Telerik

We're also currently facing the same problem. We would rather not change cultures in the backend if at all avoidable (UiCulture is fine though), because we do a lot of calculation in the backend and it does lead to some serious problem in our current solution if we just change the culture in the .net solution (and it extends to our database in some cases). I also personally believe it's wrong to have the thread culture set to anything other than en-US, because that would also make it harder to talk to external apis from c# as it also seems to affect the default outcome of every conversion method. And it even expects commas instead of dots for JSON numbers, witch I think it's technically invalid JSON to even have a number be formatted that way.
Our solution so far is to be building our own serialize to be used in place of jqueries serialize function as a jquery extension.
(
function
($) {
$.fn.serializeJSON =
function
() {
let map = {};
$(
this
).find(
":input"
).each(
function
() {
let name = $(
this
).attr(
'name'
);
let role = $(
this
).attr(
'data-role'
);
if
(
typeof
name !==
typeof
undefined && name !==
false
) {
switch
(role) {
case
"numerictextbox"
:
map[name] = $(
this
).data(
'kendoNumericTextBox'
).value();
break
;
default
:
map[name] = $(
this
).val();
break
;
}
}
});
return
JSON.stringify(map);
};
}(jQuery));
We also would have to do that for all the rest of the kendo widgets we might use and want to serialize that contain numeric values. We don't current intend to do that for dates as we use the same format for every language, but that might change eventually.
I'm not sure if checking the data-role attribute is the right approach here though. Is there a way to make sure it's actually a kendo widget. And not something else. Basically, is it possible to check for kendoNumericTextBox somehow?
---
And yet another problem is when using asp.net html helper functions. It will also in case of numerictextbox render the value into the input tag before the javascript code is executed to initialize the rest of the widget and the widget then will convert 6.5 with en-EN culture set correctly, but in case of de-DE it will see the 6.5 and convert it to 65. Is there a way to solve that as well? We are currently setting culture on top of the razor html page. We do that for every single page individually as we cannot do it in the layout files, because we don't always reload the page when we load new HTML into the view and as soon as a controller is called the language will be back to en-US. So the current solution is not very convenient and I'd imagine it could also fail as soon as the razor helpers c# code tries to fetch a datasource from a controller. Although, I didn't encounter this issue yet.
You can use the data-role attribute to get reference of the NumericTextBox widget. If you would like to ensure that the reference is indeed a Kendo widget you can use an approach similar to this:
switch
(role) {
case
"numerictextbox"
:
let numeric = $(
this
).data(
'kendoNumericTextBox'
);
let isKendoNumericTextBox = numeric
instanceof
kendo.ui.NumericTextBox;
if
(isKendoNumericTextBox) {
map[name] = numeric.value();
}
break
;
default
:
map[name] = $(
this
).val();
break
;
}
Regarding your other query. The value of the NumericTextBox is serialized based on the culture. When using German culture the decimal separator is comma and the dot in the value is ignored. This is why the value is different. There are two issues in the GitHub repository that discuss the behavior. Check them out below:
- https://github.com/telerik/kendo-ui-core/issues/2788
- https://github.com/telerik/kendo-ui-core/issues/2970
Regards,
Viktor Tachev
Progress Telerik