I'm not sure about how common the need for custom widget templates are. Speaking for djangoproject.com and a few other small projects I maintain, I don't think these projects would make use of them but maybe if the feature is there, I might realize it would help in some places.
What's your proposal for changing the default TEMPLATES? Using Jinja2 or DTL? Since others have supported the idea, feel free to push your ideas to the branch -- I won't be working on that branch for the rest of today. On Tuesday, May 10, 2016 at 2:22:14 PM UTC-4, Carl Meyer wrote: > > Hi Tim, > > On 05/10/2016 07:10 AM, Tim Graham wrote: > > 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). > > Yeah, I considered this (my first version of my commit actually had two > different renderer classes like this). My concern is that I think this > proposal has the default backwards for what will actually be typical > usage. In my experience of using templated widgets for the last several > years (via django-floppyforms), the biggest value is the ability to > override specific widget templates with your own templates. So I think > overriding templates (within a normal Django project with TEMPLATES > configured) is the "basic usage" and standalone use of the forms library > is an "advanced use," not the other way around. > > The proposed "DefaultTemplateRenderer" doesn't allow any template > overriding at all, because it can _only_ load the built-in templates. I > think in the long run it would be a mistake to have the default > FORM_RENDERER setting be a renderer that doesn't allow easily overriding > templates, and I don't think that we should allow the transition > concerns to override reaching the right long-term solution after a > transition path. > > 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/18c63161-f3de-44d5-aa4e-c91e3b63ec8b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
