Can't get events to show

[Jesse]

I'm using the scheduler for the first time but can't get the events to show up. I've followed the demos as closely as possible and I can see that 108 events are being returned to the AJAX read call to my web api method but can't figure out why they're not displaying. The calendar just remains empty with no javascript errors. I've read this can happen if the field mappings are incorrect, but I've done what the demos do.

[Jesse]

I found the problem. I downloaded the source JS and stepped through the read code and found that my data was getting lost in following function:

function wrapDataAccess(originalFunction, timezone) {
    return function (data) {
        data = originalFunction(data);
        convertData(data, 'apply', timezone);
        return data || [];
    };
}

 

on the first line where it calls originalFunction(data), it sends my 108 items in and returns undefined. I stepped into that a few layers deep and found an anonymous function returning d.Data where d was my data (a DataSourceResult) but my object had a .data property not a .Data property.

It turns out this is because of a custom json formatter configured in my global.asax. We are using the Newtonsoft CamelCasePropertyNamesContractResolver:

config.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver(); //Persist camel cased properties in JSON serialization

 

This is causing the casing of the first character of the property names to change. To solve it, I updated my web api method to explicitly serialize the DataSourceResult using the default resolver like so:

return Json(scheduleVM.ToDataSourceResult(request), new JsonSerializerSettings { ContractResolver = new DefaultContractResolver() });

 

[Dimitar]

Hello Jesse,

I am glad to hear that you have managed to successfully resolve the issue. I believe the provided solution will be helpful for other users that struggle with a similar issue.

You could also track the following GitHub issue, which is also affecting your scenario. After it is successfully resolved, there will be no need to explicitly configure the serializer settings.

Regards,
Dimitar
Progress Telerik

[Jesse]

Thanks, Dimitar. I'm not using ASP.NET Core but that is a good resource to have cited here. In MVC 5, a DefaultContractResolver is used by default but we changed ours to a CamelCasePropertyNamesContractResolver globally. I suspect if we did the equivalent in ASP.NET Core, a DefaultContractResolver would still have to be used to override that at the method level like above.

 

For everyone's information, I ended up ditching the Web API and moving the read action to a controller. This is what that looks like too since the MVC Controller JSON method doesn't accept a JsonSerializerSettings parameter:

return Content(JsonConvert.SerializeObject(scheduleVM.ToDataSourceResult(request), new JsonSerializerSettings { ContractResolver = new DefaultContractResolver(), Formatting = Formatting.None }), "application/json");