Hi Tim, On 11/16/2016 06:23 AM, Tim Graham wrote: > I took a stab at backwards-compatibility with respect to allowing the > admin to work without adding 'django.forms' to INSTALLED_APPS. It seems > to work for at least the simple TEMPLATES = 'BACKEND': > 'django.template.backends.django.DjangoTemplates', ...} case, although > I'm not proud of the code and I'm nervous it's a bit fragile. What do > you think of the approach?
I have similar concerns about fragility, as well as the behavior being complex and hard to keep a clear mental model of. I went back and re-read this thread and took a fresh approach to the problem, trying to adhere to "keep the easy things easy, make the hard things possible" and keep the behavior as explicit as possible. Here's what I came up with, let me know what you think: We provide three built-in template renderer classes: 1. The default FORM_RENDERER is DjangoTemplateRenderer. It does not use settings.TEMPLATES/get_template(), but constructs its own DTL template engine. This engine has APP_DIRS=True, and automatically inserts the built-in form templates directory _after_ the app dirs. (This will require a subclass of the normal DTL Engine class that overrides the template_dirs property, because DIRS takes priority over APP_DIRS, so the default Engine has no way to specify a directory that has lower priority than APP_DIRS. But I don't think needing this subclass is a problem, and I do think it's important that out of the box you can override the default form templates, as well as adding your own; this latter of course is needed for the admin.) 2. We also provide JinjaTemplateRenderer, which is just like DjangoTemplateRenderer, except it uses Jinja. (I.e. we get rid of the "automatically use Jinja2 if it's installed" behavior of the StandaloneTemplateRenderer in the current PR, and instead split into two different renderers for DTL vs Jinja. Magically changing behavior just because something is installed is bad. The choice to use Jinja should be explicitly configured, not automatic when you install it.) 3. Lastly, we provide ProjectTemplateRenderer (name up for bikeshedding), for those who want form template rendering to use their overall project templating settings, as defined in TEMPLATES. This renderer just uses the stock get_template() function. If you choose to switch to this renderer, you will need to either put 'django.forms' in INSTALLED_APPS (and have at least one engine with APP_DIRS=True), or add the forms directory in DIRS of one of our engines, or supply all the form templates you need yourself, or whatever. You've chosen to take full control, so it's your responsibility to make the form templates you need are available. I think this meets all the requirements: The default renderer is backwards-compatible with no settings changes, and does not require Jinja2, but it still allows overrides/additions of widget templates. It's also standalone-compatible, in that it is self-contained and has no dependency on TEMPLATES config. Switching to Jinja2 is just a six-character change to your FORM_RENDERER setting. If you want complete control of how your widget templates are sourced, switch to ProjectTemplateRenderer. And of course you can always write your own renderer class if you need even more control than that. Anything I missed? Carl I thought I'd try something to get the > conversation going again. I've been reacting to some tickets based on > the assumption that this will get into 1.11 so I'd like to make it happen. That would be great. Carl -- 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/7b4d51f5-6f48-acb5-a3bf-802cf7a8ea1f%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
