On Tue, Oct 18, 2011 at 5:21 PM, Rich Jones <miser...@gmail.com> wrote:
> Hey guys! > > So I've just written a blog post about getting started with Django, > http://gun.io/blog/python-for-the-web/, and many of the things here > just make me think, 'why doesn't it just do that by default?' > > Here's some of what I propose. I'm not suggesting this be a canonical > list of features by any means, I'm just suggesting that django have > more convenient default settings. We should look at the most common > conventions and best practices and shape the defaults towards them. > > Anyway, I propose that: > > django-admin.py startproject newproj > > should create ./static, ./uploads and ./newproj and ./newproj/ > templates > I personally +1 on the ./static and ./uploads. I like a starting point for putting the static files and the uploaded files. If you don't use static files or uploaded files, it'll never get used and deleting a folder is pretty easy. For consistency, I'd rename ./uploads to ./media (to match the MEDIA_ROOT notation used in settings.py). I'd also fill-in MEDIA_URL ('/media'), MEDIA_ROOT, and STATIC_ROOT to work out of the gate. Is there a way to statically serve the MEDIA_ROOT folder to '/media/' without collectstatic collecting it and/or findstatic finding it by default? > > in ./newproj/settings.py.. > > import os > TEMPLATE_DIRS = ( > os.path.join(os.path.dirname(__file__), 'templates'), > ) > > +1 for something to accomplish this. I personally don't care how it's done. > and at the end, the commonly used from local settings import * block. > -1 'from <module> import *' should always be avoided. You never know what can happen down the road that you may override later. > > I'd also suggest that django-admin.py startproject newapp, if > possible, add the new application to the settings.py file if it can be > done so safely. > -1 I can see why this seems like a good idea, but I agree that I don't want anything touching my settings file. I also think people should learn how to start a new app and about manage.py, startapp seems like the obvious answer from a teaching perspective. > > I would also suggest that when making a new application, the most > commonly used imports are already there in the py files > (render_to_response, HttpResonse, get_object_or_404, etc). > > -1 If the exception wasn't so blatently obvious and worded well in the error, I might agree. > Who's with me? :) > > R > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > I also want to add another change. Put TEMPLATE_CONTEXT_PROCESSORS in the settings.py. I would just it rather be more explicit that you may be using these things. If there's any other settings like this that 'slide' a default value in w/o your knowledge, I'd like it to add to the settings.py by default. Most problems I have helping people is a default value that's not explicitly done in the settings.py, so people don't realize it's something they can override (or may need to). My criteria would be anything that could require modification (within reason) when adding or removing an app to make the app work properly. (See TEMPLATE_CONTEXT_PROCESSORS as an example.) -- Joe & Anne Tennies tenn...@gmail.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
