#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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/052.5380969c3d4afc5d63be79fd1be377eb%40djangoproject.com.
