I'd like the settings file to be more convenient too, but most of the
suggestion are too specific.
It's an excellent idea to automate more things, but it's a really bad
idea to pretend that we know
everybody's needs.
Personally here's what I'd like to see in the generated settings.py:
import os
PROJECT_PATH = os.path.dirname(os.path.abspath(__file__))
...
MEDIA_ROOT = os.path.join(PROJECT_PATH, 'media/')
...
TEMPLATE_DIRS = (
os.path.join(PROJECT_PATH, 'templates/'),
)
This would already be a big time saver.
Another things that would be nice is commonly used code like
TEMPLATE_CONTEXT_PROCESSORS,
some middlewares and apps being commented. This wouldn't hurt anybody
I think.
About adding stuff to views or other files generated by starapp or
startproject .. -1. I think the bare minimum is a win for everybody.
That said, it would be nice to let people write their own templates
for thoses files. Startapp and startproject could look for them
in a path like $USER/.django/templates/newapp/ or $USER/.django/
templates/newproject/ and/or let startapp/startproject accept
a --templates argument to make something like this possible:
python manage.py startapp myapp --templates=/some/path/templates/
newapp/
python manage.py startproject myproject --templates=/some/path/
templates/newproject/
my 2¢
On Oct 18, 9:20 pm, "Joe & Anne Tennies" <tenn...@gmail.com> wrote:
> 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.
