Florian started a long discussion [0] on the pull request and concluded in him saying, "If we are going to promote the usage of ProjectTemplateRenderer (which I think we should), we probably should bite the dust and get rid of POST_APP_DIRS and in the same breath of the jinja renderer -- ie provide the Django renderer really only as backwards compat shim."
One concern I have is that if you want to ues ProjectTemplateRenderer and render Jinja2 widget templates but use Django templates elsewhere, then you have to put a Jinja2 backend first in TEMPLATES which means all your non-form widget template lookups have an additional cost of checking if the Jinja2 template exists. Does anyone have a sense if that would be a noticeable performance penalty? (and perhaps an argument against ProjectTemplateRenderer for a use case like that) [0] https://github.com/django/django/pull/6498#issuecomment-268120711 On Monday, December 19, 2016 at 5:53:23 PM UTC-5, Tim Graham wrote: > > It's ready for review: > > Add 'POST_APP_DIRS' TEMPLATES option. > https://github.com/django/django/pull/7693 > Template based widget rendering: > https://github.com/django/django/pull/6498 > > On Wednesday, December 14, 2016 at 6:59:16 PM UTC-5, Tim Graham wrote: >> >> I don't have any strong objections at this point, just wanted to think it >> through and offer possible alternatives. If there's no further input, I'll >> finish adding tests and docs for the TEMPLATES 'POST_APP_DIRS' option >> tomorrow, after which I think the widget rendering patch will be ready for >> final reviews. >> >> On Wednesday, December 14, 2016 at 6:40:36 PM UTC-5, Carl Meyer wrote: >>> >>> 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/29979449-8bc8-4e49-8878-fefe34e04385%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
