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.
Finally, I'd like if the renderer names were less verbose. Proposal:
django.forms.renderers.DjangoTemplates, Jinja2, TemplateEngines.
On Tuesday, December 20, 2016 at 3:00:11 PM UTC-5, Carl Meyer wrote:
>
> Sure, I guess Florian mentioned dropping Jinja2TemplateRenderer, but I
> don't really see a strong argument against keeping and documenting it.
> As you say, cost is low.
>
> Carl
>
> On 12/20/2016 11:55 AM, Tim Graham wrote:
> > I thought maybe that use case could be an argument for keeping the
> > Jinja2TemplateRenderer -- we need it for testing the Jinja2 templates
> > anyway, so it's not adding any maintenance overhead, it's just a matter
> > of whether it's public with docs or if it just lives in the tests.
> >
> > About the fate of 'POST_APP_DIRS' -- it seems the consensus among you
> > and Florian is to drop it. Fine with me.
> >
> > On Tuesday, December 20, 2016 at 2:26:33 PM UTC-5, Carl Meyer wrote:
> >
> > 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://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
>
> > <
> 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>
> > > <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>
> > > <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-develop...@googlegroups.com <javascript:>
> > > <mailto:django-developers+unsubscr...@googlegroups.com
> <javascript:>
> > <javascript:>>.
> > > To post to this group, send email to django-d...@googlegroups.com
> > <javascript:>
> > > <mailto:django-d...@googlegroups.com <javascript:>>.
> > > Visit this group at
> > https://groups.google.com/group/django-developers
> > <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>
>
>
> >
> > >
> > <
> https://groups.google.com/d/msgid/django-developers/6e011e39-2e25-4d61-975f-866bf4a6a2a3%40googlegroups.com?utm_medium=email&utm_source=footer
>
> > <
> 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
> > <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-develop...@googlegroups.com <javascript:>
> > <mailto:django-developers+unsubscr...@googlegroups.com <javascript:>>.
> > To post to this group, send email to django-d...@googlegroups.com
> <javascript:>
> > <mailto:django-d...@googlegroups.com <javascript:>>.
> > 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/2aa831a2-d435-49ba-9872-85422ea00e28%40googlegroups.com
>
> > <
> https://groups.google.com/d/msgid/django-developers/2aa831a2-d435-49ba-9872-85422ea00e28%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/a7dabf8d-69ce-4876-b587-e34079e3afe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
