On Jun 24, 4:05 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 24, 2008 at 2:53 PM, radioflyer <[EMAIL PROTECTED]> wrote:
> > I continue to struggle with what I see as some real limitations of the
> > User/UserProfile paradigm used by Django.
>
> Well, it doesn't cover every conceivable thing you might want to do,
> which is to be expected; out of the box, the most common case (single
> user type, single profile model) is covered, and more complex
> situations -- which will probably require customization anyway --
> aren't.
>
> > One issue, which I have seen a number of people struggling with is the
> > usability of the Users selection widget. The problem is that when
> > creating users, there are no required fields that make for easy
> > ordering, searching or readability. If first_name, last_name were
> > required, they could be used to make the selection widget order-able
> > and more readable. Of course, no one wants to have Django hardwire
> > anything but the bare minimum fields for the authentication system so
> > this is understandable.
>
> So if it's important to require these fields, then write forms for
> entering users which require these fields. The fact that they're not
> required at the model level doesn't forbid you setting up requirements
> at a form level.
>
> > Because I want administrators of the site to have an easy way to give
> > Users a choice of different profiles, I've had to try some different
> > approaches.
>
> One other thing you might try is exploring the Group model as a way to
> keep users organized according to who they are -- e.g., have
> "Teacher" group, a "Student" group, etc., and use group membership to
> determine which profile model you want to use for a given user.
>
> > - All of the child user types show up in the add/change admin for
> > users. The administrator would have to remember what type of user they
> > were adding and do a lot of scrolling around irrelevant fields.
>
> You're really getting into a case where the stock admin doesn't suit
> your needs, and instead of stepping back and writing what would be a
> few short, simple views to do exactly what you want you're still
> trying to force what you want into a codebase that wasn't designed for
> this. newforms-admin might help you a little bit by giving you places
> to just plug in and override, but I really think writing a couple
> views and forms that handle your custom logic is the way to go here.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Thanks James. I think maybe what I needed was a 'reality check'
response which is what you supplied. :-)
I do have a tendency to make more work for myself by trying to do less
work.
Best regards from an old Jayhawk.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
