On 11/12/2015 09:22 AM, Tim Graham wrote:
> The expected behavior of the {% if %} tag isn't clear to me. How do you
> propose to solve the "bug"? As I noted in the ticket:
>
> We end up checking {% if <string_if_invalid> %} which passes for a
> non-empty string_if_invalid. I'm not sure we should add special handling
> of RelatedObjectDoesNotExist in the template engine to restore the old
> behavior (and I'm not sure how to since RelatedObjectDoesNotExist is a
> dynamically generated exception based on the related descriptors).
RelatedObjectDoesNotExist inherits from ObjectDoesNotExist, so we could
catch ObjectDoesNotExist, I suppose. It is possible to construct a
rationale for that: "an object that does not exist should evaluate to
false." But I'm not sure I buy that rationale; I don't like adding more
ad-hoc differing handling of particular exception types in the template
engine.
A better option for resolving this might be to have a dedicated Invalid
type which always evaluates to false in boolean context, but renders
itself as TEMPLATE_STRING_IF_INVALID if asked to coerce to a string.
I guess it could be arguable whether Invalid should be truthy or falsy,
but at least that way it would always be consistent, not dependent on
TEMPLATE_STRING_IF_INVALID.
Carl