[Bug] ISO8601 dates and WebAPI break Scheduler

[David]

As far as I can tell, newer versions of WebAPI return ISO8601 dates instead of the traditional Microsoft format that was /Date(  )/.

The rendering script has the value of "g" being null when attempting to parse the date and the appointments never bind and the Scheduler breaks with the exception shown in the Locals list in my screenshot. I would hate to have to revert back to using the old format.

Any work around for this?

[David]

For reference, the functionality that is erroring out has the following comment above it

/* START Telerik.Web.UI.Scheduler.ClientRendering.RenderingManager.js */

[Boyan Dimitrov]

Hello,

Could you please clarify whether you are facing any problems with the attached project? If yes please explain what exactly you want to achieve. Please test with our Telerik dll for .NET 4.5. I would suggest using our latest release 2014.2.724.45.

Regards,
Boyan Dimitrov
Telerik

 

 

[David]

Currently we are using 2013.2.717.40, and the only code I have set up at the moment matches what is in the SchedulerController provided in the sample

[HttpGet]
public IEnumerable<AppointmentData> GetAppointments(string schedulerInfo)
{
    return Controller.GetAppointments(JavaScriptSerializer.Deserialize<MySchedulerInfo>(schedulerInfo));
}

[HttpGet]
public IEnumerable<ResourceData> GetResources(string schedulerInfo)
{
    var o = new JavaScriptSerializer().Deserialize<MySchedulerInfo>(schedulerInfo);
    return Controller.GetResources(o);
}

All I'm trying to do at the moment is fetch appointments via webservice and nothing else. At this time it is not possible to update to the latest version in the application we are using, however that sample does work correctly.

If you can, try to run that sample with the version I specified and see if you experience the same scripting error I have run into.

[Boyan Dimitrov]

Hello,

Please find attached a sample web site that shows how to populate the RadScheduler via web service.


Regards,
Boyan Dimitrov
Telerik

 

 

[David]

Okay this is all well and good, but I'm communicating with WebAPI specifically and not a WCF service like the sample shows.

The newest versions of WebAPI spit back dates in a format such as this

2014-09-25T07:07:31Z

meanwhile the Scheduler when parsing a date from a webservice, is looking for the obsolete Date format of

/Date(1325754000000)/

The Scheduler control doesn't work with WebAPI. I don't want to write a custom parser that will take the newer (and standard format) and convert it backwards to the older .NET format.

Telerik has claimed that WebAPI is supported since 2013.2.717 and as far as I can tell, it isn't.

[Boyan Dimitrov]

Hello,

Indeed there was a problem with Web API scenario and date parsing in version 2013.2.717.45. It seems that this is fixed in 2013.3.1114.45 version which is 2013 Q3 SP1.

I tested the Web API scenario with 2013.3.1114.45 version and the RadScheduler does parse ISO 8601 data format, which is the default serialization format of Json.Net serializer.

I would like to apologize for any inconveniences caused.

Regards,
Boyan Dimitrov
Telerik

 

 

[David]

After updating to the latest version of the RadAjax controls, I notice that the WebAPI binding works correctly. However, I realize there isn't very much documentation on doing things like managing custom resources and custom appointment templates.

I'd like to see some examples of how to bind custom resources to the AdvancedEdit/InsertForm and customize the appointment template bound to the Scheduler.

Right now I have some extra information on every appointment that is shown, and I have 3 custom resources that are single value only (render out as RadComboBox)

[Boyan Dimitrov]

Hello,

Thank you for your feedback.

I would suggest reviewing the documentation for the web service scenario. The specifics between Web API and the web service is actually configuring the web API controller and  communication between the controller and the scheduler. The use of resources and templates are same with the web service scenario.


Regards,
Boyan Dimitrov
Telerik