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 then allowing the admin to use
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 quic
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 versio
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
http://code.google.com/p/django-smtpd/wiki
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?
--~--~
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-
> > View-Controller design pattern. Django widgets
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 i
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
"Djan
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
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 a
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 for whoever is not fam
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.
--~--~-~--~~---
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 t
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 thing to consider is
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
form.c
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
> wrote:
>> On Thu, 2009-01-22 at 17:27 -0800, mr
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 pychecke
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
> persistent :) Clicking on
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
> > implementation of TemporaryFile. This cause
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 approuch is in model's met
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
> > I'd be keen to hear what is the official (
21 matches
Mail list logo
