On 03/18/2011 07:22 AM, Carl Meyer wrote:
Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned
they bring almost nothing to the table except for the "there can be only
one" restriction
+1
Just use OneToOneField and the regular ORM access descriptors, and you
can have as
On 18 мар, 21:22, Carl Meyer wrote:
> On 03/18/2011 08:09 AM, Alexander Schepanovski wrote:
>
> > I think using subclass of User model for your fields has the same
> > flexibility as separate profile model (since you can have only one).
>
> You can have multiple subclasses of
On Fri, Mar 18, 2011 at 2:22 PM, Carl Meyer wrote:
>
>
> On 03/18/2011 08:09 AM, Alexander Schepanovski wrote:
>> I think using subclass of User model for your fields has the same
>> flexibility as separate profile model (since you can have only one).
>
> You can have multiple
On 03/18/2011 08:09 AM, Alexander Schepanovski wrote:
> I think using subclass of User model for your fields has the same
> flexibility as separate profile model (since you can have only one).
You can have multiple subclasses of the User model (not that I recommend
subclassing).
> contrib.auth
I think using subclass of User model for your fields has the same
flexibility as separate profile model (since you can have only one).
contrib.auth can be fairly simply adjusted to use custom User model
from settings instead of always using its own User.
In that sense I am totally for
On 03/15/2011 01:49 PM, Michael A. Ryan wrote:
In a typical client app, your User object is most
likely one robust object which you have to express in Django as both
User and UserProfile.
It's kind of hard to talk about "typical" Django app because there are
so many different of them :-).
Hello developers,
I've been using Django for a couple of months now on a new project and I've
come across something which I think might be improved upon. It deals with the
nature of UserProfile, which I think is a very handy tool overall.
The thing I'm not totally satisfied with is the way