On Thu, Aug 20, 2009 at 04:54, Andrew Fong wrote:
> The real problem is all of the code and third-party contrib that
> expects the User model to live at django.contrib.auth.models. Ideally,
> all of these apps should be rewritten to expect not the actual User
> model but any model that implements
Rob Hudson wrote:
> Take a look at ticket 3011:
> http://code.djangoproject.com/ticket/3011
>
>
Thanks a lot! That's pretty much exactly what I want. In my opinion this
should become a real feature and not just a patch.
--~--~-~--~~~---~--~~
You received this
On Thu, Aug 20, 2009 at 9:22 AM, Rob Hudson wrote:
>
> Take a look at ticket 3011:
> http://code.djangoproject.com/ticket/3011
>
I don't know, but that seems a little too "magic" for me. The User
model appears to be imported from somewhere else than it actually is.
Isn't this what the core devs d
Take a look at ticket 3011:
http://code.djangoproject.com/ticket/3011
--~--~-~--~~~---~--~~
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
The real problem is all of the code and third-party contrib that
expects the User model to live at django.contrib.auth.models. Ideally,
all of these apps should be rewritten to expect not the actual User
model but any model that implements a User interface. More broadly
speaking, if your third-par
James Bennett wrote:
> On Mon, Aug 17, 2009 at 11:35 AM, James Bennett wrote:
>
>>def __getattr(self, name):
>>if hasattr(self.user, name):
>>return getattr(self.user, name)
>>else:
>>return getattr(self.profile, name)
>>
>
> And for some reason
> This is actually pretty much exactly what I had before, it was horribly
> slow! And somehow not nice since you always have to wrap the users
> around and can't just use request.user...
When you say that it was "horribly slow," does that mean you weren't
using caching to skip the DB, or was it s
James Bennett wrote:
> On Mon, Aug 17, 2009 at 10:57 AM, Jonas Obrist wrote:
>
>> Thanks for your opinion on this, didn't know django had this feature
>> once. But I just can't get it out of my head that there's gotta be a
>> better solution than this profile-extending... It just seems ridiculo
On Mon, Aug 17, 2009 at 11:35 AM, James Bennett wrote:
> def __getattr(self, name):
> if hasattr(self.user, name):
> return getattr(self.user, name)
> else:
> return getattr(self.profile, name)
And for some reason gmail ate the trailing double underscores --
On Mon, Aug 17, 2009 at 10:57 AM, Jonas Obrist wrote:
> Thanks for your opinion on this, didn't know django had this feature
> once. But I just can't get it out of my head that there's gotta be a
> better solution than this profile-extending... It just seems ridiculous
> to me that half of the use
On Mon, Aug 17, 2009 at 11:57 AM, Jonas Obrist wrote:
>
> Hey Jacob
>
> Thanks for your opinion on this, didn't know django had this feature
> once. But I just can't get it out of my head that there's gotta be a
> better solution than this profile-extending... It just seems ridiculous
> to me that
Hey Jacob
Thanks for your opinion on this, didn't know django had this feature
once. But I just can't get it out of my head that there's gotta be a
better solution than this profile-extending... It just seems ridiculous
to me that half of the user properties is in one table and the other
half
Hi Jonas --
On Mon, Aug 17, 2009 at 7:43 AM, Jonas Obrist wrote:
> Basically it lets you define a class in settings which extends the User
> table before it's created, using subclassing.
This is a non-starter. It's not going to happen.
Back in the day, Django actually had this "feature." There
Hi django-developers
I wasn't quite happy with how django.contrib.auth handles extending the
User table. So I changed the auth system and in my opinion it's a better
solution.
The code can be found here: http://dpaste.com/81651/
Basically it lets you define a class in settings which extends t
14 matches
Mail list logo
