Can someone give me an example please where a swappable model would benefit
me as opposed to one-to-one model inheritance, FKs, or even proxy models?
Django does this very well and allows
for seamless up/down traversal.
It seems that swappable models are nothing but a different way of doing what
I already am doing for when I am extending the flat pages; except that it
ads a nice centralized SWAPPABLE_MODELS setting.
Furthermore if I do make a swappable custom user model the correct
implementation of 'standard' User methods depends on me; sure I could extend
a the base User model and inherit these methods but then
what did I gained by having this swappable model concept?
The more I think about it the more it makes sense to me to have a base User
model just a stub with a user Identifier and password field. Sure one could
argue for less ore more fields, but I think the idea
is to pick something that would work in 95% situations and yet be flexible
enough to be extended as you wish. Need to extend to add your own
authorization you create a profile with a FK key to the base model and
a new auth backend.
Perhaps the reason the current contib.auth is still not overhauled is
because it does work for a large number of situation and extending it is
relatively easy. Keep the solution simple - I think we are overthinking it.
-----Original Message-----
From: Russell Keith-Magee
Sent: Wednesday, April 04, 2012 10:44 AM
To: django-developers@googlegroups.com
Subject: Re: auth.user refactor: the profile aproach
On 04/04/2012, at 8:44 PM, Tai Lee wrote:
I'm not so sure that it's necessary or even desirable to solve the
"general" problem of swappable models. If anyone can swap any model by
changing a setting, that sounds like a recipe for confusion to me.
Sure, but that's not what I've proposed. A model would only be swappable if
the original app developer declared that model as swappable. An end user
wouldn't be able to arbitrarily decide that they wanted to replace a model
in an app developed by someone else.
And sure, any feature we add could ultimately end up being used (and
overused) in bad ways. However, that's true of any language or library
feature. Classes, metaclasses, decorators, or any other Python language
feature can be both used and abused, as can Django features like ModelForms
or the internals of the Meta class.
My point is that there is nothing about this problem that is unique to User.
Django's own codebase contains another example of exactly the same
pattern -- Comments. Therefore, we shouldn't pretend that the solution is
User specific. At some point, we have to just provide enough documentation
and guidance to shepherd people away from bad architectural decisions, and
trust that the userbase will take that advice.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
