Opened 13 years ago

Closed 2 years ago

Last modified 2 years ago

#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 Łukasz Rekucki)

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)

pattern_charfield.patch (1.4 KB ) - added by karthikabinav 13 years ago.
Supply accepted characters as a regular expression in CharField forms. Uses HTML5 attribute 'pattern' to provide the client side validation.

Download all attachments as: .zip

Change History (10)

by karthikabinav, 13 years ago

Attachment: pattern_charfield.patch added

Supply accepted characters as a regular expression in CharField forms. Uses HTML5 attribute 'pattern' to provide the client side validation.

comment:1 by Łukasz Rekucki, 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.

Version 0, edited 13 years ago by Łukasz Rekucki (next)

comment:2 by Łukasz Rekucki, 13 years ago

Triage Stage: UnreviewedAccepted

comment:3 by Marcelo Galigniana, 3 years ago

Owner: changed from nobody to Marcelo Galigniana
Status: newassigned

comment:4 by Marcelo Galigniana, 3 years ago

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
UI/UX: unset

PR was created.

comment:5 by Mariusz Felisiak, 3 years ago

Has patch: set

comment:6 by Mariusz Felisiak, 3 years ago

Cc: Carlton Gibson added

comment:7 by Marcelo Galigniana, 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 Carlton Gibson, 2 years ago

Resolution: wontfix
Status: assignedclosed

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 Marcelo Galigniana, 2 years ago

Of course Carlton, totally makes sense! I'm happy to see another old one closed!

Thanks you for the detailed answer!

🤗

Note: See TracTickets for help on using tickets.
Back to Top