Re: Support POST of application/json content type

[Curtis Maloney]

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.

--
C


On 4 September 2013 10:05, Curtis Maloney wrote:

> 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
> handle it)
>
> This would mean adding a request.JSON would be simple for the projects
> that want it, and even overriding how the existing content types are
> handled would be possible. [I haven't seen a use case for such yet, but
> it's a wild world out there :)]
>
> --
> Curtis
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support POST of application/json content type

[Curtis Maloney]

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
handle it)

This would mean adding a request.JSON would be simple for the projects that
want it, and even overriding how the existing content types are handled
would be possible. [I haven't seen a use case for such yet, but it's a wild
world out there :)]

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Silencing deprecation warnings in the test suite

[Tim Graham]

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 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. 
>
> https://code.djangoproject.com/ticket/21024
>
> On Monday, September 2, 2013 8:41:46 PM UTC-4, Ramiro Morales wrote:
>>
>> On Mon, Sep 2, 2013 at 8:08 AM, Aymeric Augustin 
>>  wrote: 
>> > Hello, 
>> > 
>> > When a feature is deprecated,  it raises a PendingDeprecationWarning, 
>> either at import time or at run time. After the following release it raises 
>> DeprecationWarning. Assuming we have a good test coverage, these warnings 
>> will be shown by the test suite, with -Wall for PendingDeprecationWarning, 
>> by default for DeprecationWarning. This is annoying. The output of the test 
>> suite should remain clean. 
>> > 
>> > Unfortunately, I've noticed that we often forget to silence warnings 
>> when we deprecate a feature. For instance, right new, the test suite raises 
>> warnings related to custom SQL, syncdb, and SortedDict (with -Wall).  If 
>> you committed one of these deprecations, would you mind silencing the 
>> PendingDeprecationWarnings in the tests? 
>> > 
>> > There are two ways to achieve that: 
>> > [...] 
>>
>> Thanks Aymeric for raising awareness about the problem and the compact 
>> action item description. 
>>
>> I plan to propose some changes that involve a deprecation cycle and 
>> had some vague recollection about an email or ticket about the same 
>> issue by Carl but had been unable to find it. Your mail made me search 
>> again and luckily this time I could find it: 
>> https://code.djangoproject.com/ticket/17049 -- Fortunately, the 
>> recommended solution there is in the same spirit as yours. 
>>
>> A result of that ticket is the fact that our CI setup uses -Wall so we 
>> can see these warnings at the console output of every configuration 
>> e.g.: 
>>
>>
>> http://ci.djangoproject.com/job/Django/database=postgres,python=python3.3/lastBuild/console
>>  
>>
>> Regards, 
>>
>> -- 
>> Ramiro Morales 
>> @ramiromorales 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Silencing deprecation warnings in the test suite

[Tim Graham]

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. 

https://code.djangoproject.com/ticket/21024

On Monday, September 2, 2013 8:41:46 PM UTC-4, Ramiro Morales wrote:
>
> On Mon, Sep 2, 2013 at 8:08 AM, Aymeric Augustin 
>  wrote: 
> > Hello, 
> > 
> > When a feature is deprecated,  it raises a PendingDeprecationWarning, 
> either at import time or at run time. After the following release it raises 
> DeprecationWarning. Assuming we have a good test coverage, these warnings 
> will be shown by the test suite, with -Wall for PendingDeprecationWarning, 
> by default for DeprecationWarning. This is annoying. The output of the test 
> suite should remain clean. 
> > 
> > Unfortunately, I've noticed that we often forget to silence warnings 
> when we deprecate a feature. For instance, right new, the test suite raises 
> warnings related to custom SQL, syncdb, and SortedDict (with -Wall).  If 
> you committed one of these deprecations, would you mind silencing the 
> PendingDeprecationWarnings in the tests? 
> > 
> > There are two ways to achieve that: 
> > [...] 
>
> Thanks Aymeric for raising awareness about the problem and the compact 
> action item description. 
>
> I plan to propose some changes that involve a deprecation cycle and 
> had some vague recollection about an email or ticket about the same 
> issue by Carl but had been unable to find it. Your mail made me search 
> again and luckily this time I could find it: 
> https://code.djangoproject.com/ticket/17049 -- Fortunately, the 
> recommended solution there is in the same spirit as yours. 
>
> A result of that ticket is the fact that our CI setup uses -Wall so we 
> can see these warnings at the console output of every configuration 
> e.g.: 
>
>
> http://ci.djangoproject.com/job/Django/database=postgres,python=python3.3/lastBuild/console
>  
>
> Regards, 
>
> -- 
> Ramiro Morales 
> @ramiromorales 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support POST of application/json content type

[Marc Tamlyn]

+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 attribute could actually be made lazy so as not to
introduce any real overhead on other pages, or on views already decoding
the data directly from request.data.

There is a (somewhat stalled) ticket for a JsonResponse class at #17942 (
https://code.djangoproject.com/ticket/17942).


On 3 September 2013 06:30, Stefan Berder  wrote:

> Hi,
> 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
> values for self._post.
>
> Given that a lot of user form interaction is now happening through
> 'XMLHttpRequest', I think that the 'application/json' content type should
> be supported. A lot of javascript libraries will use json as the default
> format:
> * angularjs: http://docs.angularjs.org/api/ng.$http, see "Setting HTTP
> Headers"
> * emberjs:
> https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js#L974
> * backbone: http://backbonejs.org/#Sync
> * jquery: http://api.jquery.com/jQuery.ajax/ (the only one using
> 'application/x-www-form-urlencoded' by default)
>
> I'm trying primarily to create a discussion on the subject and am ready to
> provide the code for it as I had to write it. This would help avoid hacks
> to handle the request object in my view.
>
> I know there are some apps to handle API construction (django-tastypie,
> django-rest, django-piston and certainly others) they use either request
> wrappers or request handling in their views.
>
> Stefan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Support POST of application/json content type

[Stefan Berder]

Hi,
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 
values for self._post.

Given that a lot of user form interaction is now happening through 
'XMLHttpRequest', I think that the 'application/json' content type should 
be supported. A lot of javascript libraries will use json as the default 
format:
* angularjs: http://docs.angularjs.org/api/ng.$http, see "Setting HTTP 
Headers"
* emberjs: 
https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js#L974
* backbone: http://backbonejs.org/#Sync
* jquery: http://api.jquery.com/jQuery.ajax/ (the only one using 
'application/x-www-form-urlencoded' by default)

I'm trying primarily to create a discussion on the subject and am ready to 
provide the code for it as I had to write it. This would help avoid hacks 
to handle the request object in my view. 

I know there are some apps to handle API construction (django-tastypie, 
django-rest, django-piston and certainly others) they use either request 
wrappers or request handling in their views.

Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Order of INSTALLED_APPS

[Kevin Christopher Henry]

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 think it would break South installations as custom app commands 
> will always override builtins. Could you open a ticket for that? The 
> inconsistency is problematic. Obviously it would be backwards incompatible, 
> but we need to gauge the size of the impact.
>
> Marc
> On 1 Sep 2013 21:31, "Kevin Christopher Henry" 
>  
> wrote:
>
>> Sorry to be late to this thread, I just came across it.
>>
>> There's another place where the order of INSTALLED_APPS matters: 
>> management commands. Management commands associated with apps that come 
>> later in INSTALLED_APPS will replace those with the same name that are 
>> listed earlier. I can't find this documented anywhere, but a look at the 
>> code confirms it. South, for example, takes advantage of this to override 
>> the syncdb command (and hints at the ordering issue when the documentation 
>> says: "add 'south' to the end of INSTALLED_APPS").
>>
>> So a documentation update should probably note this specifically in the 
>> management documentation, as well as mentioning it in the box for 
>> INSTALLED_APPS. (I also think static files should also be mentioned in the 
>> box, since as Aymeric points out that is another area dependent on the 
>> order of apps.)
>>
>> One thing that's unfortunate is that the semantics of ordering for 
>> management commands is opposite that of the other cases. For templates, 
>> static files, and translations, listing an app *first *gives it 
>> precedence, whereas with management commands it's listing it *last.*Ideally 
>> this would be changed so that management commands were consistent 
>> with the other cases, but that would create serious backwards compatibility 
>> issues. Like, breaking everyone's South installation. :-O
>>
>> Cheers,
>> Kevin
>>
>>
>> On Wednesday, August 14, 2013 5:26:47 AM UTC-4, Stefano Crosta wrote:
>>>
>>> Done! 
>>> https://code.**djangoproject.com/ticket/**20914#ticket
>>>
>>> thanks!
>>>
>>> On Tuesday, August 13, 2013 12:20:48 PM UTC+2, Aymeric Augustin wrote:

 2013/8/13 Stefano Crosta 

> My proposal would then be to simply add another box to the 
> https://docs.**djangoproject.com/en/dev/ref/**settings/#installed-apps
>  to 
> say "order matters" once more and link the other two pages for 
> translations 
> and templates.
> *if you think this would* help I could do it as well as a ticket. To 
> save everybody's time no answer will mean it's not worth it!
>

 Yes, please file one, and include a link to this discussion.

 -- 
 Aymeric. 

>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

1. Progress: I've made improvements to admin checks. I've also finished
implementing filtering and silencing checks. I've rebased my branch against
master again.

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 less than two weeks (12 
days) +
one buffer week, because firm 'pencils down' date is September 23. Merging
django-secure in such little time is actually impossible -- we must through 
out
this task from schedule. I really apologize for that.

My plan is that this week I will work at documentation (at this moment 
there is
only a draft). I will also try to implement as much "nice to have" things as
possible. These are:

   - Writing tests which would be nice to have. I mean three tests:
  -   [#20974],
  -   test for raising error when ImageField is in use but Pillow is 
  not installed,
  -   test for raising error in `BaseCommand.__init__`.
   - Moving out checks performed in `__init__`.
   - Checking clashes between accessors and GenericForeignKeys.
   - Checks for grouped `choices`.
   
The second week and the backup week is for deep review. Regarding the amount
of comments I got during the first review, I guess I need *at least* one 
week
for deep review.

[#20974] https://code.djangoproject.com/ticket/20974

3. As I said, I've implemented both filtering and silencing system checks.

You can run only a subset of checks like that:

./manage.py check auth -t tag1 --tag tag2

This command will run only these checks which are labeled with `tag1` or 
`tag2`
tags and only `auth` app will be validated. If there is no app name, all 
apps
are checked. If there is no tag name, all checks are performed.

Your check function can be labeled in this way:

from django.core.checks import register, tag

@tag('mytag')
def my_check_function(apps, **kwargs):
# apps is a list of apps that should be validated; if None, all apps
# should be checked.
return []

register(my_check_function)

The `tag` decorator works only for entry-point functions, e.g. these one 
passed
to `register` function. It doesn't work for checks
functions/methods/classmethods which are called by entry-point functions
(directly or indirectly).

To silence a specific error/warning, you need to append its `id` to
SILENCED_SYSTEM_CHECKS setting. The `id` could be any string, but we use the
following convension: "E001" for core errors, "W002" for core warnings,
"applabel.E001" for errors raised by an custom app (including contrib apps, 
i.e.
"sites.E001"). The error/warning number is unique to an app, e.g. 
"sites.E001",
"admin.E001" and "E001" are all allowed, but "E001" and "W001" are not OK. 
You
should use "E001" and "W002". To create an error/warning with given id, 
pass it
as a keyword argument:

Error('Message', hint=None, obj=invalid_object, id='myapp.E001')

4. More important changes in code:

- Introduced RAW_SETTINGS_MODULE [1]. I use it in compatibility checks to 
test
  if `TEST_RUNNER` setting was overriden [2].

- Introduced `BaseAppCache.get_models_from_apps` method [3]. This method 
returns
  all models of given set of apps (or of all apps if None is passed) and is 
used
  in `default_checks.py` [4].

- Admin changes are backward compatible. Admin validators are deprecated in
  favour of admin checks, i.e. `BaseValidator` is deprecated in favour of
  `BaseModelAdminChecks`. `BaseValidator` is an almost empty class now.
  `ModelAdmin.validator` class attribute is deprecated in favour of new 
`checks`
  attribute. If an ModelAdmin defines `validator`, we are not ignoring it.

[1] 
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/conf/__init__.py#L139
[2] 
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/core/checks/default_checks.py#L33
[3] 
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/db/models/loading.py#L296
[4] 
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/core/checks/default_checks.py

5. I've left one comment on the pull request. (I mean this one about moving
registering admin checks to `autodiscover`.)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.