Opened 16 years ago

Closed 13 years ago

Last modified 9 years 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: dev
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 16 years ago.
normalize kwarg for newforms.Field
6362.diff (3.2 KB ) - added by Alex Kamedov 13 years ago.
update to current trunk
6362-default-for-ChadFields.diff (7.7 KB ) - added by Alex Kamedov 13 years ago.
Strip leading and trailinig whitespace for CharFields

Download all attachments as: .zip

Change History (51)

comment:1 by bp@…, 16 years ago

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 by David Cramer, 16 years ago

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 by jamiequint, 16 years ago

+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 by Antti Kaihola, 16 years ago

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

comment:5 by Jacob, 16 years ago

Triage Stage: UnreviewedDesign decision needed

comment:6 by Karen Tracey <kmtracey@…>, 16 years ago

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 by Johannes Dollinger, 16 years ago

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 ..

by Johannes Dollinger, 16 years ago

Attachment: 6362.normalize-kwarg.diff added

normalize kwarg for newforms.Field

comment:8 by Johannes Dollinger, 16 years ago

BooleanField.__init__() looks messy.

comment:9 by Peter of the Norse <RahmCoff@…>, 16 years ago

Cc: rahmcoff@… added

comment:10 by bruno.desthuilliers@…, 16 years ago

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

comment:11 by zhango, 16 years ago

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 by nail.xx <nail.xx@…>, 16 years ago

+1 vote. Strip should be performed by default.

comment:13 by nail.xx <nail.xx@…>, 16 years ago

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 by Julian Bez, 16 years ago

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

comment:15 by Malcolm Tredinnick, 16 years ago

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 by anonymous, 16 years ago

Has patch: set

comment:17 by Ivan Giuliani, 16 years ago

See also #5714 that basically belongs to this.

comment:18 by Thomas Güttler, 15 years ago

Cc: hv@… added

comment:19 by Henk de Vries, 15 years ago

Cc: bjorn@… added

comment:20 by dc, 15 years ago

-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 by anonymous, 15 years ago


comment:22 by anonymous, 15 years ago


comment:23 by Ole Laursen, 15 years ago

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 by Marinho Brandão, 15 years ago

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.

in reply to:  24 comment:25 by Julian Bez, 15 years ago

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 by Marinho Brandão, 15 years ago

@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 by anonymous, 15 years ago

Cc: andy@… added

comment:28 by martin, 15 years ago

Cc: martin@… added

comment:29 by Farhan Ahmad, 15 years ago

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 by Henk de Vries, 14 years ago

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

comment:31 by Harro, 14 years ago

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 by James Bennett, 14 years ago

milestone: 1.2

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

comment:33 by net147, 14 years ago

Cc: net147@… added

comment:34 by paulc, 14 years ago

Cc: paulc@… added

comment:35 by ishirav, 14 years ago

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 by fwenzel, 14 years ago

Cc: fwenzel@… added

comment:37 by Julien Phalip, 13 years ago

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

Tests need to be updated to use unit tests.

comment:38 by Anders Hovmöller, 13 years ago

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 by Anders Hovmöller, 13 years ago

Easy pickings: set

in reply to:  39 comment:40 by Ramiro Morales, 13 years ago

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.

by Alex Kamedov, 13 years ago

Attachment: 6362.diff added

update to current trunk

by Alex Kamedov, 13 years ago

Strip leading and trailinig whitespace for CharFields

comment:41 by Alex Kamedov, 13 years ago

Cc: alex@… added
UI/UX: unset

comment:42 by t.zander@…, 13 years ago

Cc: t.zander@… added

comment:43 by Jacob, 13 years ago

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 by Marti Raudsepp, 11 years ago

Cc: marti@… added

comment:45 by anonymous, 11 years ago

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

comment:46 by Mike Fogel, 10 years ago

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 10 years ago by Mike Fogel (previous) (diff)

comment:47 by Jon Dufresne, 10 years ago

+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 by Tom Christie, 9 years ago

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