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 variabl
I found something that I find interesting with the deserialization.
If you create a child class and do not define a OneToOneField yourself, the
deserialized output has an extra field, "parent_ptr".
i.e.
{
"pk": 2,
"model": "first.child",
"fields": {
"parent_ptr": 2,
"name
Hi all,
I've been using twill integrated into Django unit tests (as described
here: http://www.djangosnippets.org/snippets/665/ ), but came across
the problem that exceptions are hidden by Django's exception
handling, so it's very difficult to tell what has gone wrong if you
have a bug. The p
So, are you suggesting that on fixture loading that parents should *not* be
saved?
Would this possibly allow you to load fixtures that don't fit in your model?
E.g. children without parents?
On Sat, May 10, 2008 at 10:24 AM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> Above, I said:
> > I notice that
That came quite unreadable... a translation here: (sorry for the
noise)
"""
Hello,
While doing some test cases for aggregates I came across the fact that
extra() does not play well with values().
For example, though
>>> Book.objects.all().extra(select={'price_per_page' : 'price /
>>> pages'}).
Hello,Book.objects.all().extra(select={'price_per_page' : 'price /
pages'}).values('price_per_page').get(pk=1)
While doing some test cases for aggregates I came across the fact that
extra() does not play well with values(). For example: though
Book.objects.all().extra(select={'price_per_page' : '
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 anythi
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 different
Hi everyone,
I discussed this last night on IRC with Alex Gaynor, if anybody's
interested in the genesis of this email:
http://oebfare.com/logger/django-dev/2008/05/14/ @ 21:24
I am
The problem that I had was that
model._default_manager.distinct().values('name')
produced something like this:
[{'n
> So that leads me to my decision to put this SQL-code into a model so
> that the query is performed faster than by the view.
I think what you might be looking for is a custom (default) manager
for your model that adds your base query to each QuerySet interaction.
I suppose depending on what that
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 _ve
> 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 enab
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 ea
14 matches
Mail list logo
