+1 to overridable function. Subclassing the whole Engine would be somewhat
cumbersome to just set up errors for invalid variable cases.
Dne neděle 24. ledna 2021 v 18:20:58 UTC+1 uživatel tim.mc...@gmail.com
napsal:
> I was going to have a go at this ticket (
> https://code.djangoproject.com/ti
I was going to have a go at this ticket
(https://code.djangoproject.com/ticket/28526) - which links this thread.
Having read the various replies, it seems like there is no shortage of
differing views how missing/invalid variables should be treated:
- There should be no logging
- There should
If anyone is interested, I've cleaned the errors in admin templates:
Ticket: https://code.djangoproject.com/ticket/28529
PR: https://github.com/django/django/pull/8973
The fixes are quite simple. The biggest problem is sometimes to find out,
in which template the bug actually appears.
Vlastik
Apparently there is number of errors in admin templates. I suggest to fix
the templates. I my experience, the most cases are missing if statements or
missing context variables. These can be fixed very easily and produce
cleaner templates. I consider this much better solution than just ignoring
I used to do that too (string_if_invalid that raises an exception). What
was nice about this, is you could explicitly wrap the variable in an if tag
to silence the error if you were ok with it. (I'm not sure if this behavior
is still true.)
{% if var_that_sometimes_exists %}{{ var_that_sometimes_e
As an anecdotal data-point: at the company I'm working at, we are running
Django with a custom object as "string_if_invalid" that raises an exception
on string-interpolation. This way missing template variables *do* get
converted to an exception. I myself am very happy with this solution, as it
We received a report that shows the large number of undefined variable
warnings when rendering an admin changelist page [0].
I'm still not sure what the solution should be, but I created #28526 [1] to
track this problem: finding a remedy to the problem of verbose, often
unhelpful logging of un
-1 for removing logs. Like Vlastimil, it's helped me spot a couple of stray
bugs.
What I'd actually like to see is this becoming stricter, with the end goal
of errors raising when using undefined variables.
For the verbosity, perhaps there's a middle ground? only log once per
variable access per
-1 to the removal. I was annoyed by the logging at first, but then I
started to clean individual logs. Half way through, I found several usages
of long removed variables, one unused template (as a side effect) and I
updated several views to always provide defined context variables.
All in all,
On Thursday 16 March 2017 12:03:07 Tim Graham wrote:
> Ticket #18773 [0] added logging of undefined template variables in
> Django 1.9 [1], however, I've seen several reports of users finding
> this logging more confusing than helpful.
With channels hitting 2.0 and the already large stack of movi
My general policy is that warnings should only be logged if there is a
good way to silence them. A good way means:
1) fix the bug which is causing them (only applies if there is genuinely
a bug or bad practice that should be fixed)
2) disable the warning in a fine tuned way i.e. you can indic
Doesn't sound like there's much impetus either way, and it's confusing
people, so I'd say remove it. Or maybe make it optional, default off?
On 19 March 2017 at 07:52, Tim Martin wrote:
> I don't have any objection to removing this. However, the thought occurs
> that my patch to the handling of
I don't have any objection to removing this. However, the thought occurs
that my patch to the handling of undefined variables could enhance this to
make it more useful. I think we could log in the case where a conditional
expression actually depends on an undefined variable. I haven't thought
a
13 matches
Mail list logo
