Re: ManyToManyField in both models/forms

On Fri, 2009-01-23 at 00:12 -0800, Evgeniy Ivanov wrote: > On Jan 23, 3:17 am, Malcolm Tredinnick > wrote: > > Addressing this only in the admin would be short-sighted, however. A for > > field that new how to handle reverse relations would be the first step > > and

Re: django-smtpd allows you to handle email messages just like Django processes HTTP requests.

On Fri, 2009-01-23 at 15:08 -0800, nside wrote: > Hello, > > I just started a new project that basically allows you to write email > handlers in Django. It could be used in a user-registration > application where the user could reply to the email instead of > clicking on a URL. > I drafted a

Re: Flatpage signal?

On Fri, 2009-01-23 at 18:16 -0600, Jeremy Dunck wrote: > I'd like to do some processing any time a flatpage is requested. > > I can accomplish this by using a view middleware and testing for the > resolved view, Or by subclassing/replacing the existing FlatPage middleware to call your own

django-smtpd allows you to handle email messages just like Django processes HTTP requests.

Hello, I just started a new project that basically allows you to write email handlers in Django. It could be used in a user-registration application where the user could reply to the email instead of clicking on a URL. I drafted a quick documentation at

Flatpage signal?

I'd like to do some processing any time a flatpage is requested. I can accomplish this by using a view middleware and testing for the resolved view, but it seems a like a signal would be useful so I could have a reference to the flatpage object itself. Any opposition to the idea?

Re: Controlling form/widgets output

On Jan 22, 11:53 pm, Russell Keith-Magee wrote: > On Fri, Jan 23, 2009 at 5:02 AM, catsclaw wrote: > >   I could have been clearer.  I'm not talking about Django Models > > here; I'm talking about models, views, and controllers from the Model- > >

Re: pychecker catches IndexError exception while importing /django/db/models/base.py

Thanks for the suggestion. My app is named 'control' and my django project name is 'geni'. Running pychecker on the app dir raises a problem in pychecker itself -- it seemed to be that it was unable to open one of the sources files: $ pychecker control/ Processing control/... Caught exception

Re: #9344 and policy for small bug reports

Very helpful information from Karen and Russell, thanks. I have written it up for the Contributing section of the FAQ: http://code.djangoproject.com/ticket/10110 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

Re: Feedback from django-roa module

Le 19 janv. 09 à 18:43, David Larlet a écrit : > I got an issue with M2M relations because SQL is hardcoded and I > can't catch it in Query(Set) object: > http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L428 > It is/will be an issue for all non-sql backend

Re: Decisions needed on signals for add/remove/clear on many-to-many relations

I recently found the time to create a better patch for the m2m signals, including some tests and documentation and have posted this patch on http://code.djangoproject.com/ticket/5390 I have taken into account Malcom's suggestions resulting in one signal called m2m_changed that has the following

Re: #9344 and policy for small bug reports

On Fri, Jan 23, 2009 at 3:14 AM, Julien Phalip wrote: > Thank you Karen for this detailed answer. Your reasoning regarding > this ticket does make a lot of sense. I totally agree with you that > tests are highly important and that this ticket is lacking useful > information

Re: Model-validation: call for discussions

On Jan 23, 4:38 pm, Marty Alchin wrote: > I haven't been following everything, but I do have a couple comments > to make here. Thanks, interesting points. The get_value approach looks simpler though, so unless you or anybody else disagrees I'll implement this.

Re: Model-validation: call for discussions

After discussing with Honza, we agreed that the dichotomy between forms and models that was present before will remain, i.e. instance will always be a model instance if given and all_values will always be form.cleaned_data. Honza's rationale was that it's common to have properties in models and

Re: Model-validation: call for discussions

I haven't been following everything, but I do have a couple comments to make here. On Fri, Jan 23, 2009 at 8:04 AM, mrts wrote: > works both for forms and models with the proposed approach (all_values > is model_instance.__dict__.copy() in model field validation case). One

Re: Model-validation: call for discussions

As the uniform all values approach has created a bit of confusion, let me present a larger example: Validators in core.validators should not be concerned with either model or form internals if possible. This is currently straightforward to achieve by passing all values always as a dict via

Re: Model-validation: call for discussions

I should be around during the weekend so I will give it a try as well... Honza Král E-Mail: honza.k...@gmail.com ICQ#: 107471613 Phone: +420 606 678585 On Fri, Jan 23, 2009 at 2:56 AM, mrts wrote: > > On Jan 23, 3:40 am, Malcolm Tredinnick >

Re: pychecker catches IndexError exception while importing /django/db/models/base.py

I think I might be able to spot where the problem is. Try running pychecker on your app folder, rather than models.py. Let's assume your app is called myapp, so you have a directory structure something like this: myapp/ -- __init__.py -- models.py -- views.py -- tests.py (et cetera) If

Re: Proposal: Make filters in admin persistent (#6903)

On Fri, Nov 14, 2008 at 2:28 PM, Jonas Pfeil wrote: > > Just to be clear we are talking about the same thing: With "persistent > filters" I just mean "going back to the _filtered_ change list after > editing an item". I don't think it makes sense to make them any more >

Re: #9344 and policy for small bug reports

On Jan 23, 6:42 pm, Karen Tracey wrote: > On Fri, Jan 23, 2009 at 12:38 AM, Julien Phalip wrote: > > > Hi, > > > I just wanted to draw your attention to what appears to be a bug in > > Django: the 'tell()' proxy is missing from the Windows-specific > >

Re: ManyToManyField in both models/forms

On Jan 23, 3:17 am, Malcolm Tredinnick wrote: > Addressing this only in the admin would be short-sighted, however. A for > field that new how to handle reverse relations would be the first step > and then allowing the admin to use that is the second one. > Maybe better

Re: #9344 and policy for small bug reports

On Jan 23, 5:14 pm, Russell Keith-Magee wrote: > On Fri, Jan 23, 2009 at 2:38 PM, Julien Phalip wrote: > > > Now, I know that this is sort of an edge case, and I also know that > > there are more important and more urgent matters at this moment. But >