Hi Tim, On 12/14/2016 12:50 PM, Tim Graham wrote: > My thinking is that there should typically be only one directory in each > project that overrides built-in templates, otherwise if multiple apps > provide overrides, they'll stomp on each other when using the > app_directories loader.Are your projects usually set up that way? Using > the app_directories loader eases setup but adds a cognitive overhead of > figuring out where the template overrides are coming from.
All of these seem like generic objections to APP_DIRS / the
app_directories loader, which has been around in some form (and been the
default behavior) effectively forever. For better or worse, we have a
template system that layers multiple loaders in the same template
namespace and allows them to stomp on each other, and leaves it up to
you to figure it out if they do. This does give people some rope to
create confusion, but it's also powerful and flexible, and so far we've
decided that tradeoff is worth it. How is any of this specific to form
templates?
> If you feel
> the ship has sailed and the pattern of putting the main "project" module
> in INSTALLED_APPS to get "project-level" templates rendered should be
> endorsed, then I guess we'll do that.
I think some kind of "project" or "core" app is in practice pretty
common (e.g. it also becomes necessary if you want "project-level"
management commands, or DTL template tags, or...). I'm sure it's not
universal; I don't think there's anything wrong with it, or anything
wrong with not doing it. And I don't think that any decision we make
here needs to imply an endorsement of one approach or the other.
I understand that in my proposed default setup, if a project relies on
DIRS for their project-level templates, they won't be able to override
form templates along with the rest of their project-level templates;
they'll either need to switch to the ProjectTemplateRenderer or put
their form override templates in an app. That's not ideal, but I think
it's still a reasonable set of options (I'd probably go for
ProjectTemplateRenderer in that situation -- "if you want project
templates to override form templates, use ProjectTemplateRenderer" seems
reasonable). While I agree this is a wrinkle, I don't think this wrinkle
is a good rationale for making it impossible to override built-in form
templates from an app in the default setup.
If you disagree with that, though, I could live with with just saying to
everyone "if you want to override form templates, use
ProjectTemplateRenderer" -- it's not that hard to switch to
ProjectTemplateRenderer.
I would not be in favor of the FORM_TEMPLATE_DIRS setting. It adds a
brand-new concept and setting, which would typically be set to the same
value as your template DIRS in the common case, without really gaining
any flexibility or much ease-of-use compared to just switching to
ProjectTemplateRenderer.
Carl
> An alternative could be an additional setting to declare the
> "project-level" templates directory. That would allow overriding
> built-in and third-party app templates without create a "project" app.
> For example, the engine for the DjangoTemplateRenderer would look like:
>
> def engine(self):
> dirs = [os.path.join(ROOT, 'templates')]
> if settings.FORM_TEMPLATES_DIR:
> dirs.insert(0, FORM_TEMPLATES_DIR)
> return DjangoTemplates({
> 'APP_DIRS': True,
> 'DIRS': dirs,
> 'NAME': 'djangoforms',
> 'OPTIONS': {},
> })
>
> This loading order makes it impossible for apps to override the built-in
> templates unless that app is pointed to by FORM_TEMPLATES_DIR. You
> couldn't easily do further customizations of built-in templates without
> copying that app's templates into a new directory and pointing
> FORM_TEMPLATES_DIR at it, then editing those templates or adding new ones.
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/cac98bf1-4f8c-be8a-8f7b-1ff95d627c24%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
