Re: For discussion: JSON-aware views for error responses

2022-04-22 Thread vanadium23
I've done some work long ago. May be will help for someone.
https://github.com/django/django/pull/8947

On Friday, 22 April 2022 at 08:53:56 UTC+3 Tobias Bengfort wrote:

> +1 from me.
>
> On 14/04/2022 11.03, Ville Säävuori wrote:
> > And to be clear, I understand we already have middleware APIs and 
> > various settings to handle this but my point is that I think handling 
> > this in Django core (even as an optional setting or middleware) would be 
> > most useful and right way to do this for the community.
>
> Can you provide some examples? I support the general idea, but having 
> some concrete APIs to discuss might be helpful.
>
> thanks
> tobias
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/744c3b96-4c42-4eac-a451-5c6f6da446fdn%40googlegroups.com.


Re: Improvements to the startproject template

2022-04-22 Thread Tim Allen
Thanks for the excellent feedback, folks. It does sound like we've built a 
consensus for merging this PR, with other iterative improvements possible 
later. I like the template idea, but also know that the vast majority of 
newcomers are going to go with the default.

Once I get the go-ahead from someone with Merger permissions, I'll go ahead 
and make the changes necessary to the documentation (such as the Tutorial) 
so we can complete this.

On Thursday, April 21, 2022 at 6:01:17 PM UTC-4 pyt...@ian.feete.org wrote:

> I want to add that I think either proposed change here would be an 
> improvement and that I'd prefer not to see this idea die because of 
> bikeshedding over the best option.
>
> Regards,
> Ian
>
> On Thu, 21 Apr 2022 at 19:21, ome chukwuemeka  wrote:
>
>> I think this is a good suggestion!
>>
>> On Thu, Apr 21, 2022, 7:08 PM Albert  wrote:
>>
>>> It is possible to do in current version of Django with two lines of code:
>>>
>>> mkdir my_project
>>>
>>> django-admin startproject config my_project
>>>
>>> I have been working for many companies that use Django and I have seen 
>>> that each ot them has their own structure of project. 
>>>
>>> And usually project is created once per couple of months, so I don't see 
>>> advantages of changing project structure.
>>>
>>> Regards,
>>>
>>> Albert
>>>
>>> Temat: Re: Improvements to the startproject template 
>>>
>>> As there are different preferences and some see the change as worse than 
>>> the default and there is already a way to change the template for 
>>> startproject, wouldn't it be easier to provide different templates and list 
>>> them in the documentation, so that they can be used with the --template 
>>> argument? With a short section about each template and the pros and the 
>>> cons, and for what kind of project one is better suited.
>>>
>>> Maybe the three top templates could be shipped directly with django, so 
>>> that users could choose one with --template=simple, --template=nested or 
>>> --template=config or something in that direction.
>>> On Thursday, April 21, 2022 at 11:16:23 AM UTC+2 ator...@redhat.com 
>>> wrote:
>>>
 I personally dislike Adam's suggestion and feel like it makes it worse 
 than the current default, but to each their own.

 I do prefer the proposed solution of the config directory, I am working 
 on two django projects in parallel and one follows the proposed config 
 scheme and the other doesn't (uses the default) and I find the proposed 
 config scheme more natural to use and navigate, so that's a +1 from me too

 On Thursday, April 21, 2022 at 5:10:06 AM UTC+2 pem...@gmail.com wrote:

> For what it's worth, this is the (general) layout I've used for the 
> past 8+ years of my professional Django development.
>
> Arthur
>
> On Wed, 20 Apr 2022 at 15:22, Olivier Dalang  
> wrote:
>
>> +1 for Adam's suggestion, I use it as well and like it very much.
>>
>> > root folder
>> - manage.py
>> - ...
>> > myproject
>> - __init__.py
>> - settings.py
>> - urls.py
>> - ...
>> > myapp
>> - __init__.py
>> - models.py
>> - ...
>>
>> Pros:
>> - everything is well namespaced under myproject 
>> (`myproject.settings`, quite straightforward)
>> - makes it clear that `settings.py`, `urls.py`, etc. concern the 
>> project as a whole, and not just an app.
>> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it 
>> clear that myapp is part of this project)
>> - it leaves the root level for stuff like .gitignore, db.sqlite, etc, 
>> so the actual source stays clean from such files.
>> - having a parent package allows (does not require) relative imports 
>> across modules of the same project, which more clearly conveys that such 
>> apps are tightly coupled
>> - with manage.py still in the root folder, you don't need to cd into 
>> any folder to start working
>>
>> I use it all the time.
>>
>> Cheers,
>>
>> Olivier
>>
>>
>>
>>
>> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>>
>>> I prefer Adam's suggestion in the forum post as it lets you 
>>> namespace everything under your project name nicely and avoids package 
>>> name 
>>> collisions, although it doesn't solve the problem of having two 
>>> directories 
>>> with the same name by default.
>>>
>>> That said, either would be an improvement on what we have so I'm in 
>>> favour of either approach over doing nothing.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Wed, 20 Apr 2022 at 16:49, John M  
>>> wrote:
>>>
 I do exactly this for every new Django project, so it's +1 from me 
 as well.

 John
 On 20/04/2022 12:01,