Opened 19 years ago
Closed 11 years ago
#23 closed New feature (wontfix)
Add support for ValidationWarning
Reported by: | Adrian Holovaty | Owned by: | Jef Geskens |
---|---|---|---|
Component: | Forms | Version: | |
Severity: | Normal | Keywords: | |
Cc: | paul.bowsher@…, mir@…, miloslav.pojman@…, dirleyrls, sebastian.goll@…, hv@…, botondus@…, adehnert, loic@…, rtnpro | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | yes |
Description
We've talked in the past about how useful it would be to let certain validators throw ValidationWarning instead of ValidationError. A ValidationWarning, when thrown, would still redisplay the admin form but display an additional checkbox above the field. If that checkbox is checked when the form is submitted, the error is ignored.
The change would have to be made in django/core/formfields.py.
Attachments (4)
Change History (40)
comment:1 by , 19 years ago
Component: | Core framework → Validators |
---|
comment:2 by , 19 years ago
Cc: | added |
---|
comment:3 by , 18 years ago
Cc: | added; removed |
---|
This would then be limited to admin forms, do I understand this correctly?
comment:4 by , 18 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:5 by , 17 years ago
Triage Stage: | Design decision needed → Accepted |
---|
Safe to assume that if Adrian proposed the idea, it has been accepted.
comment:6 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:7 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:8 by , 17 years ago
Owner: | changed from | to
---|
comment:9 by , 17 years ago
Cc: | added |
---|---|
Component: | Validators → django.newforms |
Has patch: | set |
Patch needs improvement: | set |
It seems to me that these ValidationWarnings could not be regular Python exceptions. Python exceptions will stop running the validation code after a ValidationWarning is thrown, so there could be a ValidationError that would be thrown later, but instead it would appear that the field only has a warning and no errors. Instead I propose that, if we still want this feature, we use a list of warnings instead.
Is it safe to assume this applies to newforms, and not the database validation?
I have a partial implementation of this in newforms.
by , 17 years ago
Attachment: | warnings_as_list_partial.patch added |
---|
Patch against [6992] that has a partial implemtation of keeping track of Warnings as a list
comment:10 by , 16 years ago
milestone: | → post-1.0 |
---|
Marking as post-1.0 as this is not essential for 1.0.
comment:11 by , 16 years ago
Component: | Forms → Authentication |
---|---|
Needs documentation: | set |
Needs tests: | set |
Version: | → 1.0-alpha-2 |
comment:12 by , 16 years ago
Component: | Authentication → Forms |
---|
I've begun work on this, you can follow it here: http://github.com/alex/django/tree/local/validation-warning
by , 16 years ago
Attachment: | form-warnings.2.diff added |
---|
removed the nasty warning system, instead pass a callable to the clean functions
comment:14 by , 15 years ago
Version: | 1.0-alpha-2 → soc2009/admin-ui |
---|
comment:16 by , 14 years ago
Cc: | added |
---|
comment:17 by , 14 years ago
Cc: | added |
---|
comment:18 by , 14 years ago
Severity: | normal → Normal |
---|---|
Type: | enhancement → New feature |
comment:19 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
UI/UX: | unset |
comment:20 by , 13 years ago
I was just day dreaming about this feature today, wondering if it existed. Just to voice another use case, I'm building a search system where a fair amount of input validation needs to be done, but when validation fails, I want to make a best effort to process the user's input and give them results (along with perhaps a message about their input: "Such and such field had an error and was ignored"). Currently, I don't think there's an easy way to do this. Would love to see built in support.
comment:21 by , 13 years ago
Cc: | added |
---|
comment:22 by , 13 years ago
Cc: | added |
---|
This would certainly be a quite useful feature to have. I've worked with a custom implementation of this in a project and it was certainly very nice for some complex forms/workflows
comment:23 by , 12 years ago
Cc: | added |
---|
comment:24 by , 12 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Patch needs improvement: | unset |
comment:27 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:28 by , 12 years ago
Cc: | removed |
---|
comment:29 by , 12 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
by , 11 years ago
Attachment: | form-warnings.3.diff added |
---|
comment:30 by , 11 years ago
https://github.com/django/django/pull/1123
Improved pull request from slurms. It will merge again. It still needs updated documentaton though... anyone wanting to help on that one?
comment:31 by , 11 years ago
Needs documentation: | set |
---|---|
Owner: | set to |
Patch needs improvement: | set |
Status: | new → assigned |
UI/UX: | set |
comment:32 by , 11 years ago
I do not think that such a feature is useful, as it can easily be implemented using standard Django machinery.
Here is an example, supposing that I am writing a user register form, where the date of birth is optional, but I want to warn the user that they would miss on some functionality on my site:
Full name
Date of birth
<hidden "Ignore warning" boolean field (default: False)>
Password
Let us say the user fills all the form but the DOB field. In my form validation, I raise "ValidationError" if the DOB field is empty, and when the form is returned to the user, I display the hidden field, along with an explanation, so that the user may dismiss the warning. If the form is validated again, and the date of birth is still missing, but the checkbox is True, I then accept the form as submitted.
I think this construct can easily be wrapped in a form field mixin. The only use for a ValidationWarning exception (derived from ValidationError) is to make it easier on the form display to determine if the checkbox should be shown. However, I think that they should be handled as regular error.
i.e. (e.g) This form is only valid if field foo
does not contain Unicode characters, or if foo
does contains Unicode and that field foo_ignore_unicode_warning
is True.
If it had to be implemented, I think that having <field>_<reason>_warning
methods would work great.
comment:33 by , 11 years ago
Cc: | added |
---|
I'm actually pretty worried about this ticket.
I've been making a lot of changes to the form error reporting (#20199, #16986, #20867, #17413) so that errors could be overridden and so they retain meaning (metadata like error code or error params) until the very last minute (rendering). All the patches in this ticket suffer from the same problem as the old error reporting, we just accumulate a blob of meaningless text (for the system) that we can only display, therefore I see them as another step in the wrong direction.
Then comes the question, why just warnings? What about informational messages or success messages for each field? Lot of modern websites that have forms operated by AJAX will give this kind of feedback. We have very good validation machinery; it wouldn't be difficult to integrate these.
We almost have form.errors.as_json() with all the metadata with #17413, I’d love to have a more generic form.validation.as_json().
comment:34 by , 11 years ago
This ticket has rotten here for eight years; it may be time to close it.
If someone wants to do something, starting from a clean slate and extracting just the relevant bits from this tickets is likely to give better results.
Any objections to closing it as wontfix?
comment:35 by , 11 years ago
Cc: | added |
---|
@aaugustin Sounds like a plan. I am researching on this issue and I will create a new ticket based on the current code and the things discussed in this thread and start fresh.
comment:36 by , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
I agree with Aymeric. Also the changes as discussed by Loic which are in progress will make it easier to do certain things. It is possible to achieve this kind of functionality already with a customised form. Once the other form validation related changes are there we will be able to come up with a much more concrete proposal for an easy way to do this.
I'll be needing this soon, so I'll try and get something up together