Hi Mateusz,
I think, adding a link at top, getting you to the end of traceback
would be suitable and would work 96% of times.
e.g, top line with exception type and URL could be a link moving you
to the end of traceback, where the exception happened.
What do you think?
Smart (colored) traceback
On Jun 9, 9:45 am, Luke Plant wrote:
> In the new admin sorting UI, which now supports sorting on multiple
> fields, the behaviour can be described by the following two rules:
>
> 1. If you click on a header, it is made the primary sort field
> (with others moved down the list as necessary).
>
In the new admin sorting UI, which now supports sorting on multiple
fields, the behaviour can be described by the following two rules:
1. If you click on a header, it is made the primary sort field
(with others moved down the list as necessary).
2. If you click on a header that was already par
On 6/6/2011 10:19 PM, Ramiro Morales wrote:
On Sun, Jun 5, 2011 at 5:18 PM, Ned Batchelder wrote:
When I try this on a PostgreSQL database, I have problems relating to
violated uniqueness constraints, sometimes from tests themselves, sometimes
from setUpClass, sometimes from tearDownClass. In
Hi all,
Karen recently discovered a data loss bug that was on trunk from 20th
April to 4th June. I realised it might affect other people who are
running trunk, so I thought I should give a heads up here. The bug was this:
If a user was editing records in the admin using the list_editable
feature
A single flag for "UI/UX" would be my first choice, with just "UI" being
second. Differentiating the two isn't going to produce a lot of useful
information at this juncture. Certainly fine with me to go ahead and add
something for it, though.
- Gabriel
--
You received this message because
Colored output of the trackeback does not solve my problem of scrolling few
screens in order to find whats happening, or use cmd-F key to quick jump.
I think this is not a good way to do this.
What's I am thinking is a tabs at the top which manipulates with visibility
of certain divs of error pa
This ticket might be a part of what you're looking for:
https://code.djangoproject.com/ticket/11834
It proposes to dim the django parts of the stacktrace, so the code
which most likely caused the error stands out better, which is
certainly something I'd love to see.
There's some similar ideas disc
Well.. I wasn't sure when to send this email, mostly cause I haven't
had time to properly document everything, but Russ' talk Wither
Django[0] seems to have done it.
One of the points he mentions in what he'd like in 1.4 is "More Class
Based Views". I've started working sporadically in an external
I used the FormPreview class in contrib.formtools for the first time
on Monday and having worked with class based views, wished it used
FormMixin.
I refactored the FormPreview class to inherit from FormView so Django
provides a more consistent API like its sister tool FormWizard which
recently got
Hi,
I have been thinking about this for quite a long time.
Can you make an error display page less verbose?
I mean not to exclude those useful information, but to initially fold (hide)
them.
Fold those items:
- Python path at the top yellow background.
- (Hide or fold) django traceback entries
Indeed it is useful, I was using a custom made app to do so.
Thank you
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d
On Jun 7, 4:30 pm, Luke Plant wrote:
> There seems to be the assumption in other messages in this thread that
> Django 'owns' the database. That is not the philosophy Django takes - it
In the case of SQLite, it just plain sucks, because the DB is too
stupid to support a true timestamp data type.
On Wed, Jun 8, 2011 at 9:36 AM, Idan Gazit wrote:
> UI: "The sorting icon is ugly."
> UX: "Sorting is confusing."
>
> That being said, I agree that most people won't be able to make the
> distinction.
>
> I'd say that we should just add a single boolean flag. I don't want to call
> it "Design" so
UI: "The sorting icon is ugly."
UX: "Sorting is confusing."
That being said, I agree that most people won't be able to make the distinction.
I'd say that we should just add a single boolean flag. I don't want to call it
"Design" so as not to confuse people with DDN tickets. "UI/UX"? "DesignHelp"
15 matches
Mail list logo