I was looking at the latest internal build (808), and it looked like you guys implemented RequestEnd on the DataSource, which is going to solve a number of problems I'm having in my app. So I set up the following code:
floorPlanDataSource = $(
The problem is, this event appears to only fire on the first read. My grid is using a remote datasource in batch mode, and the event does not fire when I add, update, or delete a row (with the built-in toolbar buttons), nor does it fire when I hit the built-in refresh button in the footer.
Digging through the code, it appears the event is wired into the sync, success, and error functions... but the only place the success function appears to be wired into is the Read function on the RemoteTransport class. If you look at the create, update, and destroy methods on RemoteTransport, you'll see they don't appear to leverage the success or error functions at all... at least, not the way you would expect.
It seems to me that an easier implementation of all of this would be to modify the Transports to start the CRUD methods by throwing the requestStart event, then passing in wrapped success and error functions that work similarly to the existing read method, where requestEnd is thrown before the passed in success or error handler is executed.
Then, the dataSource would handle these events from the Transport, and re-throw them back down to the implementer.
So 1) is the feature in its current state considered complete?
2) Did I hit a bug or am I doing something wrong?
3) Does my explanation of a "better" approach make sense?
I was doing something wrong. Mental note: Next time, test new Kendo feature on page with one Grid, not seven. I pasted in the wrong GridID, to the bind function, so I was testing the results in a different grid than the one that was wired up. My bad.