We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. (Last updated on: November 16, 2018).
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Looks easy, but breaks even more easily

Thread ID:





129055 Feb 23,2017 03:29 PM UTC Mar 3,2017 01:01 PM UTC JavaScript 3
Tags: ejSchedule
Asked On February 23, 2017 03:29 PM UTC


I like your components, but sometimes its too easy to break. I modified an example to demonstrate this.

Select for answer:
On line 43 I changed an lower case o to upporcase O

Now, if a trivial example breaks down so easily with a minor bug, its very hard to make actual use of the component.

How can we migitate this?

I'm using .NET & typescript to catch the most errors with compilers and development tools, but these things still slip trough. Even when using the MVC components its still dependent on magic strings.

Karthigeyan Krishnamurthi [Syncfusion]
Replied On February 24, 2017 10:18 AM UTC

Hi Wouter, 
Thank you for contacting Syncfusion support. 
We would like to inform you that resource fields mapping is case sensitive and it is mandatory to map the correct field name in-order to display an appointment in resource sample. 
Please let us know if you need further assistance. 

Replied On March 2, 2017 11:38 AM UTC

Yeah, I know its case sensitive. But if you make one type the error is really obscure. That makes for a bad developer experience. If the component would have some more checks and display the result in the console this would be much improved. In this case it would be really helpful if it said: "you provided xxx but based on the data only Xxxx and Yyyyy are available".

Karthigeyan Krishnamurthi [Syncfusion]
Replied On March 3, 2017 01:01 PM UTC

Hi Wouter,  
Thanks for your update. 
We regret to inform that it is not possible to process the mentioned validation (checking with cases) within our source to display the error message, and also as per the standard - the database fields need to be mapped correctly with proper Scheduler fields name (as per the casing standards). Moving such kind of validation for each record at source side will lead to the lack of performance. 
Please let us know, if you need any further assistance. 


This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Please sign in to access our forum

This page will automatically be redirected to the sign-in page in 10 seconds.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon