Re: [Django] #23: Add support for ValidationWarning
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Changes (by sebastian):
* cc: sebastian.goll@… (added)
* ui_ux: => 0
* easy: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:19>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by anonymous):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:20>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
* cc: hv@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:21>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
* cc: botondus@… (added)
Comment:
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
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:22>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by anonymous):
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:23>
Django
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by anonymous):
[http://www.parisbonbon parisbonbon]
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
* cc: adehnert (added)
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
* needs_docs: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:24>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by slurms):
updated patch to work on current code, all tests pass.
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:25>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by slurms):
opened a pull request: https://github.com/django/django/pull/629
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:26>
Django
Reporter: adrian | Owner: AnkitBagaria
Type: New feature | Status: assigned
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by AnkitBagaria):
* owner: nobody => AnkitBagaria
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:27>
Django
-----------------------------+----------------------------------------
Reporter: adrian | Owner: AnkitBagaria
Type: New feature | Status: assigned
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+----------------------------------------
* cc: cmawebsite@… (removed)
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:28>
Django
-----------------------------+------------------------------------
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
* status: assigned => new
* owner: AnkitBagaria =>
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:29>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner:
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by jgeskens):
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:30>
Django
-----------------------------+------------------------------------
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 1
-----------------------------+------------------------------------
Changes (by jgeskens):
* owner: => jgeskens
* needs_better_patch: 0 => 1
* ui_ux: 0 => 1
* status: new => assigned
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:31>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: jgeskens
Type: New feature | Status: assigned
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 1
-----------------------------+------------------------------------
Comment (by sebleblanc):
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)>
Email
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:32>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: jgeskens
Type: New feature | Status: assigned
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 1
-----------------------------+------------------------------------
* cc: loic@… (added)
Comment:
I'm actually pretty worried about this ticket.
I've been making a lot of changes to the form error reporting (#20199,
#16986, #20867, [https://code.djangoproject.com/ticket/17413#comment:8
#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().
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:33>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: jgeskens
Type: New feature | Status: assigned
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 1
-----------------------------+------------------------------------
Comment (by aaugustin):
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:34>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: jgeskens
Type: New feature | Status: assigned
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 1
-----------------------------+------------------------------------
* cc: rtnpro (added)
Comment:
@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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:35>
Django
-----------------------------+------------------------------------
Reporter: adrian | Owner: jgeskens
Component: Forms | Version:
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 1
-----------------------------+------------------------------------
* status: assigned => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23#comment:36>