How to Not update the schedulers appointments on the UI if there is an error in my backend code

[towpse]

When I create, update or delete an appointment and my code fails for whatever reason (debgging, testing etc), the UI will still look like the appointment was added and currently exists or was changed successfully until i refresh the page which of course reloads what i actually have in the DB.

Is there a standard way of not updating the UI on a failure?
The issue seems to be that the appointment is added to the control immediately before the call to my code actually creates or updates or whatever.

I've currently been using this to refresh the UI as a temp way to refresh

//temp way to rebind scheduler on the client
function refreshSchedulerClientSide() {
    var scheduler = $find('RadScheduler1');
    scheduler.set_selectedDate(scheduler.get_selectedDate());
}

I could just call this on failure?

any tips?

thanks

[Peter]

Hi towps,

I can handle the AppointmentInsert, AppointmentUpdate and AppointmentDelete server events and cancel them if needed. For example -

protected void RadScheduler1_AppointmentInsert(object sender, SchedulerCancelEventArgs e)
  {
             e.Cancel = true;
  }

Greetings,
Peter
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[towpse]

okay, right that works

okay based on your response I found the two events OnClientRequestSuccess and Failed.
I guess on Failed I could always set cancel to true!

That should do it. Thanks.

[Roatin Marth]

I just recently started working with the scheduler. I'm working with the web service approach.
I've handled the OnClientRequestFailed event in which I show an alert and set cancel to true.
Say I was inserting an appointment and an error occurred in my backend somewhere, set cancel true is invoked but I still see the new appointment on the scheduler UI.
If I force a refresh to force the scheduler to call GetAppointments, of course the UI is cleaned up.

Is this how you would expect us to handle this event?

I've also tried to transactionalize this entire flow. I've had to do it from the web service level just because I cannot be certain what the telerik web appointment controller is doing before it gets to my provider (creating an exception for example calls an update then an insert).

I'm finding that some backend errors, such as transaction errors, will not get picked up by the OnClientRequestFailed event and therefore my alert is never seen and my force refresh never invoked. Seems very inconsistent that I cannot rely on this event.
It seems the scheduler is handling some exceptions in a different way and showing it's own alerts and not allowing me to handle the error as I see fit.

Any ideas?

[T. Tsonev]

Hello Roatin,

You're handling the OnClientRequestFailed event correctly. You still need to refresh the appointments in order to recover from the error. This is a very simple error notification implementation and we plan to implement automatic retry in future versions, so the control can recover from the most common problems (network timeouts) automatically.

Error information is transferred to the client only when a server exception occurs. Your code either has to throw one or you need to use the extended response format in order to notify the client instance of the problem. Look here for more information:
http://www.telerik.com/help/aspnet-ajax/returning_extra_data.html

I hope this helps.

Sincerely yours,
Tsvetomir Tsonev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[Roatin Marth]

All my code properly catches, logs errors and then throws the exception up.
If i throw from the web level, either from the web service itself or the provider, i seem to be able to handle things on my own in the OnClientRequestFailed event, show a message and force a refresh.

If the error is thrown from a business layer or data layer, even though i throw the exception up the same as before except from a deeper level, i don't seem to get a chance to handel the error in the request failed event.
Something else is intercepting it first somewhere.

Your link maybe helpful but I'm saying that, after settign a breakpoint in that event, for many exeptions that breakpoint is never hit.

Are you saying to catch an exception and set a code property in that SchedulerResult object to an error code and not throw an error but rather check the code in the client success method?



thanks

[T. Tsonev]

Hello Roatin,

Yes, that exactly what I mean - to use the extended result to inform the client code of any problems that have occurred on the server. This can make it easier to distinguish between different critical and non-critical conditions. But you'll still have to detect such errors in the business / data layers.

Kind regards,
Tsvetomir Tsonev
the Telerik team

Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Follow the status of features or bugs in PITS and vote for them to affect their priority.

[Roatin Marth]

Thanks for the response Tvestsomir.
I'm currently attempting to handle both the request success and failed. I was thinking that if I handled both, after each web service call I would be bound to hit either the request or success handler.
I seem to be wrong. Even if nothing goes wrong (presumably), with my current setup I am not able to detect a request fail or success.

OnClientRequestFailed="ClientRequestFailed"

OnClientRequestSuccess="ClientRequestSuccess" function ClientRequestFailed(sender, eventArgs) {     debugger;     //cancel UI updates if the web service failed.     alert('Server request failed.');     refreshSchedulerClientSide();     unspin();     set_cancel(true); } function ClientRequestSuccess(sender, eventArgs) {     debugger;     alert('Success');     refreshSchedulerClientSide();     unspin(); }

I'm not hitting those breakpoints at all. You'd think the success case would get hit in most all cases.

Also I have a new  use case where I am calling the updateAppointment method on the scheduler explicitly; that is not through the framework.

If I try the following

    var scheduler = $find('RadScheduler1');
    scheduler.updateAppointment(selectedAppointment, 1,
    //on success
                function(r) {
                    selectedAppointment.set_backColor(new);
                },
    //on fail
                function(r) {
                    alert('disable fail!');
                    selectedAppointment.set_backColor(original); //reset back colour
                }

It doesn't look like the on fail executes if there is an exception thrown somewhere in my backend. Again neither of the request success or fail get hit as well.

regards,
Roatin

[T. Tsonev]

Hello Roatin,

Both events fire in my test project and exceptions result in requestFailed. Are you sure there are no JavaScript errors? Can you please capture the network traffic using FiddlerCap, so we can take a look at it?

The second syntax is not supported, events must be attached as in the first example.

Regards,
Tsvetomir Tsonev
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.