Re: DDN on #9284

On Mon, Mar 23, 2009 at 8:17 PM, Malcolm Tredinnick < malc...@pointy-stick.com> wrote: > > Hey Joseph, > > On Mon, 2009-03-23 at 15:32 -0500, Joseph Kocherhans wrote: > > #9284 [1] Has a patch to make BaseModelFormSet call ModelForm.save() > > when saving objects rather than using completely

Re: Killing reloaders when parent receives TERM signals

On Mar 24, 5:04 pm, Graham Dumpleton wrote: > Use Apache/mod_wsgi and the documented method of running a WSGI > application in a specific daemon process in a autoreloading > development mode. You could even have both the production and > development instances under

Re: Killing reloaders when parent receives TERM signals

On Mar 25, 9:27 am, Dave Benjamin wrote: > No, I'm trying to run it as a dev server. I use mod_python in > production. However, I use the dev server in a shared environment so > that a few other programmers and testers in the office can view the > site. > > In any

Re: Killing reloaders when parent receives TERM signals

On Mar 24, 4:13 pm, Malcolm Tredinnick wrote: > On Tue, 2009-03-24 at 15:27 -0700, Dave Benjamin wrote: > > In any case, sending a TERM signal to the parent process should cause > > the child to die. There is no reasonable justification for the current > > behavior,

Re: Killing reloaders when parent receives TERM signals

On Tue, 2009-03-24 at 15:27 -0700, Dave Benjamin wrote: > No, I'm trying to run it as a dev server. I use mod_python in > production. However, I use the dev server in a shared environment so > that a few other programmers and testers in the office can view the > site. > > In any case, sending a

Re: Flatpages has been broken by a recent change (10139)

On Tue, 2009-03-24 at 07:06 -0700, Stephane Raimbault wrote: > The following changeset has broken the flatpages feature: > http://code.djangoproject.com/changeset/10139 > > I can't access the flat page list (admin/flatpages/flatpage/) with > this change (error on f.rel.get_related_field().name).

Re: QuerySet.values() Shallow Copy

After spending some time looking at the code I found out that my original problem has been solved by Malcolm with #5768 by using "__" to traverse foreign key relations. Too bad that this was not reflected in django online doc at

Re: "Delete selected objects" in admin batch edit

Am 24.03.2009 um 10:41 schrieb David Larlet: > > > Le 24 mars 09 à 09:36, Elliott a écrit : >> Given these reasons it only makes sense to me to leave delete off by >> default and provide an easy way to enable it, both globally or for >> each model. > > I agree with Elliott, admin actions are

Re: Killing reloaders when parent receives TERM signals

No, I'm trying to run it as a dev server. I use mod_python in production. However, I use the dev server in a shared environment so that a few other programmers and testers in the office can view the site. In any case, sending a TERM signal to the parent process should cause the child to die.

Re: Killing reloaders when parent receives TERM signals

It looks like you're trying to run the dev server as a real web server, which is a very bad idea (it's only serves one request at a time, for starters). As it says here: http://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-optional-port-number-or-ipaddr-port "DO NOT USE THIS

Re: Template filters problem introduced in rev 10118

On 24 Mar, 15:26, Waylan Limberg wrote: > Well, you are using the `stringfilter` decorator, which, according to > the docs [1],  "will convert an object to its string value before > being passed to your function." Are you sure? The docs say about converting only the first

Re: CSRF template tag patch done

On Monday 23 March 2009 19:21:00 Luke Plant wrote: > Hi all, > > The patch has been added to: > > http://code.djangoproject.com/ticket/9977 I've bashed on this a lot more, and discovered (and fixed) several issues (particularly to do with what happens when sessions are first created). I've

Killing reloaders when parent receives TERM signals

Hello, I run the Django development server (manage.py runserver) under Daemontools on Linux. Daemontools is a server management framework that runs a foreground process as a daemon and automates the tasks of starting, restarting, signal handling, and logging. I use a run script that looks like

Re: New Feature: ModelBase Signals

lol It seems nothing. Sorry about that - the reference I was consulting didn't mention that signal. You guys really covered a lot of bases - thanks! Dan On Tue, Mar 24, 2009 at 12:04 PM, Jacob Kaplan-Moss wrote: > > On Tue, Mar 24, 2009 at 10:41 AM, Dan

Re: New Feature: ModelBase Signals

On Tue, Mar 24, 2009 at 10:41 AM, Dan wrote: > I think an easy solution would be to use signals to allow receivers to > be notified when the class type is being declared in > ModelBase::__new__ and receive an alterable copy of the class > declaration.  Is this sort of thing

New Feature: ModelBase Signals

Hi All, I'm still getting started with Django to some extent, but there's a feature I would like to see and would be happy to add to the source if there's interest from the community. In short, I've come across a few occasions where I want to alter a model class declaration dynamically, just as

Re: Template filters problem introduced in rev 10118

On Tue, Mar 24, 2009 at 9:57 AM, eXt wrote: > [SNIP] > > This worked before 10118. Starting from 10118 all filter's parameters > are passed as strings (why?) so it breaks my code causing: > > TypeError: slice indices must be integers or None or have an __index__ >

Flatpages has been broken by a recent change (10139)

The following changeset has broken the flatpages feature: http://code.djangoproject.com/changeset/10139 I can't access the flat page list (admin/flatpages/flatpage/) with this change (error on f.rel.get_related_field().name). --~--~-~--~~~---~--~~ You received

Template filters problem introduced in rev 10118

Hi! As apollo13 has suggested to me on #django I'm reporting here a problem I've ecountered. Revision 10118 of Django has introduced some changes to the way template filters work. I've simple filter: @register.filter @stringfilter def truncatestring(src, ln): ret = src[:ln] if

Re: "Delete selected objects" in admin batch edit

It would seem to me that the method we're using for context_processors might be a good one. A list of things available by default, then you can override it in settings.py in order to provide different ones or remove some of the defaults. I think it could very well. Thoughts? -justin -- Justin

Re: #13 -- Related Objects Interface (edit_inline)

On Tue, Mar 24, 2009 at 4:17 PM, Jurie-Jan Botha wrote: > > This post is for discussion of improvements to the related objects > interface. It mostly concerns the implementation of more Javascript/ > Ajax that will allow for a 'slicker' inline related object editing >

Re: "Delete selected objects" in admin batch edit

Le 24 mars 09 à 09:36, Elliott a écrit : > Given these reasons it only makes sense to me to leave delete off by > default and provide an easy way to enable it, both globally or for > each model. I agree with Elliott, admin actions are great and we were all impatients to see it in action - no

"Delete selected objects" in admin batch edit

Sorry for pushing about this right after the feature was committed, but I have a problem with the way the feature was done. Specifically, I don't like the fact that "delete selected objects" is enabled by default. Although I'm glad to have the bulk edit feature, none of my models are designed at

#13 -- Related Objects Interface (edit_inline)

This post is for discussion of improvements to the related objects interface. It mostly concerns the implementation of more Javascript/ Ajax that will allow for a 'slicker' inline related object editing interface. As far as I can see there are two major points of discussion: 1.) Is it a good