Say I have an event handler function defined for a grid's beforeEdit event:
deferredpromise = doSomethingAsync(e.sender, e.model);
// we'll return back here immediately, while whatever async stuff we started is still executing
// and we'll return to Kendo from here before it is done
The problem I'm trying to solve is others making changes being made to the underlying remote database on records being displayed in the grid. If "myAttribute" starts out as "123" when the page is loaded, then someone else somehow modifies that to "456", if the first person edits the record to change something else, the stale "123" value will be sent out and used in the update. I was going to have the beforeEdit handler retrieve the data for the row being edited from the remote server, compare it to the dataRec, and update any stale fields, but I run into the async problem described above.
I don't know if this might sort-of-work anyway - the async handler would use the model's set() method, and perhaps the editor window would visually refresh any elements that get modified by the async handler behind its back after the binding is done and the window is up? Even then, there would be potential timing issues with the user and UI.
I just wanted to see if I was missing something obvious on waiting on the async to complete before returning from beforeEdit. The alternative we are looking at would be to add modification timestamps to the database tables involved, and if an update come in from Kendo and the stamps in the payload don't match the database record, the update would be rejected. Aside from not wanting to monkey with our existing database schema unless absolutely necessary, it would require the user to re-enter their edits after a refresh.