On Mon, 2009-05-04 at 11:35 -0700, eric.frederich wrote: > I wrote an app that consist of an authentication backend and a single > model "Profile" (extension of auth.User). It also has a function > which queries ldap to get user information like their manager. We'll > call this app my_custom_backend. The reason the Profile and > authentication are in the same app is because when a user logs in for > the first time it creates an auth.User as well as a > my_custom_backend.Profile and populates fields like cost center, > manager, phone number etc. > > Another app that I have is a training application to register for > training courses offered here for engineering (Ansys, AutoCad, MathCad > etc.). > > At first they were pretty separated through the use of the setting > AUTH_PROFILE_MODULE. > > At the top of my models.py in the training application I had this... > > PROFILE = getattr(settings, 'AUTH_PROFILE_MODULE', 'auth.User') > > And then later on in my models I would have things like... > > class Enrollment(models.Model): > person = models.ForeignKey(PROFILE) > offering = models.ForeignKey(Offering) > > So depending on setting AUTH_PROFILE_MODULE it would either link to > my_custom_backend.Profile or auth.User. > > Now as I start writing views and functionality I find the training app > directly depending on my_custom_backend. Like when a user enrolls in > an offering of a course the manager needs to get emailed for approval > and finding the manager's email is provided by my_custom_backend. > > Is it worth keeping them separated through the AUTH_PROFILE_MODULE > abstraction or should I just make the training app completely > dependent on my_custom_backend and directly reference > my_custom_backend.Profile from within there?
I would make the dependency firm. I'm always very nervous about code that does what you're doing here, for a couple of reasons: Firstly, that setting can never be changed once syncdb is run, since changing the setting would require changing the database schema (the reference constraint between the tables). Secondly, as a more minor point, you've removed the ability to be able to import your models file before the settings are available. That's why a bunch of Django's own code has "from django.conf import settings" inside functions -- so that the module itself can be imported even if the user is going to call settings.configure() later on. The second point is relatively minor for you at this stage, I suspect, but it's worth keeping in the back of your mind. Realistically, though, the answer to your question comes down to whether you'll ever be actually using your code without your particular profile module? It sounds like you won't be. Also, there's kind of an awkward design in what you've got now. The auth.User class is not a substitute for an AUTH_PROFILE_MODULE class, as the latter has a related field pointing to the former. Lots of your code would be easier if you were able to guarantee to yourself that you could always call get_profile() on a user object and just have it return the right thing. At a minimum, even if not hard-coding in the particular profile module, make it a requirement that a profile module exists. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
