Code

Opened 6 years ago

Closed 3 years ago

Last modified 7 months ago

#6362 closed New feature (wontfix)

Remove blank spaces with strip when validating the data

Reported by: marinho 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 emulbreh 6 years ago.
normalize kwarg for newforms.Field
6362.diff (3.2 KB) - added by alekam 3 years ago.
update to current trunk
6362-default-for-ChadFields.diff (7.7 KB) - added by alekam 3 years ago.
Strip leading and trailinig whitespace for CharFields

Download all attachments as: .zip

Change History (48)

comment:1 Changed 6 years ago by bp@…

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 6 years ago by dcramer

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 6 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 6 years ago by akaihola

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

comment:5 Changed 6 years ago by jacob

  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 6 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 6 years ago by emulbreh

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 6 years ago by emulbreh

normalize kwarg for newforms.Field

comment:8 Changed 6 years ago by emulbreh

BooleanField.__init__() looks messy.

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

  • Cc rahmcoff@… added

comment:10 Changed 6 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 6 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 6 years ago by nail.xx <nail.xx@…>

+1 vote. Strip should be performed by default.

comment:13 Changed 6 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 6 years ago by julianb

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

comment:15 Changed 6 years ago by mtredinnick

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

  • Has patch set

comment:17 Changed 6 years ago by kratorius

See also #5714 that basically belongs to this.

comment:18 Changed 6 years ago by guettli

  • Cc hv@… added

comment:19 Changed 5 years ago by hdevries

  • Cc bjorn@… added

comment:20 Changed 5 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 5 years ago by anonymous


comment:22 Changed 5 years ago by anonymous


comment:23 Changed 5 years ago by olau

  • 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 follow-up: Changed 5 years ago by marinho

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 5 years ago by julianb

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 5 years ago by marinho

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

  • Cc andy@… added

comment:28 Changed 5 years ago by martin

  • Cc martin@… added

comment:29 Changed 5 years ago by thebitguru

  • 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 4 years ago by hdevries

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

comment:31 Changed 4 years ago by hvdklauw

  • milestone set to 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 4 years ago by ubernostrum

  • milestone 1.2 deleted

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

comment:33 Changed 4 years ago by net147

  • Cc net147@… added

comment:34 Changed 4 years ago by paulc

  • Cc paulc@… added

comment:35 Changed 4 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 4 years ago by fwenzel

  • Cc fwenzel@… added

comment:37 Changed 3 years ago by julien

  • Patch needs improvement set
  • Severity set to Normal
  • Type set to New feature

Tests need to be updated to use unit tests.

comment:38 Changed 3 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 follow-up: Changed 3 years ago by boxed

  • Easy pickings set

comment:40 in reply to: ↑ 39 Changed 3 years ago by ramiro

  • 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 3 years ago by alekam

update to current trunk

Changed 3 years ago by alekam

Strip leading and trailinig whitespace for CharFields

comment:41 Changed 3 years ago by alekam

  • Cc alex@… added
  • UI/UX unset

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

  • Cc t.zander@… added

comment:43 Changed 3 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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 15 months ago by intgr

  • Cc marti@… added

comment:45 Changed 7 months ago by anonymous

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.