+1 > but if the Ajax request > fails (which I assume happened in your case), I don't think any feedback is > displayed to the page. Perhaps we should correct that -- first check the > response of the Ajax request, and only remove the row from the grid if it > was successful, otherwise flash an error message.
In fact, I go one step further. I have the callback function in the controller rebuild the entire list table and update it via returned javascript. Maybe not appropriate for all situations, as these list tables usually contain < 10 items and are just as likely to have items added as deleted. On Feb 8, 9:14 am, Anthony <abasta...@gmail.com> wrote: > On Wednesday, February 8, 2012 2:16:21 AM UTC-5, Mark Kirkwood wrote: > > > Sorry, I was not being all that clear. What I meant to say was: > > > When I try to delete such a record, instead of the form telling me that > > the delete was prevented it appears to have succeeded. However a refresh of > > the form shows the record survived (and obviously the database log tells us > > why)! > > Forms don't know about database constraints -- they will only return and > display friendly errors if a validator or onvalidation fails (that's why, > for example, if you have notnull=True, you still need an IS_NOT_EMPTY() > validator for the form to check for an empty field before submission). In > your case, were you doing the delete from an edit form or from the grid > itself (via the delete button)? If the latter, what happens is that the row > is immediately removed from the grid via Javascript, and then an Ajax > request is sent to delete the record from the db -- but if the Ajax request > fails (which I assume happened in your case), I don't think any feedback is > displayed to the page. Perhaps we should correct that -- first check the > response of the Ajax request, and only remove the row from the grid if it > was successful, otherwise flash an error message. > > Anthony
