Opened 9 years ago

Closed 5 years ago

Last modified 22 months ago

#6362 closed New feature (wontfix)

Remove blank spaces with strip when validating the data

Reported by: Marinho Brandão Owned by: nobody
Component: Forms Version: master
Severity: Normal Keywords: blank space strip
Cc: rahmcoff@…, alex@…, hv@…, bjorn@…, olau@…, andy@…, martin@…, farhan@…, net147@…, paulc@…, fwenzel@…, alex@…, t.zander@…, marti@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Would be nice if forms remove blank spaces with .strip() method when validating data[] to cleaned_data (or saving).

Attachments (3)

6362.normalize-kwarg.diff (6.8 KB) - added by Johannes Dollinger 8 years ago.
normalize kwarg for newforms.Field
6362.diff (3.2 KB) - added by Alex Kamedov 5 years ago.
update to current trunk
6362-default-for-ChadFields.diff (7.7 KB) - added by Alex Kamedov 5 years ago.
Strip leading and trailinig whitespace for CharFields

Download all attachments as: .zip

Change History (51)

comment:1 Changed 9 years ago by bp@…

There is a ticket #4960: 'Add "strip" keyword argument to CharField constructor' that was closed as "wontfix - it's too specialized for inclusion in the main library.", which I personally find quite baffling since it looks like a really low-impact 4-line change, and IMHO for the vast majority of field inputs in a form - you probably don't want leading or tailing spaces.

When prompting for a city name for example, do you really want people entering "Chicago " or " Chicago" instead of just "Chicago"? That hardly seems like a specialized need.

comment:2 Changed 9 years ago by David Cramer

I'm signing this petition. Every single use-case we have of a Char or Text field would use strip() as a default before validation.

comment:3 Changed 9 years ago by jamiequint

+1 here. Seems obvious that in most form cases this should be the default. I don't want users to be able to bypass form fields simply by entering spaces in the required fields instead. Isn't it more common to want stripped data than not? I imagine this probably won't be changed to be like this for backwards compatibility sake, but it does seem to make the most sense, no?

comment:4 Changed 9 years ago by Antti Kaihola

#6717 is about URL fields and leading/trailing spaces specifically.

comment:5 Changed 9 years ago by Jacob

Triage Stage: UnreviewedDesign decision needed

comment:6 Changed 8 years ago by Karen Tracey <kmtracey@…>

I agree this would be useful. Greg Fuller has raised the issue on django-users and pointed out several ways ordinary users can get tripped up and cause problems when blanks are not stripped:

http://groups.google.com/group/django-users/browse_thread/thread/ad01501c1fd9d213#

comment:7 Changed 8 years ago by Johannes Dollinger

How about a more general normalize keyword?

CharField(normalize=lambda x: x.strip()) or CharField(normalize=lambda x: x.upper())

That could also be used to accept "+2h" or "yesterday" in DateTimeFields, or expressions for numerical fields, or ..

Changed 8 years ago by Johannes Dollinger

Attachment: 6362.normalize-kwarg.diff added

normalize kwarg for newforms.Field

comment:8 Changed 8 years ago by Johannes Dollinger

BooleanField.__init__() looks messy.

comment:9 Changed 8 years ago by Peter of the Norse <RahmCoff@…>

Cc: rahmcoff@… added

comment:10 Changed 8 years ago by bruno.desthuilliers@…

As far as I'm concerned, I'd even say that all (text) fields should be stripped by default, period.

comment:11 Changed 8 years ago by zhango

Cc: alex@… added

+1 on this too please. In usability tests, most of my users accidentally entered a space in EmailFields and were baffled when the django-based system threw an error at them, since what they typed looks fine to them. This happens too often not to be addressed.

comment:12 Changed 8 years ago by nail.xx <nail.xx@…>

+1 vote. Strip should be performed by default.

comment:13 Changed 8 years ago by nail.xx <nail.xx@…>

Possible temporary solution is available at http://www.djangosnippets.org/snippets/956/. But I'm still sure strip should be done by django as default behavior.

comment:14 Changed 8 years ago by Julian Bez

+1. Could be made opt-out, if someone really doesn't like it.

comment:15 Changed 8 years ago by Malcolm Tredinnick

Will everybody please stop putting "+1" style comments. They are *totally* useless for the purposes of the ticket. Even if 100 people added such a comment, that's less than .1% of the userbase, so is entirely non-representative. The resolution will be on the merits, not some straw count.

comment:16 Changed 8 years ago by anonymous

Has patch: set

comment:17 Changed 8 years ago by Ivan Giuliani

See also #5714 that basically belongs to this.

comment:18 Changed 8 years ago by Thomas Güttler

Cc: hv@… added

comment:19 Changed 8 years ago by Henk de Vries

Cc: bjorn@… added

comment:20 Changed 8 years ago by dc

-1 for the normalize(). It's overkill for simple stripping. And for complicated normalization better normalize data in form.clean_FIELD() or write own field subclass with specialized clean() method.

comment:21 Changed 8 years ago by anonymous


comment:22 Changed 8 years ago by anonymous


comment:23 Changed 8 years ago by Ole Laursen

Cc: olau@… added

I sometimes got email from visitors claiming that the user registration form didn't work as it didn't accept their email address. Took quite a while to figure out what was wrong. Today I discovered the same problem with the shopping cart.

Adding a clean_email() method to the form to strip the data doesn't work as it is run after EmailField does its check. So it's easy to do the wrong thing, and it's not straightforward to fix.

comment:24 Changed 8 years ago by Marinho Brandão

In my opinion would be simple have an attribute "keep_blank_spaces" in forms.CharField, with defaulf value False. Then who wants to keep the blank space just set something like this:

    field = forms.CharField(max_length=20, keep_blank_spaces=True)

I'm sure most of cases people don't want keep blank spaces at left or right of cleaned strings.

comment:25 in reply to:  24 Changed 8 years ago by Julian Bez

Replying to marinho:

I'm sure most of cases people don't want keep blank spaces at left or right of cleaned strings.

That might be, but as everyone here was told "Even if 100 people [think so], that's less than .1% of the userbase, so is entirely non-representative. The resolution will be on the merits, not some straw count."

I'm wondering when that is happening.

comment:26 Changed 8 years ago by Marinho Brandão

@julianb

When I said "most of cases" I wasn't meaning "most of us in this discussion", but "most of projects made using Django". And for exceptional cases, there would be an attribute to set it.

comment:27 Changed 8 years ago by anonymous

Cc: andy@… added

comment:28 Changed 8 years ago by martin

Cc: martin@… added

comment:29 Changed 8 years ago by Farhan Ahmad

Cc: farhan@… added

I am also looking for a decision on this (ideally, yes, do it). Posting to the django developers group for a decision (http://groups.google.com/group/django-developers/t/90352cc0da78390b).

comment:30 Changed 7 years ago by Henk de Vries

2 years after opening this ticket still no decision? Rails' ticket management is way, way better than Django's.

comment:31 Changed 7 years ago by Harro

milestone: 1.2

If you call another ticket a duplicate: http://code.djangoproject.com/ticket/11907
At least make sure the original is still looked at...

comment:32 Changed 7 years ago by James Bennett

milestone: 1.2

1.2 is feature-frozen, moving this feature request off the milestone.

comment:33 Changed 7 years ago by net147

Cc: net147@… added

comment:34 Changed 7 years ago by paulc

Cc: paulc@… added

comment:35 Changed 6 years ago by ishirav

Two and a half years for such a small change? C'mon guys, this really needs to be fixed.

Here's another use case that would benefit from this: you send an email to a user with his initial password, or an application license key. When the user copies the value from their email into a form field on your site, very often an extra blank slips in and the form validation fails. This is especially problematic in password fields, since the user can't even see that there's an extra blank in there. It happened to me several times, because when you select-by-double-clicking a word in Firefox or Thunderbird, the blank after the word is included in the selection (try it!)

comment:36 Changed 6 years ago by fwenzel

Cc: fwenzel@… added

comment:37 Changed 6 years ago by Julien Phalip

Patch needs improvement: set
Severity: Normal
Type: New feature

Tests need to be updated to use unit tests.

comment:38 Changed 6 years ago by boxed

Easy pickings: unset

Spaces in various fields in the database screw up sorting too, which gets reported as bugs because the spaces are of course not even shown by HTML.

It's also very hard to fix after the fact. Cron jobs that run strips on all character fields on all your models? No thanks :P

comment:39 Changed 6 years ago by boxed

Easy pickings: set

comment:40 in reply to:  39 Changed 6 years ago by Ramiro Morales

Easy pickings: unset

Replying to boxed:

Easy picking is a recently added nullable boolean-like flag for tickets in our Trac instance that is reset to false with the first update to the ticket after it got added. That is the reason it changes even when you hadn't deactivated it explicitly. There is no need to set it back to on.

Changed 5 years ago by Alex Kamedov

Attachment: 6362.diff added

update to current trunk

Changed 5 years ago by Alex Kamedov

Strip leading and trailinig whitespace for CharFields

comment:41 Changed 5 years ago by Alex Kamedov

Cc: alex@… added
UI/UX: unset

comment:42 Changed 5 years ago by t.zander@…

Cc: t.zander@… added

comment:43 Changed 5 years ago by Jacob

Resolution: wontfix
Status: newclosed

Silently discarding user input -- whether it's spaces or not -- isn't something a framework ought to do. There are enough ways to do this in user code, but if Django strips spaces there aren't any way to get them back, so it's gotta stay this way.

I'd be slightly in favor of a normalization callback for fields (as suggested above), or maybe some sort of "strip spaces" flag (but only if done is a reasonable manner. If someone has a good proposal (hopefully with a patch) here feel free to open a new ticket for it.

comment:44 Changed 4 years ago by Marti

Cc: marti@… added

comment:45 Changed 3 years ago by anonymous

It is really error prone to do the stripping manually. This should be reconsidered.

comment:46 Changed 2 years ago by Mike Fogel

FWIW, I agree with @jacob's decision that by default the framework shouldn't be mucking with user input. However, since removing leading/trailing whitespace is the desired behavior for I believe most every (every?) form I've ever written... a 'strip spaces' flag would be helpful.

Last edited 2 years ago by Mike Fogel (previous) (diff)

comment:47 Changed 2 years ago by Jon Dufresne

+1. I would really appreciate if this feature could be reconsidered. Whether it is on by default or not, I don't care. Users are bypassing form validation by entering spaces in required fields. This seems to throw away the entire point.

comment:48 Changed 22 months ago by Tom Christie

Link to latest thread on the discussion group regarding this...

https://groups.google.com/d/msg/django-developers/D1GBj9VB9sk/gDm5PFHMKSUJ

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