You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The chapter on Signals is made up of information about how to avoid using signals. This is important information to know: signals appear shiny, and suffer from the old problem of, "I have a hammer, so now everything looks like a nail!" However, when I had an actual use case for signal use to remain DRY, I couldn't find a how-to or use case in Two Scoops, which has served me so well in so many other cases.
I'd be happy to share my use case in a chapter. I'm on a team migrating a huge legacy web site which serves tens of thousands of paying users from a legacy Perl / ColdFusion / PHP mash-up to Django. We can't do this with a kill switch: the sites must be able to live side-by-side without the end user knowing they're actively being swapped back and forth between the legacy site, and the Django site. As an upshot of this, we have four forms of auth which will need to be supported in Django: Django's own model auth, a custom middleware cookie authentication, LDAP, and CoSign (RemoteUser). There are some functions we need to perform regardless of the authentication type after login, which is a good use case for a signal. I'd be happy to use this as a concrete example and show how we implemented it for the next version of the book / Django LTS release.
The text was updated successfully, but these errors were encountered:
The chapter on Signals is made up of information about how to avoid using signals. This is important information to know: signals appear shiny, and suffer from the old problem of, "I have a hammer, so now everything looks like a nail!" However, when I had an actual use case for signal use to remain DRY, I couldn't find a how-to or use case in Two Scoops, which has served me so well in so many other cases.
I'd be happy to share my use case in a chapter. I'm on a team migrating a huge legacy web site which serves tens of thousands of paying users from a legacy Perl / ColdFusion / PHP mash-up to Django. We can't do this with a kill switch: the sites must be able to live side-by-side without the end user knowing they're actively being swapped back and forth between the legacy site, and the Django site. As an upshot of this, we have four forms of auth which will need to be supported in Django: Django's own model auth, a custom middleware cookie authentication, LDAP, and CoSign (RemoteUser). There are some functions we need to perform regardless of the authentication type after login, which is a good use case for a signal. I'd be happy to use this as a concrete example and show how we implemented it for the next version of the book / Django LTS release.
The text was updated successfully, but these errors were encountered: