On 18/07/11 14:33, Tom Evans wrote:
> I don't see why this is considered hacky or anti-DRY.
>
> Eg:
>
> class FooForm(forms.ModelForm, StripWhiteSpaceMixin):
> class Meta:
> strip_whitespace_fields = ( 'username', )
> model = Foo
This one would be OK, I hadn't thought about that.
I g
On Thu, Jul 14, 2011 at 10:35 PM, Luke Plant wrote:
> On 10/07/11 22:26, Chris Beaven wrote:
>> To clarify, didn't even notice we were talking about models.Field, I'm
>> +0 for a 'strip' attribute on the form's field, nothing on the model.
>
> Like Chris, I don't think we can put this feature anyw
On 10/07/11 22:26, Chris Beaven wrote:
> To clarify, didn't even notice we were talking about models.Field, I'm
> +0 for a 'strip' attribute on the form's field, nothing on the model.
Like Chris, I don't think we can put this feature anywhere on model
definition. It is clearly an issue of how a fo
How is that supposed to interact with the `cleaning` mechanism of the field?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/BNMXjILUK7gJ.
To post
Hi all!
I like patch 2 [1] for ticket #6362. It has docs and tests, but Yuri propose
more interesting way.
+1 for somthing like SomeField(validators=[...], processors=[...]) where
`processors` is used for normalize value to common format, and `validators`
is used for validate this value.
[1] http
Hi Yuri,
At first I thought that we should extend validators logic, but then I
realized that validation and cleaning (agree that 'cleaners' is a
better term than 'processors') are rather different tasks and mixing
them could be ambiguous, not mentioning backwards incompatibile as a
cleaner should
Hi Dmitry,
I think we could have combination of "validators" + "processors":
they will return either exception or cleaned value.
For example,
SomeField(cleaners=[clean_and_validate_email()])
Did you mean exactly this or rather separated SomeField(validators=[...],
processors=[...]) ?
On Mon, Ju
I don't see what's wrong with 'strip' attribute for models.Field,
we've already non database-related 'blank' attribute, but I agree that
it does not solve the general problem.
What I'm thinking about is something like django.core.validators [1],
but called 'processors' with the only and main diffe
To clarify, didn't even notice we were talking about models.Field, I'm +0
for a 'strip' attribute on the form's field, nothing on the model.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://
On Sunday, July 10, 2011 12:06:34 AM UTC+12, Andrew Ingram wrote:
>
> I'm on the fence here, I like the idea of a strip flag, but I do agree that
> it seems too specific. Perhaps something more generic, eg:
>
> myfield = models.CharField(max_length=255, text_filters=[StripFilter,
> UpperFilter])
On 9 Jul 2011, at 10:44, Sam Lai wrote:
> I concur. The consensus seems to be shifting towards a 'strip' flag
> though (defaulting to false), and I'm +1 on that. That would make it
> explicit, minimise repetitive boilerplate code and also make it less
> likely to accidentally forget to strip a fie
On 5 July 2011 02:20, Jacob Kaplan-Moss wrote:
> Doesn't do anything to change my point, though: a framework can't go
> about stripping user input. That's a user-code decision. If Django
> strips out data I wanted, there's nothing I can do to get it back.
I concur. The consensus seems to be shift
On Mon, Jul 4, 2011 at 10:59 AM, Ole Laursen wrote:
> It sounds like you've never been bitten by strip bugs.
Then I must haven't been clear enough -- sorry -- because I certainly
have, many times. I've also found it incredibly easy to solve in my
user code: ``form.cleaned_data['field'].strip()``.
On Jul 4, 4:52 pm, Jacob Kaplan-Moss wrote:
> On Mon, Jul 4, 2011 at 12:13 AM, Ryan wrote:
> > Umm... How about now?
>
> Sorry, but this isn't going to happen. I left more information on the
> ticket:https://code.djangoproject.com/ticket/6362#comment:43.
It sounds like you've never been bitten b
On Mon, Jul 4, 2011 at 12:13 AM, Ryan wrote:
> Umm... How about now?
Sorry, but this isn't going to happen. I left more information on the
ticket: https://code.djangoproject.com/ticket/6362#comment:43.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django
+1
On Mon, Jul 4, 2011 at 6:13 AM, Ryan wrote:
> Umm... How about now? I've been bitten by trailing/leading blank spaces in
> form inputs several times now, and I'm tired of monkey patching django to
> fix this. Thanks.
>
> Ryan
>
> --
> You received this message because you are subscribed to t
Umm... How about now? I've been bitten by trailing/leading blank spaces in
form inputs several times now, and I'm tired of monkey patching django to
fix this. Thanks.
Ryan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this di
I tend to agree that #6362 should be reconsidered. Realistically
speaking, almost all form fields aren't going to want leading or
trailing spaces. The default case, therefore, should strip them,
while allowing the app writer to override that behaviour in the small
minority of cases where the whit
On "strip keyword arg for CharField"
>From http://code.djangoproject.com/ticket/4960
09/14/07 11:28:49 changed by adrian
{{{
Marking as wontfix -- it's too specialized for inclusion in the main library. A
bunch of us in #django-sprint agreed.
}}}
We should think about this decision again. The cc
09, 9:35 pm
> Subject: Decision for ticket #6362 - Remove blank spaces with strip
> when validating the data
> To: Django developers
>
>
> The common use case on my projects is definitely to trim whitespace.
> The autostrip decorator I found on djangosnippets (http://
> ww
The common use case on my projects is definitely to trim whitespace.
The autostrip decorator I found on djangosnippets (http://
www.djangosnippets.org/snippets/956/) is pretty awesome, but I'd
prefer not to import that into every project and it would be nice to
not call:
> MyForm = autostrip(MyFo
I'd love to see this change get put in. I think the most common case
for forms is to trim whitespace, not the other way around. I'd rather
have the extra work come in for the rare case (when you wanted to
preserve leading/trailing spaces).
-Taylor
On Oct 10, 11:37 am, Barry Pederson wrote:
>
On May 13, 2:56 am, Russell Keith-Magee
wrote:
>On Wed, May 13, 2009 at 7:48 AM, thebitguru wrote:
>> Hi,
>> What do we need to make a decision for ticket 6362 (http://
>> code.djangoproject.com/ticket/6362)?
> We need to wait until we're not trying to get v1.1 out the door.
> We are w
On Wed, May 13, 2009 at 2:36 AM, julianb wrote:
> Since the ticket is one year old, that time had come and passed.
The ticket's age is irrelevant. *right this minute*, everyone is
focused on 1.1, so making a design decision for this ticket is not
important right now.
Once 1.1 is out, it can be
On May 13, 2:56 am, Russell Keith-Magee
wrote:
> We need to wait until we're not trying to get v1.1 out the door.
Since the ticket is one year old, that time had come and passed.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
On Wed, May 13, 2009 at 7:48 AM, thebitguru wrote:
>
> Hi,
>
> What do we need to make a decision for ticket 6362 (http://
> code.djangoproject.com/ticket/6362)?
We need to wait until we're not trying to get v1.1 out the door.
We are well past the feature deadline for v1.1; the focus of the
com
Hi,
What do we need to make a decision for ticket 6362 (http://
code.djangoproject.com/ticket/6362)?
Thanks,
Farhan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, s
27 matches
Mail list logo
