Re: rev 7920 fresh checkout fails tests?

On Mon, Jul 14, 2008 at 12:57 AM, Russell Keith-Magee < [EMAIL PROTECTED]> wrote: > > On Mon, Jul 14, 2008 at 12:25 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > > > > Speaking of 2.3 compatibility, the tests don't run for me on 2.3 (which I > > just installed for testing purposes). I get: > ...

Re: rev 7920 fresh checkout fails tests?

On Mon, Jul 14, 2008 at 12:25 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > > Speaking of 2.3 compatibility, the tests don't run for me on 2.3 (which I > just installed for testing purposes). I get: ... > cmd += ''.join(' %s' % arg for arg in args) > ^ > Synta

Re: rev 7920 fresh checkout fails tests?

Generator expressions were added in 2.4, django uses them in a number of places doesn't it? On Jul 13, 11:50 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 12:25 AM, Karen Tracey <[EMAIL PROTECTED]> wrote: > > [snip] > > >   File "D:\u\kmt\django\trunk\tests\regressiont

Re: rev 7920 fresh checkout fails tests?

On Mon, Jul 14, 2008 at 12:25 AM, Karen Tracey <[EMAIL PROTECTED]> wrote: [snip] > File "D:\u\kmt\django\trunk\tests\regressiontests\admin_scripts\tests.py", > line 56 > cmd += ''.join(' %s' % arg for arg in args) > ^ > SyntaxError: invalid syntax > > (the ca

Re: rev 7920 fresh checkout fails tests?

On Sun, Jul 13, 2008 at 11:50 PM, Russell Keith-Magee < [EMAIL PROTECTED]> wrote: > > On Mon, Jul 14, 2008 at 10:55 AM, Matt Wilson <[EMAIL PROTECTED]> wrote: > > > > I'm trying to figure out if I'm running the tests incorrectly, or if > > there are really are failed tests in the revision. > > I'm

Re: rev 7920 fresh checkout fails tests?

On Mon, Jul 14, 2008 at 10:55 AM, Matt Wilson <[EMAIL PROTECTED]> wrote: > > I'm trying to figure out if I'm running the tests incorrectly, or if > there are really are failed tests in the revision. I'm not seeing any failure in my checkout of [7920]. Looking at the failures you are getting, it

Re: Inquiry

This list is not for general usage questions; rather, it is for discussion of the development of Django itself. Please keep usage discussion on django-users. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ Y

Inquiry

Good Day to All! I am new to Django and I was wondering if there is a sample application that deals with sessions that is not using cookies. Also is there a directory structure in an web app when using Django? Like in J2EE?? Hope someone would reply. Thanks Myles --~--~-~--~~---

rev 7920 fresh checkout fails tests?

I'm trying to figure out if I'm running the tests incorrectly, or if there are really are failed tests in the revision. There's no point in working on a patch if I'm just doing something wrong, so I'd really appreciate it if somebody can look over how I'm running these tests. I ran the runtests

Re: Make clickable area of object links larger

I've just submitted an updated patch for this issue to , which does the following: * standard edit links and fields listed in 'list_display_links' fill the whole cell * any other links (eg using 'allow_tags' on a field) are not affected * The dashboar

Re: Multiple database support

I've been doing a little reading on multi-db code an wiki. You've basically been tackling problem #3 (different data types and engines) - which I didn't care about at all. That's good, I guess. The way I handle database connections is just by having a connection pool of different connection objec

Re: Make clickable area of object links larger

On Jul 13, 12:56 pm, David Danier <[EMAIL PROTECTED]> wrote: > So making the whole field () clickable should really be enough, the > row itself (everything inside ) does not need to be clickable by > default. If I'm not mistaken, in NFA, you can create a custom subclass of ModelAdmin that always

Re: Make clickable area of object links larger

> There is already a way to control which fields are links to the change > page: http://www.djangoproject.com/documentation/model-api/#list-display-links I know, thats what I meant. To make the whole row clickable you have to put all fields which are in list_display into list_display_links, too.

The Code One

http://www.thecodeone.com/vb/index.htm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group

Re: Make clickable area of object links larger

There is already a way to control which fields are links to the change page: http://www.djangoproject.com/documentation/model-api/#list-display-links On Jul 13, 6:44 am, David Danier <[EMAIL PROTECTED]> wrote: > > Each row in a change list represents one object, usability suffers by > > making on

Re: George Carlin comedy

Bah, exploiting the death of a comedy genious and true patriot like this. I shit on you spammers. 2008/7/13 mangaboy008 <[EMAIL PROTECTED]>: > > George Carlin comedy > > George Carlin comedy, movies, pictures, wallpaper, download > > http://english1.isoshu.com > > > --~--~-~--~~

George Carlin comedy

George Carlin comedy George Carlin comedy, movies, pictures, wallpaper, download http://english1.isoshu.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send emai

Re: Make clickable area of object links larger

> Each row in a change list represents one object, usability suffers by > making only one potentially tiny (an integer primary key) field > clickable. What about supporting custom urls for some fields in the future? (e.g. linking to an foreign object for model.ForeignKey) I would make the whole

Re: Make clickable area of object links larger

Isn't click to focus a window (or not) an OS decision? E.g. clicking anywhere in a browser window on a Mac will focus the window but not send a click to the application. Even if that weren't the case, making the link area smaller just reduces the probability for accidental clicks and makes it mor