#30801: Improve guidance for making good use of signals
------------------------------------------------+------------------------
Reporter: Aymeric Augustin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
------------------------------------------------+------------------------
This is a follow-up to https://github.com/django/django/pull/11814 and
https://groups.google.com/d/msg/django-
developers/c5sFZ5BEujI/jVLsfSYBAwAJ.
I have two suggestions to improve the documentation of signals.
1. In ref/signals.txt, for each signal, document the alternatives, which
will usually be more robust and maintainable:
- Instead of a model signals, you can override the corresponding
method in the model class — unless that model is provided by a library and
cannot be swapped
- Instead of request/response signals, you can provide a middleware.
- As far as I can tell, other signals don't have a great alternative.
You could replace `connection_created` by a custom database backend but
that's a lot more work.
2. In the introduction of topics/signals.txt, replace the list of signals
with a good example. In my opinion, `setting_changed` is likely the best
example: many pluggable apps need it in their test suite.
--
Ticket URL: <https://code.djangoproject.com/ticket/30801>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/052.5380969c3d4afc5d63be79fd1be377eb%40djangoproject.com.
