You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the situation of redirects, for example, I would like to validate all of the rows before any are saved. This would allow me to make sure there are no circular redirects. I also think it's good usability not to insert any of them before checking that all of them pass validation.
I was thinking that process_row could become validate_row or even clean_row (then we could also consider it as a hook for fixing some of the data).
Somewhat related:
Also, would it be possible to use form non-field errors instead of the messages framework? I know that it might be a big change, but would it be possible to move the import logic to the Form instead of the View? That would have several advantages:
We could take the Form in use it outside of the admin in a normal FormView.
clean_row could live on the form, and be a part of the normal validation flow
The obvious place to the circular redirect check is now clean.
The text was updated successfully, but these errors were encountered:
If one row is invalid, the data import doesn't get committed. You could just raise a ValidationError in the clean method of the form, when a row introduces a circular redirect.
Side-note: @gavinwahl would like to display the whole CSV in a table form with the validations errors when there are some. This would allow the user to update the data and resubmit it. I feel like this would be related to this feature.
Anyway, I don't really understand how this would work, but in the abstract, I don't see anything wrong with your feature. And I would like to have @gavinwahl's suggested feature if possible.
In the situation of redirects, for example, I would like to validate all of the rows before any are saved. This would allow me to make sure there are no circular redirects. I also think it's good usability not to insert any of them before checking that all of them pass validation.
I was thinking that
process_row
could becomevalidate_row
or evenclean_row
(then we could also consider it as a hook for fixing some of the data).Somewhat related:
Also, would it be possible to use form non-field errors instead of the messages framework? I know that it might be a big change, but would it be possible to move the import logic to the Form instead of the View? That would have several advantages:
clean_row
could live on the form, and be a part of the normal validation flowclean
.The text was updated successfully, but these errors were encountered: