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.
