Re: WSGI support in Django

On Tue, Oct 27, 2009 at 10:49 PM, Gustavo Narea wrote: > > Hi there. > > Over the last week I've been working to improve WSGI support in Django > and I have sent a few patches which have not received the feedback I > expected to have, so I wanted to ping you.

Re: project folder with dots

On Tue, Oct 27, 2009 at 4:06 PM, Kevin Teague wrote: > Structure a Django project so it has the same layout as a normal > Python project. Which might look something like: > >myinstance/ >setup.py >settings.py >bin/ >manage.py >mysite/

Re: CSRF changes - backwards incompatible

Interesting note. A co-worker of my has been working with the poll tutorial for a couple days now and just got to part 3 which now contains the {% csrf_token %} tag. He could not figure out how why he was getting an error that the csrf_token tag could not be loaded. I'm not sure how wide spread

Re: project folder with dots

On Oct 26, 7:23 pm, Tobias McNulty wrote: > > IMHO the project namespace is a useful one to keep around. If you lose the > project name space, then you risk polluting your python path with a lot of > generic 'urls' modules, among other things. > > If your directory

Re: CSRF changes - backwards incompatible

On Tue, Oct 27, 2009 at 1:54 PM, Luke Plant wrote: > There is a patch on http://code.djangoproject.com/ticket/12095 that > tries to address this. Repeating what I said on #django-dev this morning, I'm +1 on this patch. Rending forms via an inclusion tag is a pretty common

Re: CSRF changes - backwards incompatible

On Tuesday 27 October 2009 13:03:14 Luke Plant wrote: > If you have supplied custom templates to contrib views that accept > POST requests (e.g. auth login etc.), the template may need > updating. The steps needed are fully described in the docs, but in > short: > > Inside all elements,

Re: project folder with dots

> To fix the code is easy enough. But to update all of the relevant > documentation and to require all existing Django deployments to have > to migrate their project structures (or change all of their imports) > to upgrade is a much bigger issue to tackle. Thank you for answer. Do you think it's

Re: project folder with dots

> IMHO the project namespace is a useful one to keep around. If you > lose the project name space, then you risk polluting your python path > with a lot of generic 'urls' modules, among other things. I don't understand why in tutorial all imports contain project name. I think this is wrong

Re: __in and comma-separated strings.

Right. I'll experiment a bit more with this and look for a better solution than comma-splitting. J. Leclanche / Adys On Tue, Oct 27, 2009 at 6:39 PM, Jacob Kaplan-Moss wrote: > > On Tue, Oct 27, 2009 at 11:36 AM, Jerome Leclanche wrote: >> Point still

Re: __in and comma-separated strings.

On Tue, Oct 27, 2009 at 11:36 AM, Jerome Leclanche wrote: > Point still stands, it's impossible to pass a true iterable (1-char > iterables don't count) to a GET. What? >>> from django.http import QueryDict >>> q = QueryDict('a=1=2=3=4=5') >>> q.getlist('a') [u'1', u'2',

Re: __in and comma-separated strings.

On Tue, Oct 27, 2009 at 6:23 PM, Alex Gaynor wrote: > > I meant precisely what I said, comma separating values in a GET string > is a fairly arbitrary means of serializing a value, in past I've seen > other characters used (or just having multiple values in the >

Re: __in and comma-separated strings.

On Tue, Oct 27, 2009 at 12:19 PM, Jerome Leclanche wrote: > > It's not... if you got control over the code. However my patch is > specifically targeted at GET processing. You have to add a bunch of > checks after each other, it quickly becomes overwhelming. > > Alex, I'm

Re: __in and comma-separated strings.

It's not... if you got control over the code. However my patch is specifically targeted at GET processing. You have to add a bunch of checks after each other, it quickly becomes overwhelming. Alex, I'm interested by what you mean exactly by "tying __in to an arbitrary serialization format". What

Re: __in and comma-separated strings.

On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche wrote: > I've got a patch to let __in accept comma-separated strings; I'm using > this locally to avoid going through the trouble of splitting a string > before processing a GET. I'm -1 on this. Is `filter(foo__in=s.split())`

Re: __in and comma-separated strings.

On Tue, Oct 27, 2009 at 11:57 AM, Jerome Leclanche wrote: > > I've got a patch to let __in accept comma-separated strings; I'm using > this locally to avoid going through the trouble of splitting a string > before processing a GET. The exact same technique is used in >

__in and comma-separated strings.

I've got a patch to let __in accept comma-separated strings; I'm using this locally to avoid going through the trouble of splitting a string before processing a GET. The exact same technique is used in django-admin, and I'd bet many other apps as well. Is there a reason why this behaviour isn't

Re: CSRF changes - backwards incompatible

I fixed the django-pages-cms app by adding the csrf token tags into the POST forms in the apps admin pages. On 27 okt, 15:36, Luke Plant wrote: > On Tuesday 27 October 2009 13:30:42 TheMaTrIx wrote: > > > I don't understand something here. csrf is stated to be a option >

WSGI support in Django

Hi there. Over the last week I've been working to improve WSGI support in Django and I have sent a few patches which have not received the feedback I expected to have, so I wanted to ping you. ;-) To be precise, with those patches Django applications would be able to: 1.- [Ticket 8927] Use

Re: CSRF changes - backwards incompatible

On Tuesday 27 October 2009 13:30:42 TheMaTrIx wrote: > I don't understand something here. csrf is stated to be a option > that needs to be enabled if you wish to use it for views, yet I > just ran a trunk sync and boom, django-pages-cms is busted, > without me enabling anything. The CSRF

Re: CSRF changes - backwards incompatible

On Tuesday 27 October 2009 13:07:14 rebus_ wrote: > And there are also some typos in guide: Cheers! Fixed now. After this patch, I won't be sad if I never have to type 'csrf' (or 'crsf') ever again :-) But unfortunately I will... Luke -- Environmentalists are much too concerned with

Re: CSRF changes - backwards incompatible

2009/10/27 Luke Plant : > If you have supplied custom templates to contrib views that accept > POST requests (e.g. auth login etc.), the template may need updating. > The steps needed are fully described in the docs, but in short: > >  Inside all elements, add {%

CSRF changes - backwards incompatible

Hi all, For those following trunk, the CSRF changes have now landed (apart from Simon's proposed refinements). At first I thought this would be perfectly seamless, not requiring any immediate action, and it therefore didn't warrant a note to django- devs. However, there are circumstances