|
|
Django users |
It might make sense in your situation to just pull back the values() Regards, -- On Sun, 2008-04-13 at 11:46 +0100, Tane Piper wrote: [...]
> What I want to Not really, unless you use values(). For any model, if the Python object
> know is there any way I could simplify the method and have it remove
> the password field any time a user object is being selected as part of
> a related query??
is being constructed, it pulls back all the values it needs to populate
the attributes. The password hash is an attribute of the User model.
> I'm sure there is a need for it when doing Login isn't the only time when the password hash might be needed (for
> authorisation, but once a session has been confirmed, is it needed
> again?
example, it's displayed and editable in the admin screen) and it would
be quite hacky to introduce a special case for saying when that field
shouldn't be displayed. You're using the User object in public-readable
situations, which isn't really part of the design. So change your design
a bit so that you're not throwing around this information if you don't
want it displayed. Yes, anything can be serialised using json, but that
doesn't mean you should indiscriminately do so or that the framework
should accommodate that.
that you need for various objects and serialise that dictionary. Or you
could make another pass through the projects list and blank out the
attribute(s) you aren't interested in, such as _project_manager_cache.
Malcolm
A clear conscience is usually the sign of a bad memory.
http://www.pointy-stick.com/blog/