I think that a) wanting render forms via Jinja and everything else via DTL, and b) caring about the perf impact of checking two engines is an edge case, and a great reason to have the full flexibility of the form renderers system. When we say "promote the usage of ProjectTemplateRenderer", I think we mean as the most flexible and least surprising option for most projects that just want Things To Work, not that it will always meet everyone's needs. If you have more specific needs, you can always write a form renderer that meets them.
Carl On 12/20/2016 11:16 AM, Florian Apolloner wrote: > One option would be to introduce a new PREFIXES option in the template > engine settings which ignores template paths not starting with one of > those prefixes (if they are set). That said I didn't bother checking for > performance issues, I know that the cached loader in Django will also > cache if it doesn't find anything, ie it will not do extra I/O for > non-existing templates (after the initial round). As far as I understand > the Jinja2 code, non-existing file are extra I/O every time, so that > might be something to consider. > > Cheers, > Florian > > On Tuesday, December 20, 2016 at 7:34:21 PM UTC+1, Tim Graham wrote: > > 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 > > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F6498%23issuecomment-268120711&sa=D&sntz=1&usg=AFQjCNH6pYlfIAgKUN59fcVGOTnZ7FikCw> > > 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 > <https://github.com/django/django/pull/7693> > Template based widget rendering: > https://github.com/django/django/pull/6498 > <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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto: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/6e011e39-2e25-4d61-975f-866bf4a6a2a3%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/6e011e39-2e25-4d61-975f-866bf4a6a2a3%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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/3ef6b57e-d252-ff70-465e-8d237a44a762%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
