Thanks for the reply.
You're right that auth.User is not a replacement for a profile.
Maybe I will make the training app require only that a profile model
exists and has a particular set of fields like cost-center, manager's
e-mail, etc.
This way at least it wouldn't be tied to a particular implementation
of a profile.
I would just have things like...
class Enrollment(models.Model):
person = models.ForeignKey(settings.AUTH_PROFILE_MODULE)
offering = models.ForeignKey(Offering)
If I do this, then do I run into that problem of not being able to
import the models file?
~Eric
On May 4, 3:35 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
