add support for unicode-normalizing get/post-data?

hi, would it be a good idea to add support to django to unicode-normalize incoming get/post-data? the normalization problem is basically this: for example my name, 'gábor' can be written in 2 different ways in unicode: u'g\xe1bor' and u'ga\u0301bor'. the first one uses the 'LATIN SMALL

Re: add support for unicode-normalizing get/post-data?

On Thu, Apr 10, 2008 at 12:18 PM, Gábor Farkas <[EMAIL PROTECTED]> wrote: > p.s: if there is a way to achieve this without touching > django-internals, please tell me :) I would have written a view decorator that takes request, and normalizes the request.GET/POST before calling the real view.

Re: add support for unicode-normalizing get/post-data?

Amit Upadhyay wrote: > On Thu, Apr 10, 2008 at 12:18 PM, Gábor Farkas <[EMAIL PROTECTED] > > wrote: > > p.s: if there is a way to achieve this without touching > django-internals, please tell me :) > > > I would have written a view decorator that takes

is_authenticated as property

Hi, is_staff, is_active, is_superuser are attributes. is_anonymous, is_authenticated are methods. This is insecure if you are not careful while programming: if user.is_authenticated: # Always true, since it is a method! It would be nice to find a solution. Here is what I thought:

Re: Easier URL patterns

Peter Rowell wrote: > I sort of know the answers, but it would be interesting (to me at > least) to hear what the core developers think. as for most successful open source projects, the core audience is people that are pretty much like themselves. projects that try to "talk down to the

Re: add support for unicode-normalizing get/post-data?

On Apr 10, 2:48 pm, Gábor Farkas <[EMAIL PROTECTED]> wrote: > hi, > > would it be a good idea to add support to django to unicode-normalize > incoming get/post-data? class NormCharField(forms.CharField): def clean(self, value): value = super(NormCharField, self).clean(value)

Re: add support for unicode-normalizing get/post-data?

On Thursday 10 April 2008 08:17:40 Gábor Farkas wrote: > that would work, but there are 2 problems with it: > > 1. i have to do it for every request (this could be solved maybe > with a middleware-based approach) You could also do it in your urls.py e.g.: urls = [ ('/foo/', fooviewfunc),

Allow Form._clean() to specify the invalid field

Quoting problem statement from #6652: "Currently the Form.clean() method has no way to specify which field is invalid, but it's the only place where validation involving many fields can be accomplished. Taking your example in the documentation: This is where you might put in things to check

Re: add support for unicode-normalizing get/post-data?

On Apr 10, 9:44 pm, simonb <[EMAIL PROTECTED]> wrote: > return unicodedata.normalize('NFC',text) That should be "return unicodedata.normalize('NFC',value)" It's late! Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to

Re: An Awesome Proposal [You won't like]

I think with field subclassing, descriptors are a good way to add this sort of thing, but it needn't be backwards imcompatible, because any get_XXX_display could just translate to model.XXX.display, etc. On Thu, Apr 10, 2008 at 12:05 PM, David Cramer <[EMAIL PROTECTED]> wrote: > Let's move

Re: An Awesome Proposal [You won't like]

On Thu, Apr 10, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote: > mymodel.filedfield.save_file() For what it's worth, ticket #5361 does exactly this. http://code.djangoproject.com/ticket/5361 > - Clutters the model namespace Agreed > - [Assumption] Performance gain by removing

Re: An Awesome Proposal [You won't like]

On Thu, Apr 10, 2008 at 1:08 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > I think with field subclassing, descriptors are a good way to add this > sort of thing, but it needn't be backwards imcompatible, because any > get_XXX_display could just translate to model.XXX.display, etc.

Re: An Awesome Proposal [You won't like]

On Thu, Apr 10, 2008 at 1:30 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > Unfortunately, there are still a number of situations where existing > code (and most likely will) break. Some of these situations are easily > solvable, others *could* be solved easily by doing a bit of weird > stuff

An Awesome Proposal [You won't like]

Let's move get_FOO_x off of the models and on to their actual objects: mymodel.choicefield.display() mymodel.filedfield.save_file() etc. Why? - Clutters the model namespace - [Assumption] Performance gain by removing them as it creates extra lambda functions to attach them. I'm guessing this

Re: An Awesome Proposal [You won't like]

On Thu, Apr 10, 2008 at 12:05 PM, David Cramer <[EMAIL PROTECTED]> wrote: > mymodel.choicefield.display() So we're going to stuff extra methods onto, say, an 'int' object? Because that's what the descriptor should return, and having it magically sprout methods like this would be more than a

Re: add support for unicode-normalizing get/post-data?

On Thu, Apr 10, 2008 at 06:44:35AM -0700, simonb wrote: > > On Apr 10, 2:48 pm, Gábor Farkas <[EMAIL PROTECTED]> wrote: > > hi, > > > > would it be a good idea to add support to django to unicode-normalize > > incoming get/post-data? > > class NormCharField(forms.CharField): > def

Re: add support for unicode-normalizing get/post-data?

Why wouldn't you just do this in a middleware? A decorator, or a clean_X on forms would not handle every incoming request like he wants. On Apr 10, 11:26 am, Gábor Farkas <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 06:44:35AM -0700, simonb wrote: > > > On Apr 10, 2:48 pm, Gábor Farkas

FormWizard and __call__

I originally posted this in -users, but since it deals with internals, maybe it's more appropriate for -dev. I'm looking at the FormWizard code, and in __call__, we have the following: for i in range(current_step): form = self.get_form(i, request.POST) if request.POST.get("hash_%d" % i,

Re: add support for unicode-normalizing get/post-data?

David Cramer wrote: > Why wouldn't you just do this in a middleware? A decorator, or a > clean_X on forms would not handle every incoming request like he > wants. maybe i wasn't clear in my original response to Amit.. the thing is, even a middleware cannot nicely solve it imho.. or at least i'm