I am new to the UltraWebGrid and find it generally very nice to work with. However, in planning how to use it in our business, I am left hanging on one issue. Using a SQLDataSource and by just setting a couple of properties, the grid works great, and every time an edit is made and the user changes grid rows, it silently posts the edit to the database. The good news is that this goes 90% of the way of insuring that edits are committed to the db without the user having to click a save button. But I am looking for how to handle situations where a user edits his/her final record and then closes the form without having selected another row.
Infragistics support informed me that this is the way the webgrid is supposed to work and that I have to teach users to always change rows after making a change. But in terms of customer experience, this seems to beg frustration among users who did not listen or simply forgot (either to change rows or to click a save button) and so their final edits were lost.
So is there a way (hopefully with a simple example) on how to use the BeforeUnload event to (a) determine if there is a lingering edit that was not updated to the database (which should be limited to the last/current row), and (b) how to force that last/current row to be updated if changes are pending?
Thanks for any ideas.
For tips on how to use JavaScript before the page unloads
http://www.google.com/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=prevent+leaving+web+page&spell=1
Now for the WebGrid specific influence:
I have not tried these and they are only offered as idea starters (and its going to be pretty stream of consciousness)
From your posting it seems to me that you are using AJAX callbacks.
One idea you could try is to have a javascript form variable (lets call it needsUpdate) In the before cell update event (client event), you set this to true. in your onunload (client) you see if the variable is set and if so then throw up a dialog stating there are unsaved changes. Then you can either force them to hit a save button or change the active row (or maybe you could just set the ActiveRow to null which might send the update automatically).
Now you want to clear this flag if the form is going back to the server to do the update , so maybe in the ActiveRowChanged event you should set the flag back to false (since the grid is going to do the update). You might also want to reset the flag in the AfterXmlHttpResponseProcessed (client side) event, since if you did an ajax request the update should have went through too.
Again, I haven't tried these, but just throwing them out as ideas that could be tried.
I would use the batch update event handlers to do all the saving at once. This will eliminate the once-per-row postbacks, and it is really very simple to implement.
Define your UpdateRowBatch and DeleteRowBatch handlers, and all your Save button has to do is trigger a postback. The two event handlers need to do pretty much what (I'm assuming) your current UpdateRow and DeleteRow do, and UpdateRowBatch needs to differentiate between inserts and updates.
That's the best solution I can think of.
However, would putting the "Save" button on the form make them assume the form isn't being saved until they click the button? If it were my form (and I certainly don't understand all your needs), I would add the button and then not save until the button is clicked.
Good luck!
I agree. Customers don't take well to having to be trained.
I'd put a "Save" button on you form. Experienced web users are used to that.
(Actually, experienced web users will know you shouldn't just leave a page without saving, and won't be expecting your grid to auto-save anything.)