#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 fall back 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 , 3 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 , 3 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 , 3 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.