On 1 Apr., 16:04, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Wed, Mar 31, 2010 at 10:15 PM, Flo <d3f3n...@bytegeist.org> wrote: > > > On Mar 31, 3:27 pm, Russell Keith-Magee <freakboy3...@gmail.com> > > wrote: > > >> But under your proposal, you *can't* use your own permission model. If > >> BaseUser inherits from BasePermissions, and every application with a > >> custom user needs to inherit from BaseUser, then you never get the > >> opportunity to use your own permissions model - you get one enforced > >> on you because you need to use the BaseUser base class. > > >> As for clearer - I don't really see that as compelling argument. You > >> end up with the same number of methods at the end of the day. Once you > >> remove the ability to use a different implementation, whether they're > >> in 3 classes or 1 is largely irrelevant, IMHO. > > > I agree, if there is no way to add your own permission/auth/custom > > data classes to BaseUser, separation doesn't make any sense. > > > But I think it would be a good idea to modify my proposal to pass > > custom abstract permission and authentication classes to BaseUser > > and passing a custom data class to NewUser. I'm thinking about three > > settings variables, ABSTRACT_USER_PERMISSION_CLASS, > > ABSTRACT_USER_AUTHENTICATION_CLASS and > > ABSTRACT_USER_CUSTOM_DATA_CLASS. By default > > ABSTRACT_USER_PERMISSION_CLASS will point to BaseUserPermission, > > ABSTRACT_USER_AUTHENTICATION_CLASS will point to > > BaseUserAuthentication and ABSTRACT_USER_CUSTOM_DATA_CLASS will point > > to an empty class. Custom authentication and permission classes should > > extend BaseUserAuthentication or BaseUserPermissions to ensure the > > basic Django permission and auth system will work (admin, > > comments,....). To add customize the Django user class, you add your > > fields to an abstract ABSTRACT_USER_CUSTOM_DATA_CLASS so no extra > > relation is needed when extending the Django user class. > > Erm... No. > > Seriously - defining the base class based on a *setting* (or rather, 4 > settings) doesn't sound like a messy idea to you? > >
I think that would be a very flexible way, but offers the user a lot of possibilities to destroy a lot. It was the first idea that came to my mind, when thinking about making the system flexible (I was thinking about something like AUTH_PROFILE_MODULE). But the post was more about the idea of adding custom permission and authentication classes in general. Do you think that might be useful? Any ideas or suggestion how to handle the issue? > > >> It doesn't especially matter *when* it happens; if your plan involves > >> data migration, it's going to be a big imposition on the community. If > >> a data migration is unavoidable, that's fine, but you need to make > >> sure you've eliminated *every* other possibility. > > >> Put it this way - If part of your migration plan involves every one > >> user of Django carefully reading the and following the upgrade > >> instructions, then I want your home phone number so I can give it to > >> everyone that contacts me personally complaining about their broken > >> Django installs. And be warned -- I'm in a timezone that guarantees > >> you will be called at three in the morning. :-) > > > I don't like the idea of data migration very much too, but at the > > moment I think it's the only way. Maybe adding the new abstract layer > > only optional would be the best idea!? (but that would break Python's > > "there's one way you can do that" mantra..) > > Unless you're proposing that we maintain two user models as a > permanent arrangement (which is a non-starter), I don't know what > you're referring to here. > I think that leads to a fundamental question: in one of your last post you were worried about the performance of an extra join, but the abstract layer wil require that extra join (and migrating / or making BaseUser abstract, but that would eliminate a major benefit) As you said maintaining two User classes forever isn't an option. But do you even like the idea of the abstract user layer? I think design comes before performance (I think that's why a lot of people prefer python) and there are other django internals where bigger performance gains are possible (the template system...), but if you don't like the basic approach arguing for a change and little performance losses won't make any sense. > As for "it's the only way" -- I think you need to go back and read the > suggestion from my last email a little more closely. > > > > >> > solution: only works with the Django User class (which supports > >> > username and email) so check if request.user is an instance of > >> > auth.User or auth.NewUser, if not, don't fill out the fields (maybe > >> > use indent instead of username, to use a field from BaseUser > > >> Lets get this straight: what you're proposing is that unless you're > >> using Django's auth class, you can't use comments. Does this sound > >> like something that will be acceptable? > > >> Now, think outside the box - if contrib.comments has this problem, > >> what about other apps that aren't part of Django itself? Is it > >> possible that other applications might have similar problems? > > >> At the very least, contrib.comments should implement a best-practice > >> solution to show what other applications *should* be doing to > >> implement auth integration. > > > Sorry, I think I didn't put it right. Of course the comment app will > > work with BaseUser! The only problem is: the comment model saves > > username and email, the comment form displays a form with username and > > email; the two fields are filled out with the email and username from > > the authenticated user, but the BaseUser class doesn't have an email > > or username field, so the fields can't be filled out, before the form > > is displayed. But that won't break the comments app! (email and > > username are not required and the comment is linked to a User object) > > Yes - like I said, the comments app will only work with BaseUser :-) > > Consider the case where I need to have a User class with an email > field that isn't called "email". Are you honestly proposing that I > shouldn't be able to populate the email field on a comment? > My idea to solve the problem is: modify the interface and add properties like email and username (maybe other useful properties too!?) to the BaseUser class, which wrap aroud specific User class functions (every class that extends BaseUser should implement the getters/setters for username and email. Of course my proposal is a base suggestion and the first week of gsoc peroid I want the finalize the api design with my mentor and the community. I'm not sure, are we still on the right way? Flo -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
