I'm sorry, but I can't agree with you about the consistency. I'm aware that the onvalidation is called after the validation. The inconsistency is why is it sometimes called when the delete checkbox is selected and not in others? If the assumption is that it has nothing to do with deletion, then it should never be called if the delete checkbox is selected. Which is not the case.
There is a way to distinguish an edit from a delete from within onvalidation. I use if form.vars.delete_this_record: and it works. I agree with your 1st case. On the 2nd case, I must correct you that ondelete is run before the delete happens. I use it to mark the record inactive and stop the deletion, when the user "deletes" the record from the grid itself. There is case I mentioned and that you didn't consider which is before the delete, doing something that doesn't require a separate workflow, which is exactly my problem. I just want to mark the record inactive. From the 5 scenarios I explained, all of which originate from the grid's edit form, 3 go to onvalidation (and are deleting the record) and 2 don't. Again, this is an inconsistency. Thanks for the explanation about the arguments. I tried with if SQLFORM.FIELDNAME_REQUEST_DELETE in request.post_vars: and this catches the missing cases. But I must say it is a ugly solution. My point being that all the validation and checking is usually done in the onvalidation, ondelete, etc. And this to work must be at the top of the action instead of in one of the on* functions. It works, but IMO is not a pretty solution. quinta-feira, 11 de Abril de 2019 às 15:50:55 UTC+1, Anthony escreveu: > > On Thursday, April 11, 2019 at 7:52:18 AM UTC-4, João Matos wrote: >> >> Thanks for the explanations. >> >> You don't understand. I don't care if the changes made at the same time >> the deleted checkbox is selected, are saved when submitting. That is not >> the problem. >> It is a question of consistency. >> >> Either web2py should call on_validation when the delete checkbox is >> selected or not. What happens now is that in some scenarios it is called >> but not in others. >> My opinion is that it should always be called, but above all, it should >> be consistent. >> > > The "onvalidation" function is supposed to be called "upon validation" > (hence the name), meaning after a successful validation of the submitted > field values. It is not intended to be run in order to make checks before > or after deletion of a record. In other words, onvalidation runs when > particular conditions are met, and it does so *consistently*. It just so > happens that you want to run it under different conditions, which is not > its intended purpose. Even if it did run when you want, you would still > need a way to distinguish a regular update request from a delete request, > and you can do that just as easily outside of the onvalidation function > (see below). > > I think there are three types of cases to handle regarding deletes: > > First, you might want to simply allow/disallow a delete, and that case is > handled by the "deletable" argument. > > Second, you might want to run some code *after* a successful delete. The > grid has an "ondelete" argument to handle that in case the "Delete" button > is clicked, but nothing for the case when a delete happens via an edit > form. However, this can be handled in all cases via the > db.mytable._after_delete callback. In any case, the onvalidation function > would not be the best place for this logic as it (a) runs *before *the > delete happens, and (b) would still require some logic to determine that a > delete was requested. It might be nice if SQLFORM had a separate "ondelete" > argument of its own. > > Finally, you might want to allow the user to request a delete and then > kick off a separate workflow, such as requiring a special password. > However, that is really a special case that is application specific, and it > is not even well accommodated by the current UI (i.e., it would be a better > user experience to request the special password up front rather than making > it a two step process). If you need something like that, you should really > be implementing custom logic. And again, the onvalidation function is not > the best place for such logic, as it would still require detection of the > delete request. > > As an aside, note that the "onvalidation" argument can actually be a > dictionary with separate "onsuccess", "onfailure", and "onchange" > callbacks. The grid also has "onupdate" (run after successful update) and > "onfailure" (run after failed update) arguments, as well as the "ondelete" > argument. Some combination of these callbacks could be used to run some > code whenever a delete is requested, though it is probably simpler to just > do a check like the following before calling grid(): > > if SQLFORM.FIELDNAME_REQUEST_DELETE in request.post_vars or 'delete' in > request.args: > [code to handle delete workflow] > > Anthony > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
