Re: Re: Django Error Display Page

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

Re: Sorting UX question

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). >

Sorting UX question

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

Re: Test optimizations (2-5x as fast)

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

Data loss bug on trunk

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

Re: Proposal: Adding UI and UX fields to Trac

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

Odp: Re: Django Error Display Page

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

Re: Django Error Display Page

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

More Class Based Views

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

Class based view version of FormPreview

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

Django Error Display Page

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

Odp: Re: Allow disabling choices in a

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

Re: Timezone-aware storage of DateTime

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.

Re: Proposal: Adding UI and UX fields to Trac

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

Re: Proposal: Adding UI and UX fields to Trac

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"