#17637 closed New feature (wontfix)
Client side validation classes for forms
Reported by: | karthikabinav | Owned by: | Marcelo Galigniana |
---|---|---|---|
Component: | Forms | Version: | 1.3 |
Severity: | Normal | Keywords: | Forms, Client Side validation, js |
Cc: | Carlton Gibson | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Having client side javascript validation for forms having common fields like username having only alphanumerics or password and Confirm password fields matching by providing a validation class.
For example a user should be able to do something like :
forms.TextField(validators ="usernameValidation")
And automatically a javascript validation for this form field should be in place.
One way to do it could be using HTML5 attributes like ticket #16304.
Attachments (1)
Change History (10)
by , 13 years ago
Attachment: | pattern_charfield.patch added |
---|
comment:1 by , 13 years ago
Description: | modified (diff) |
---|---|
Needs documentation: | set |
Needs tests: | set |
Patch needs improvement: | set |
Per discussion on django-developers, I think we can accept this on principal (not the patch itself, as it doesn't have tests or docs). IMHO, best approach would be to use HTML5 features + provide some simple JavaScript fallback for not widely supported features.
comment:2 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 3 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 3 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Patch needs improvement: | unset |
UI/UX: | unset |
PR was created.
comment:5 by , 3 years ago
Has patch: | set |
---|
comment:6 by , 3 years ago
Cc: | added |
---|
comment:7 by , 2 years ago
The HTML5 pattern attribute does a re.fullmatch behind the scenes and our RegexValidator does a re.search instead.
Should I create a new Validator?
Thanks!
comment:8 by , 2 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Hi Marcelo. Thanks for the input on this old-one. Mariusz and I have been discussing it intermittently… hence the slow follow-up.
In conclusion, I just can't see that the functionality here justifies the additional passthrough kwarg on the CharField
.
We can already specify pattern
via the widget attributes, and a validator if desired.
I'd much rather we used that API, than add an extra code path for the same here.
In a project subclassing CharField
to wrap your own options is likely.
As such I'm going to close this as wontfix
. In the 10 years since this was opened things have progressed — as you said on the PR, we don't need the fallback — I think it was that which may have justified the ticket, but I don't think ever in that time there's been a stable enough JS option that we'd have wanted to include... — hence it sitting here I guess.
Even if we're not merging your fix, getting it to a conclusion is a good step forwards, so thanks! 🎁
I hope that makes sense. C.
comment:9 by , 2 years ago
Of course Carlton, totally makes sense! I'm happy to see another old one closed!
Thanks you for the detailed answer!
🤗
Supply accepted characters as a regular expression in CharField forms. Uses HTML5 attribute 'pattern' to provide the client side validation.