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 -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5644C38E.8030804%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
