On 12/20/2016 01:26 PM, Tim Graham wrote: > Okay I removed 'POST_APP_DIRS' from the PR. > > Next, we should discuss whether or not to make the ProjectTemplate > renderer the default FORM_RENDERER in the startproject template. (For > backwards compatibility, DjangoTemplateRenderer has to be the default in > global_settings.py.) > > Florian said: > > the first question in IRC I (and everyone else in IRC) will have to > answer for weeks will be: > I have a nice context_processor where I specify the theme (color) of > my material design template, why is the variable not in the templates > for widgets, after all it is in the same template directory. > I am already using django-sniplates via libraries in the TEMPLATE > config, as migration step I want to reuse that for the widgets, why are > they not getting picked up. > > Carl said: > > "the best we can do to address the support concern that may arise once > people start to use custom widgets and wonder why their TEMPLATES config > doesn't apply, is to clearly document that if you're creating custom > widgets that need custom template features, you should upgrade to > ProjectTemplateRenderer. (And we should update startproject to use > ProjectTemplateRenderer, so this support concern is a temporary thing > during the upgrade timeframe only.)" > > I feel these concerns may be overstated. I think custom template widget > rendering won't be high on the list of things that Django beginners are > looking to do and different values betwen "setting default" and > "startproject default" causes confusion too. If we do make the addition, > I guess 'django.forms' would be added somewhere in INSTALLED_APPS also.
Yes, it would mean adding django.forms to INSTALLED_APPS as well. Personally, I'm totally fine with deferring this decision until we see how the default DTL renderer plays out in practice, and whether it does cause confusion with people trying to build custom widgets. I do think it'd be good to add to the DjangoTemplates renderer docs, noting specifically that if you are using this renderer your custom widget templates will use a "stock" DTL engine and won't have access to any template engine customizations in your TEMPLATES setting, and recommend ProjectTemplateRenderer if you need the latter. > Finally, I'd like if the renderer names were less verbose. Proposal: > django.forms.renderers.DjangoTemplates, Jinja2, TemplateEngines. +1. The first two names are fine with me, not sure about TemplateEngines. It seems kinda generic and unclear: all of the renderers use "template engines" in one way or another. What about "ProjectTemplates"? "ConfiguredTemplates"? 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/5d2bed65-88cf-5ab8-4f75-cdc61ef2b7b6%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
