I have a kendo grid using a popup editor that does a create/delete, both of them ending with errors.
I would like to handle both errors
1. When having an error on delete to prevent the row deleting from the grid
2. When having a create error to prevent the popup editor to close
Please see this fiddle:
The second point works by default (so having an error on create does not close the popup)
The first point works by adding the error function and cancelingChanges
, but adding that that breaks the popup (it now closes on error).
So I can have either one of my requirements, but not both in the same time.
I am kind of stuck.
I saw this 2 questions on kendo forums:
But as you can see in the fiddle I can't make it both work on the same time
Thank you for your help
10 Answers, 1 is accepted
I suggest you to use an if condition in the error event handler to determine which of the two workarounds should be executed.
In this case the server should provide information about type of the error that occurred. You can retrieve the error status from error event arguments.
The error message is generated from the server. The server should include all the needed information about type of the error and which actions caused it.
You may use the parameterMap of the DataSource transport to add additional parameters to the request data or to set a ModelState error on the server that provides more information.
My issue is that I can't find a way to tell which client operation led to the error. If they were deleting a row then I want to cancel changes and redisplay the row. But if they were updating or inserting, then I don't want to cancel the changes, giving them the opportunity of correcting the data. I can't even parse the error message (not that this is a good idea anyway), since the error I am handling here could occur as the result of either a delete or an insert.
I'm hoping that I've missed something and there's a property in the error event that will give me the information I need!
I am afraid that there isn't a parameter in the error event argument that indicates which action has failed. A possible approach that I can suggest if the type cannot be returned in the errors from the server, is to use the requestStart event to save the last request type and use the saved value in the error event: