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.
Seems to me that the main benefit of the swappable models approach is just
to avoid backwards incompatibility issues by making the change opt-in, but
I think it's also opening Pandora's box. I think that leaving it up to
developers to ensure that their swapped-in models simply behave enough like
the original is going to cause subtle and difficult to trace bugs.
App developers won't be able to have confidence that models they have
defined will actually be used as defined.
This is why I would prefer to simply have an empty `User` model that is
basically just a PK, which is used only as the glue that connects all the
related bits and pieces (auth models, profile models, group and permissions
models, etc.)
The rest of the existing `User` fields can be implemented in an `AdminUser`
model, and allow multiple authentication backends, which defaults to just
an `AdminUserBackend` authentication backend.
Apps and projects can just use this if they like, or they can define
whatever models they like to link to the user (if they want to hook into
other data that is linked to the user), along with their own auth backend.
Then users can login with either admin credentials, or your project/apps
credentials. A few abstract user base classes or auth backend classes could
help make this part easier.
I'm not convinced that there should even be this concept (like the "data
bag") that an app can rely on "some app" ("any app") defining a value for a
user related field (e.g. name, email, twitter name, etc.), without knowing
or caring which app has defined it. If you don't know which app defines the
data, how can you know that it is the correct data for your app and your
purpose? Likewise if you change a value, how do you know it won't
inadvertently impact another app that relies on it? You won't know what
other apps will be installed along side your own, what fields they will
define, or when they will want to overwrite those fields.
There is such a thing as too generic. People can and do already define
their own user/profile models and authentication backends. They can and do
create their own models to store arbitrary data like name, twitter name,
longer email address. The only problem is that there are then required and
redundant or insufficient vestigial fields left over in `auth.User`. I have
my own user model with username field, but I have to fake an
`auth.User.username` to connect my user to groups and permissions. I can't
use signals to sync my username/email address to `auth.User.email` for the
Django admin because it's only 75 characters long and not RFC compliant.
If `auth.User` was just a glue model, with just a PK, and the other fields
were moved to `AdminUser` (and `AdminUser.email increased in length), this
would be a non-issue because I would not need to even have an `AdminUser`
at all to create users for my app/project. I would only need to create one
for users of the admin app, and in that case I should adhere to the
AdminUser model's field requirements.
Cheers.
Tai.
On Wednesday, 4 April 2012 15:25:40 UTC+10, Eric Florenzano wrote:
>
> I completely agree with Adrian's proposal, with these amendments suggested
> by Russell in order to build something slightly more generic, like
> LazyForeignKey, instead of UserField. In fact, a UserField coud end up
> being provided as a subclass of LazyForeignKey with a default name provided
> (e.g. 'user') and any other user-domain-specific customizations needed.
>
> Thanks,
> Eric Florenzano
>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/gMdsJCSMmKIJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
