About the fallback engines, the main use case I have in mind (as Claude alluded to) is if you want to use django.forms "standalone" without the rest of Django. In that case, it seems like it would be nice not to require someone to configure settings.TEMPLATES. Here's an alternate proposal:
Creating a "django.forms.renderers.templates.DefaultTemplateRenderer" (exact name to be discussed) which uses the fallback engines and ignores settings.TEMPLATES. This could be the default renderer for the FORM_RENDERER setting, for backwards-compatibility and to allow django.forms standalone usage by default. For more advanced uses, set the setting: FORM_RENDERER = 'django.forms.renderers.templates.TemplateRenderer' (which uses django.template.loader.get_template and doesn't have any fallback engines). On Tuesday, May 10, 2016 at 2:35:50 AM UTC-4, Aymeric Augustin wrote: > > I agree with Carl’s arguments about the fallback strategy (specifically, > the four paragraphs quoted below). > > -- > Aymeric. > > > On 10 May 2016, at 00:28, Carl Meyer <ca...@oddbird.net <javascript:>> > wrote: > > > > Yeah... so relatedly, you also mentioned in IRC and on GH that you don't > > see why we should deprecate the automatic fallback in case you don't > > have django.forms in INSTALLED_APPS and a loader with APP_DIRS=True. The > > answer to that, IMO, is that checking specifically for "django.forms in > > INSTALLED_APPS and APP_DIRS=True" is janky and inadequate, and I really > > don't think it belongs in there permanently. In fact I'm wondering now > > whether it even belongs in there temporarily as a deprecation path. > > > > The problem with that check is that there are various legitimate ways > > one could use the TemplateRenderer, and putting django.forms in > > INSTALLED_APPS and using a loader with APP_DIRS=True is only one of > > them. If you don't want to use APP_DIRS=True, it's also reasonable to > > put a separate engine in TEMPLATES pointing to the form templates (this > > might be a nicer solution for the Django test suite, for instance). Some > > people might even want to supply all their own form templates and not > > use any of the default ones, and that should be supported, too. By > > automatically overriding with our own fallback template engine if we > > don't detect "django.forms in INSTALLED_APPS and APP_DIRS=True", we > > effectively prohibit any other approach. I thought that might be OK as a > > temporary state of affairs during a deprecation path, but I definitely > > don't think it's OK permanently. > > > > I pushed an alternative approach in > > > https://github.com/carljm/django/commit/7d734cfb9da2f64e4bf59c55167c70748b3bd092 > > > that removes the INSTALLED_APPS checking. Instead, it has the `render` > > method unconditionally fallback to the built-in templates if a template > > is not found via the engines configured in TEMPLATES. > > > > I still think that in the long run, it's simpler and more predictable if > > the developer is simply responsible to either set up TEMPLATES such that > > the form templates needed are findable (startproject would set this up > > by default), or use a custom subclass of TemplateRenderer that does > > something entirely different. So I would still favor deprecating the > > fallback (in which case we should also update the startproject template > > so the fallback isn't needed for new projects). But I think this > > fallback is more flexible and simple enough that we could consider > > keeping it in place permanently, if you and others prefer that. > > -- 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/8e52e3c9-f7dd-4b78-9ba8-66fcc0a7f9e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
