'll check out the db.mytable._before_delete callback. You said " I would probably simply disable the "delete" checkbox in the edit form (via editargs=dict(deletable=False) ), and only allow deletion via the grid buttons (which you can then intercept via the ondelete callback)."
ondelete works but has a drawback (at least I couldn't figure out a solution). It works fine if what we have to do doesn't require a redirection to another page. If it does, it doesn't work. quinta-feira, 11 de Abril de 2019 às 18:48:07 UTC+1, Anthony escreveu: > > On Thursday, April 11, 2019 at 11:33:16 AM UTC-4, João Matos wrote: >> >> 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. >> > > I agree it should never be called on deletion, but if it worked that way, > it would make no difference for your use case. (As an aside, the reason the > validation process proceeds even on deletion is likely due to the fact that > SQLFORM is implemented by extending FORM, so the usual FORM processing > happens before SQLFORM deals with the delete.) > > I suppose instead you would like onvalidaton to run in *all *cases (when > delete is checked), but I don't think that is the best solution for your > use cases, as it would still require custom internal logic to distinguish > deletions (not to mention that it would break backward compatibility). > Instead, if we were going to make changes to accommodate these use cases, a > better approach would be a separate before delete hook, and possibly an > after delete hook. But even without these additional hooks, it is fairly > easy to accommodate these cases with the DAL callbacks or simply with some > code that runs before or after the grid code. > > >> 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. >> > > Yes. The point is the need for such custom logic makes onvalidation less > suitable for what you want to do. A separate callback would be more useful. > Otherwise, you might as well just put that logic outside of onvalidation. > > >> 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. >> > > Yes, good point. Actually, in your case, I would probably simply disable > the "delete" checkbox in the edit form (via editargs=dict(deletable=False)), > and only allow deletion via the grid buttons (which you can then intercept > via the ondelete callback). > > An even better approach would be to use the db.mytable._before_delete > callback, which is exactly how the built-in record versioning works (it > adds a _before_delete callback that intercepts all deletes and instead > updates the is_active field to False). This would catch deletion via the > grid buttons or edit forms. > > >> 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. >> > > See above -- onvalidation is not the place for that logic. Though if you > *must*, you can simply put that logic in both the onupdate and onfailure > callbacks of the grid, or specify onvalidation as a dictionary, with > onsuccess and onfailure callbacks that both include that logic. > > >> 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. >> > > Callbacks are necessary when you need to run some custom code in the > middle of some other process, but less important when your custom logic can > run entirely before or entirely after the process in question. In that > regard, as noted above, before and after delete callbacks in SQLFORM might > be nice, but certainly aren't a necessity (particularly given that in many, > if not most, cases, the DAL callbacks would suffice). > > 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.
