On Mon, Jan 12, 2015 at 10:28 AM, Carl Meyer <[email protected]> wrote:
> Hi Russ,
>
> On 01/11/2015 05:20 PM, Russell Keith-Magee wrote:
> >> Without having spent much time to research the consequences — it's on my
> >> TODO list but Collin brought it up before I investigated — my straw man
> >> proposal is:
> >>
> >> TEMPLATES = [
> >> {
> >> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> >> 'DIRS': [],
> >> 'APP_DIRS': True,
> >> 'OPTIONS': {
> >> 'context_processors': [
> >> 'django.template.context_processors.debug',
> >> 'django.template.context_processors.request',
> >> 'django.contrib.auth.context_processors.auth',
> >> 'django.contrib.messages.context_processors.messages',
> >> ],
> >> },
> >> },
> >> ]
> >>
> >
> > Given that tz and i18n aren't doing anything significant, and
> media/static
> > aren'tt doing it right, this list makes sense to me as defaults.
> >
> > In my ideal world, we wouldn't need to specify these at all in the
> settings
> > file - I'd almost propose that the Django template engine should have
> those
> > context processors baked in by default, unless manually specified by the
> > end user (i.e., if 'context_processors' in OPTIONS:). The goal of the
> > simplification of the project template was to get all the extra cruft out
> > of a default working template; having a bunch of boilerplate that
> many/most
> > new users won't need to modify seems like a step backward in that regard.
>
> On the other hand, there are some significant disadvantages to having
> non-empty default values for list settings:
>
> 1) Less explicit - things show up in the template context and new users
> have no idea where they might have come from.
>
> 2) As soon as you want to add a context processor, you have to find the
> docs or `global_settings.py` and copy-paste the default value in, and if
> you don't know that that's necessary it may not be obvious what you
> broke or how to fix it.
>
> I sympathize with the goal of a less-crufty default project template,
> but in this case I find the argument for "explicit is better than
> implicit" more compelling. It just makes sense that the default settings
> for a template engine wouldn't magically add anything to the template
> context.
>
I agree with both these comments - hence my "almost propose" and "ideal
world" qualifiers. I mentioned the idea purely to point out the conflict
between the "simpler template" and "more explicit" goals of the project
template (with the added irony that the core dev who simplified the
template is also the one making it more complex :-)
Ultimately, I think you're right - explicit > implicit is a good argument.
However, I would have made the same argument about some of the values that
were taken out of the original project template. For more irony - the
removal of TEMPLATE_CONTEXT_PROCESSORS was the one that bugged me most from
the original template cleanup :-)
Russ %-)
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAJxq84986AE4X%3DdNCk22fQ0tGUduCfc0Ry9xpO9Yjasb2fKu6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
