Someone remind me never to post to list before I've had my second coffee? :)
Of course the above would trivially be handled using middleware.
On 4 September 2013 10:05, Curtis Maloney wrote:
> What do people think of an extensible registration approach to
What do people think of an extensible registration approach to handling
request content types?
Something along the lines of ('POST', [list of content types], class to
This would mean adding a request.JSON would be simple for the projects that
want it, and even overriding how the
I updated the syncdb tests as well since it was straightforward. I get a
clean output on Python 2.7. Python 3 still has some issues (e.g. #19905),
but these aren't deprecated features.
On Tuesday, September 3, 2013 8:46:30 AM UTC-4, Tim Graham wrote:
> Thanks for raising the issue. I think I
Thanks for raising the issue. I think I committed the first and last of the
three, so I'll fix those.
I've also added a ticket to document "how to deprecate a feature" in order
to make these guidelines more accessible.
On Monday, September 2, 2013
+1 to providing a better way of accessing JSON encoded post data. -1 to it
being munged into request.POST - I feel this is unintuitive.
A nice possibility could be a simple piece of middleware which detects
`application/json` and attaches request.json as an attribute, if it can
decode it. This
I looked around the list and couldn't find any mention of this subject.
In `django.http.request.HttpRequest._load_post_and_files()` there is
explicit mention of two content type ('multipart/form-data' and
'application/x-www-form-urlencoded'), any other content type will get empty
You're right, it would only matter if multiple apps (not core) were trying
to use the same command. Which presumably doesn't happen very often?
I filed a ticket here: https://code.djangoproject.com/ticket/21018.
On Sunday, September 1, 2013 6:04:03 PM UTC-4, Marc Tamlyn wrote:
> I don't
1. Progress: I've made improvements to admin checks. I've also finished
implementing filtering and silencing checks. I've rebased my branch against
2. I'm afraid that there is too little time to merge django-secure.
September 16 is
suggested 'pencils down' date, so there are only