#8077: Add ability to disable signals one a per-object-per-event basis.
----------------------------------------------+-----------------------------
Reporter: [email protected] | Owner: nobody
Status: closed | Milestone:
Component: Core framework | Version: SVN
Resolution: wontfix | Keywords: signals
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------------+-----------------------------
Changes (by lukeplant):
* status: new => closed
* resolution: => wontfix
Comment:
Given the kind of examples given so far, I think there is a
misunderstanding about the purpose of signals.
As the [http://docs.djangoproject.com/en/dev/topics/signals/
documentation] says, signals are to help decoupled applications know about
what is going on elsewhere in the framework. As the person writing
`MyModel(params)` or `my_model.save()`, you don't know what signals are
attached to the model, so you don't know whether it is appropriate to turn
them off. The proposal is therefore not granular enough - you really need
to disable a single handler that is attached via signals, not all of them.
On the other hand, if you are creating instances of the model, you are
more like to be the person in charge of the model class, and you can
always override `__init__()` and `save()` to do some custom work, and you
can even pass custom parameters that will control whether the work needs
to be done or not.
In short, it sounds like, given the defined purpose of signals, it is the
attached signal handler that needs to become more intelligent (like in
davedash's suggestion), rather than the code that emits the signal.
Disabling signals is just a quick fix that will work when you know exactly
what handlers are attached to a signal, and it hides the underlying
problem by putting the fix in the wrong place.
--
Ticket URL: <http://code.djangoproject.com/ticket/8077#comment:14>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
