Re: Template handling of undefined variables

On Wednesday, 1 March 2017 19:52:22 UTC, Luke Plant wrote: > > > This is a really big backwards incompatibility, as far as I can see. It > means that any filter may now get passed `UndefinedVariable` instead of > being passed `None` or string_if_invalid. So for example, the following > templat

Re: Template handling of undefined variables

On 01/03/17 01:53, Tim Martin wrote: On Tuesday, 28 February 2017 13:39:21 UTC, Luke Plant wrote: On 28/02/17 15:24, Marten Kenbeek wrote: What about adding a filter |definedthat returns True if a variable is defined, False otherwise? It may not solve any problems when it's

Re: Template handling of undefined variables

In the context of template variable interpolation i.e. `{{ }}` syntax, it is defined that `x` in this case will get converted to the empty string (or your 'string_if_invalid' setting) - https://docs.djangoproject.com/en/dev/ref/templates/api/#how-invalid-variables-are-handled

Re: Template handling of undefined variables

On Monday, 27 February 2017 10:43:02 UTC, Luke Plant wrote: > > > > On 05/01/17 02:39, Tim Martin wrote: > > 2) There appears to be an inconsistency in the default_if_none >modifier. If I have a template with > >x|default_if_none:y = {{x|default_if_none:y}} >{% if x|default_if_none:y

Re: Template handling of undefined variables

On Tuesday, 28 February 2017 13:39:21 UTC, Luke Plant wrote: > > > > On 28/02/17 15:24, Marten Kenbeek wrote: > > What about adding a filter |defined that returns True if a variable is > defined, False otherwise? It may not solve any problems when it's left > implicit, but at least it allows us

Re: Template handling of undefined variables

On 28/02/17 15:24, Marten Kenbeek wrote: What about adding a filter |definedthat returns True if a variable is defined, False otherwise? It may not solve any problems when it's left implicit, but at least it allows users the explicitly define the behaviour for non-existing template variables,

Re: Template handling of undefined variables

What about adding a filter |defined that returns True if a variable is defined, False otherwise? It may not solve any problems when it's left implicit, but at least it allows users the explicitly define the behaviour for non-existing template variables, and it makes the intention of the templat

Re: Template handling of undefined variables

On Sunday 26 February 2017 11:16:54 Florian Apolloner wrote: > As much as I'd like variables to raise an error if they cannot resolve, I > am with Karen here -- the backwards compatibility considerations should > take priority here. At least we should have a possibility in the templates > to check

Re: Template handling of undefined variables

On 05/01/17 02:39, Tim Martin wrote: 2) There appears to be an inconsistency in the default_if_none modifier. If I have a template with x|default_if_none:y = {{x|default_if_none:y}} {% if x|default_if_none:y %} x|default_if_none:y is apparently True {% endif %} with y define

Re: Template handling of undefined variables

On 26/02/17 00:44, Karen Tracey wrote: On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham > 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, co

Re: Template handling of undefined variables

As much as I'd like variables to raise an error if they cannot resolve, I am with Karen here -- the backwards compatibility considerations should take priority here. At least we should have a possibility in the templates to check if variables are undefined before we start raising exceptions. Ch

Re: Template handling of undefined variables

On Sat, Feb 25, 2017 at 8:21 PM, Fred Stluka wrote: > 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. > I disagree, unless you are limiting this change specifically to argu

Re: Template handling of undefined variables

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 reviewin

Re: Template handling of undefined variables

On Saturday 25 February 2017 16:28:17 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 except

Re: Template handling of undefined variables

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 rai

Re: Template handling of undefined variables

On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham 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 w

Re: Template handling of undefined variables

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. On Saturday, Febr

Re: Template handling of undefined variables

Actually, I can imagine that the option might be worth keeping permanently. I think both the "exception on use of undefined" and "treat undefined as different from all other objects" would both be valid modes. Treating undefined as None is probably only justifiable for backward compatibility, t

Re: Template handling of undefined variables

+1 to not having to add (and then remove later) a {% load %} tag to every template - that was seriously dull with the URL change. Marc On 20 February 2017 at 11:42, Luke Plant wrote: > On 19/02/17 12:55, Adam Johnson wrote: > > +1 for more obvious errors, silently changing the behaviour could i

Re: Template handling of undefined variables

On 19/02/17 12:55, Adam Johnson wrote: +1 for more obvious errors, silently changing the behaviour could indeed lead to unconsidered security holes like {% if user is None %} non-sensitive information {% else %} sensitive information {% endif %} ...which doesn't seem like an unrealistic templa

Re: Template handling of undefined variables

+1 for more obvious errors, silently changing the behaviour could indeed lead to unconsidered security holes like {% if user is None %} non-sensitive information {% else %} sensitive information {% endif %} ...which doesn't seem like an unrealistic template snippet. We all know variables can go m

Re: Template handling of undefined variables

After reviewing the pull request, I wonder if it would be better to raise exceptions when comparing nonexistent variables in {% if %} rather than altering the behavior. For existing projects, this would prevent possible inadvertent information leakage if some {% if %} starts evaluating differen

Re: Template handling of undefined variables

On Friday, 6 January 2017 10:15:22 UTC, Alasdair Nicol wrote: > > Hi, > > On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote: >> >> >> >> On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote: >>> >>> Hi Tim, >>> >>> On 01/04/2017 03:39 PM, Tim Martin wrote: >>> >>> > 1) There are

Re: Template handling of undefined variables

> > I apologise if adding the tests has made it harder to improve the > behaviour of the tag. I don't think you have anything to apologise for! More tests is always better. This has clarified the current behaviour 👌 On 6 January 2017 at 10:15, Alasdair Nicol wrote: > Hi, > > On Thursday, 5 Jan

Re: Template handling of undefined variables

Hi, On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote: > > > > On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote: >> >> Hi Tim, >> >> On 01/04/2017 03:39 PM, Tim Martin wrote: >> >> > 1) There are test cases where we have templates that should treat "x >> >is y" as True

Re: Template handling of undefined variables

On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote: > > Hi Tim, > > On 01/04/2017 03:39 PM, Tim Martin wrote: > > > 1) There are test cases where we have templates that should treat "x > >is y" as True where x and y are both undefined. > > Really? Is this an accidental side effe

Re: Template handling of undefined variables

Hi Tim, On 01/04/2017 03:39 PM, Tim Martin wrote: > I've been looking at bug #24977 (Template variables with a value of > None are considered to be == to non-existent properties). ... > The suggestion on the ticket is to use an instance of a special > `Undefined` class to indicate an undefined var

Template handling of undefined variables

Hi all, I've been looking at bug #24977 (Template variables with a value of None are considered to be == to non-existent properties). The problem is that in a template: {% if user.pk == some_object.invalid_property %} ... this gets rendered when the user is logged out {% endif %} This is because