Jacob Kaplan-Moss wrote:
> On Sat, May 17, 2008 at 11:30 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>> The impression I get is that a lot of people rely on silent *variable*
>> failure, but very few rely on silent *tag* failure. In fact, most
>> real-world custom template tags I've seen are
Graham King wrote:
> And if Django had logging, we could have a SQL log, and I wouldn't
> have to start all my projects by setting up a logger, a SQL logging
> middleware, and an audit log of object create/update/delete.
I trust you've seen the django-logging project on c.g.c?
'warnings' sounds like a subset of 'logging'.
In a similar thread (about template tags and filters failing
silently) two years ago Simon Willison (who started this thread) said:
"We really need an official Django logging framework so stuff like
this can be logged"
On Wed, May 21, 2008 at 5:27 AM, Curtis <[EMAIL PROTECTED]> wrote:
>
>
> Has anyone considered using Python's 'warnings' module? It seems like
> it might be the perfect fit for this problem.
>
> For example, if the appropriate warn() calls were added to the
> templating system, by default,
Has anyone considered using Python's 'warnings' module? It seems like
it might be the perfect fit for this problem.
For example, if the appropriate warn() calls were added to the
templating system, by default, problems would be sent to sys.stderr.
By setting up a warnings filter in (for e.g.
I can add newer patch if anyone interested.
On Wed, May 21, 2008 at 2:54 AM, graham_king <[EMAIL PROTECTED]> wrote:
>
> Making {{ myval }} fail loudy would break the admin app. Setting
> TEMPLATE_STRING_IF_INVALID to anything other than '' also breaks it.
>
> Here's an example:
Making {{ myval }} fail loudy would break the admin app. Setting
TEMPLATE_STRING_IF_INVALID to anything other than '' also breaks it.
Here's an example: http://code.djangoproject.com/ticket/5532
This ticket has all the details: http://code.djangoproject.com/ticket/3579
Will this be fixed in
On Sat, May 17, 2008 at 11:30 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> The impression I get is that a lot of people rely on silent *variable*
> failure, but very few rely on silent *tag* failure. In fact, most
> real-world custom template tags I've seen are wired up to raise errors
> quite
James Bennett wrote on 05/18/08 06:30:
> On Wed, May 14, 2008 at 8:58 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
>> Silent errors are bad. If we were to remove them, how much of a
>> negative impact would it have on the existing user base?
>
> The impression I get is that a lot of people rely
Another issue(related to error raising in templates), is that when an
error propagates inside a loop the error page highlights the error as
being in the {% for %} tag, which is often confusing, I'm not sure
what causes this, since the traceback correctly highlights the actual
issue in question.
On Wed, May 14, 2008 at 8:58 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?
The impression I get is that a lot of people rely on silent *variable*
failure, but very few
Personally, I prefer fireworks when a variable is not set.
Here's yet another possibility, just a variant on current code:
TEMPLATE_STRING_IF_INVALID = "%
(expression)s: %(error)s"
The above would be filled in by _resolve_lookup with appropriate
values.
Then you have a style:
template-var-error
+1 on no silent errors by default.
Tying behaviour to the DEBUG setting is wrong: if you're building a
template with optional Titles, you'd want to be able to test it in
your debug environment with Titles both present and missing.
I know creating more syntax is evil, but how about {{ post.title
Simon Willison schrieb:
>
> There are a few problems with inserting error output in the template
> rather than raising an exception, ...
I use this to raise an exception:
{{{
# settings.py
if DEBUG:
TEMPLATE_STRING_IF_INVALID = InvalidVarException()
}}}
This raises an exception, if a
I agree that silently failing is useful for var lookups,not as much for tags..
how about having a TemplateDebugException,that would be silenced in
production, availible for use in tags and some special syntax for var
lookups,like
{{ var.key|filter or '' }} or just
{{ var.key|filter '' }} or
i like the filter idea, but would prefer the default to be required,
and a filter to specify when something is not required (that might be
harder to push because of backwards incompatability)
i dont agree with the setting to be based on debug.
last thing i want is my test behavior being
I sometimes return an 'error' string from my own tags when it's
important to see a problem.
One way of making that more elegant would be to make an explicit
MustNotBeSilencedException that a tag could use for error checking.
The template handling code would ignore all other exceptions.
Derek
I've been thinking about this issue, so here are some thoughts:
I like Jeff's idea on inserting the results into the template. I agree
also that the errors in-place pose problems since, as Simon commented,
the errors would not be visible in some cases.
Also the fail silently feature _can_ be
> I'd be +1 on this, on the condition that there be some way to supress
> errors, something like this.
>
> {% for item in list %}
> {{ item.title }}
> {% silent %}
> {{ item.owner }}
> {% endsilent %}
> {% endfor %}
That seems very clunky to me. If going down that route, I'd prefer to
either
On May 14, 3:51 pm, Ken Arnold <[EMAIL PROTECTED]> wrote:
> 4. Other tags and filters, like include, ssi, and truncatewords (from
> a quick scan) that perform some function that could fail, should mark
> that failure very clearly in the output. (Those two currently do, but
> the error string is
I'd be +1 on this, on the condition that there be some way to supress
errors, something like this.
{% for item in list %}
{{ item.title }}
{% silent %}
{{ item.owner }}
{% endsilent %}
{% endfor %}
On May 14, 11:03 pm, "John Lenton" <[EMAIL PROTECTED]> wrote:
> On Wed, May 14, 2008 at 7:19 PM,
On Wed, May 14, 2008 at 7:19 PM, Christopher Allan Webber
<[EMAIL PROTECTED]> wrote:
>
> I'm just going to chime in here that a lot of our older apps at our
> work use Zope Page Templates.
>
> Largely we've found ZPT pages to be less pleaseant in all regards
> *excepting* the fact that they
I'm just going to chime in here that a lot of our older apps at our
work use Zope Page Templates.
Largely we've found ZPT pages to be less pleaseant in all regards
*excepting* the fact that they never, ever silently fail. Just as
your code fails when there's a problem, so do your templates.
Hello!
Not that I have a vote, but I do have an idea...
Ken Arnold wrote:
5. Variable lookups, and everything else, never cause render() to
fail, but insert an easy-to-catch and easy-to-bypass error string in
the output.
Thoughts?
Another option for easy-to-catch and easy-to-bypass
Hi, I like to use TEMPLATE_STRING_IF_INVALID with %s, however such usage is discouraged.
I think that in production mode it's better to put no item into HTML
instead of 500 error in most of cases.
But there might be a method to mail admins somehow for important
fields having broken.
If
On May 14, 2008, at 12:29 PM, J. Cliff Dyer wrote:
>
> On Wed, 2008-05-14 at 19:00 +0400, Ivan Sagalaev wrote:
>> Simon Willison wrote:
>>> {{ article.something.title }} - outputs text if article is there,
>>> fails silently otherwise
>>>
>>> Which leaves us in a tricky situation. A global
On Wed, 2008-05-14 at 19:00 +0400, Ivan Sagalaev wrote:
> Simon Willison wrote:
> > {{ article.something.title }} - outputs text if article is there,
> > fails silently otherwise
> >
> > Which leaves us in a tricky situation. A global settings.py variable
> > for "throw errors on missing
Simon Willison wrote:
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?
+1 from me.
I always set TEMPLATE_DEBUG to True and TEMPLATE_STRING_IF_INVALID to
something that stands out, during development.
--
Nicola Larosa -
I like the filter idea -- maybe something like 'required' It could be
similar to marking things as safe for the autoescaping.
Default behavior should be silent failures, and authors can explicitly
set variable calls to fail visibly.
So with Simon's original example, the template author
Simon Willison wrote:
> {{ article.something.title }} - outputs text if article is there,
> fails silently otherwise
>
> Which leaves us in a tricky situation. A global settings.py variable
> for "throw errors on missing template variables" is a bad idea as it
> kills application portability
It
I made some comments on bug #5140 a while back, before I realized that
bug reports weren't a great place to discuss important things. That
bug bit me quite enough back in the early days of my project.
I'd definitely want to know if any url templatetag failed. And
probably any variable lookup
On Wed, May 14, 2008 at 10:10 AM, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> On Wed, May 14, 2008 at 9:07 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> > Which leaves us in a tricky situation. A global settings.py variable
> > for "throw errors on missing template variables" is a bad idea
On Wed, May 14, 2008 at 10:07 AM, Simon Willison
<[EMAIL PROTECTED]> wrote:
>> I suspect that a lot of people actually rely on this behavior, and it
>> would be devastating to them.
>
> Thinking about it some more you're right - I'm sure there are lots of
> cases where people are relying on
On Wed, May 14, 2008 at 9:07 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> Which leaves us in a tricky situation. A global settings.py variable
> for "throw errors on missing template variables" is a bad idea as it
> kills application portability (the PHP magic_quotes problem again - if
> your
On May 14, 3:02 pm, George Vilches <[EMAIL PROTECTED]> wrote:
> On May 14, 2008, at 9:58 AM, Simon Willison wrote:
> > Silent errors are bad. If we were to remove them, how much of a
> > negative impact would it have on the existing user base?
>
> I suspect that a lot of people actually rely on
On May 14, 2008, at 9:58 AM, Simon Willison wrote:
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?
I suspect that a lot of people actually rely on this behavior, and it
would be devastating to them. What I've
Hi all,
Some time in late 2003, Adrian and I decided that errors in templates
were best handled silently - the idea was that it would prevent
untrained template editors from being able to 500-error a site with a
typo.
Is it too late to reconsider this decision, four and a half years
later? I
37 matches
Mail list logo
