Tim and others,
+1 for raising an exception.
Specifically...
I agree that use of undefined variables should raise an exception.
The incompatibility with previous versions will mostly catch errors
that have been going undetected.
Personally, I find it very hard to detect such bugs when reviewing
code written by myself or other team members, especially since we
make heavy use of template inheritance, and we reuse the same
templates from multiple views. So, it's not easy to spot a case
where we forgot to pass a value to a template.
I think Django should at least offer this as an option.
--Fred
------------------------------------------------------------------------
Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
------------------------------------------------------------------------
On 2/25/17 7:28 PM, Tim Graham wrote:
My proposal was only for the use of undefined variables in template
tags. I didn't realize that the behavior of undefined variables in
some tags resolving to None is documented, but I still think it's a
useful change to raise an exception instead. The philosophy that
template tags shouldn't raise exceptions is more unhelpful than
helpful in my experience. I think the change would be consistent with
the deprecation that starts in Django 1.11 to change {% include %} not
to silencing exceptions and render an empty string, for example.
On Saturday, February 25, 2017 at 4:44:30 PM UTC-5, Karen Tracey wrote:
On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham <timog...@gmail.com
<javascript:>> wrote:
I think any use of undefined template variables should raise
an exception. In the long run, keeping a setting to allow some
other behavior seems confusing and, considering the case of
templates that might be reused in different projects with
different settings, even dangerous.
I think I'm confused...Django templates have allowed use of
undefined variables and documented their use as evaluating to the
empty string for as long as I recall. Wouldn't a change to instead
raise exceptions be a major backwards-incompatibility?
https://docs.djangoproject.com/en/1.7/topics/templates/#variables
<https://docs.djangoproject.com/en/1.7/topics/templates/#variables>
said "If you use a variable that doesn’t exist, the template
system will insert the value of the TEMPLATE_STRING_IF_INVALID
setting, which is set to '' (the empty string) by default."
https://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables
<https://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables>
has refined that doc to note that the behavior is slightly
different in some tags.
Are we really considering changing this behavior to now raise
exceptions?
--
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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-developers@googlegroups.com
<mailto: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/8b260b00-7921-4977-9521-f61f073e717b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/8b260b00-7921-4977-9521-f61f073e717b%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/8ff7366a-b8ba-5ac3-566d-6e6258e4ed81%40bristle.com.
For more options, visit https://groups.google.com/d/optout.
