elfs | Small but useful Django notions… (Reply)

If you’ve created Django Application A, and then Django Application B, it is acceptable (and even sometimes necessary) for Application B to reference Application A. The canonical example is Django contrib.auth; everyone references that beast. It is not acceptable for you to go and edit Application A to reference Application B. That is officially Doin’ It Wrong.

In a smarter world, you will never use a Django ManyToMany field. You will create an individual class referencing both objects of the many-to-many relationship. You will inevitably need more smarts than a mere two-column table, and a separate class, however small and insignificant, will provide both self-documentation and a chance to define the __unicode__() method for administration. Django is smart enough to hook up the relationships under the hood.

Unit testing is goddamned hard when your application is married to FacebookConnect. A smarter relationship uses the SocialAuth layer, with additional proxies for information and posting handlers. That way, not only can your application send updates to Facebook walls, but it can also update its activity on Twitter, and allow authentication via Google, and so on. By using the SocialAuth layer, you can create a pseudo-layer that handles testing. You’re still beholding to testing the SocialAuth stuff yourself.

If you’re using SocialAuth, push all of your user-related smarts into the UserProfile object, and always refer to it. Build your UserProfile object to own the proxy to the user’s authenticated relationships with social media. After login, leave the user alone! Better yet, use middleware to attach the profile to the request object automagically if and when it’s present, and live with it.

This entry was automatically cross-posted from Elf's technical journal, ElfSternberg.com