Re: Class based views: A standard hook for http-method-independent code

Not quite, other Mixins, take for example SingleObjectMixin require access to request, args, kwargs so to utilize the functionality of existing mixins in init(), we need to set self.request, self.args and self.kwargs

Re: Perimission field name on the new Custom User Model

Oh, my apologies, the proper argument to set the name of the table that is created for a ManyToManyField is db_table instead of db_column (which just controls the column on the user table itself). Entirely my mistake. Best, Alex Ogier On Thu, Nov 8, 2012 at 8:10 PM, Christian Jensen

Re: Class based views: A standard hook for http-method-independent code

Ok… so let's get this straight: * init() needs to have access to request, args, kwargs * That means your implementation of dispatch() needs to set them. Sure. I'll pay that. If you assume that an init() method is required, then sure, you need to set up attributes to support it. What I don't

Re: Class based views: A standard hook for http-method-independent code

Hey Russ, The main point of concern which I think you may be missing is that self.kwargs and self.args are set inside dispatch, so using other mixins that require self.kwargs and self.args to be set (most do) will not work, without doing: def dispatch(self, request, *args, **kwargs):

Re: Class based views: A standard hook for http-method-independent code

On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam wrote: > Without setting request, args, and kwargs on on the view instance (which > is done during the base dispatch view), anything in the view that assumes > these values are present cannot run. > > Most of my views end up

Re: Class based views: A standard hook for http-method-independent code

Without setting request, args, and kwargs on on the view instance (which is done during the base dispatch view), anything in the view that assumes these values are present cannot run. Most of my views end up with functions which retrieve an object and then do some basic validation to ensure

Re: Perimission field name on the new Custom User Model

Yea, the column name was the first thing I tried - it had no effect on the name of the database table that was created. I am good with copying the entire ModelBackend I just thought someone would either want to document this fact or make it configurable. Christian On Thu, Nov 8, 2012 at 1:22

Re: DatabaseError with empty IN clause with Paginator

On Thu, Nov 8, 2012 at 9:44 PM, Chi Ho Kwok wrote: > Hi devs, > > I've noticed that after upgrading to Django 1.4, __in queries really don't > like empty sets. Simple queries still work, like > User.objects.filter(groups__in=[]), but most failures I've seen are with >

Re: Class based views: A standard hook for http-method-independent code

On Thu, Nov 8, 2012 at 8:42 PM, Diederik van der Boor wrote: > > Op 7 nov. 2012, om 17:49 heeft Aaron Merriam het volgende geschreven: > > I wanted to post and modified version of a gist posted earlier in this > thread. > > https://gist.github.com/4032482 > > I originally

Perimission field name on the new Custom User Model

I was tweaking around with making an email address only User model (sans username) while still retaining the permissions stuff and ran into a small issue. I can fix it but it might need to be documented. Here is the problem: I copied over the entire AbstractUser of django.contrib.auth.models.py,

Re: Custom user models in 1.5, not flexible/dry enough?

I agree entirely. The point of mixins is not that they are a particularly healthy abstraction, just that they are one way of exposing the Django permissions system, which is currently only done in full form (that is, with is_active and is_superuser guards) in AbsractUser and User. If you want to

DatabaseError with empty IN clause with Paginator

Hi devs, I've noticed that after upgrading to Django 1.4, __in queries really don't like empty sets. Simple queries still work, like User.objects.filter(groups__in=[]), but most failures I've seen are with Paginators. I think this is the minimum set to cause a DatabaseError, create any app,

Pull Request for django-localflavor-ro

Hi, Could someone review my pull request for django-localflavor-ro? I added some improvements to the Phone Number Field, and with the recent reorganization of the localflavor packages I don't know where to announce this. https://github.com/django/django-localflavor-ro/pull/1 -- You received

Re: Class based views: A standard hook for http-method-independent code

I think the naming in rest framework is certainly nicer than init, purely from the being explicit point of view. Having a method with the same name as a dunder method seems like it would be a point of confusion for new comers too. On Thursday, November 8, 2012 7:43:45 AM UTC, Mike Fogel wrote:

Re: Class based views: A standard hook for http-method-independent code

Op 7 nov. 2012, om 17:49 heeft Aaron Merriam het volgende geschreven: > I wanted to post and modified version of a gist posted earlier in this thread. > > https://gist.github.com/4032482 > > I originally implemented the original structure of having an `init` hook > which was called between

Re: Custom user models in 1.5, not flexible/dry enough?

Ok - so, I've been following this thread, and I should probably shed some light on the other side of the decision making process. I've got a history with Mixins. I was responsible for the final commit of Django's class-based views, which are very mixin heavy… and haven't been universally well

Re: Custom user models in 1.5, not flexible/dry enough?

If you ask me this just points out to some point i mentioned in the original Custom UserModel Thread. I'm trying to reframe it again. I think the current django.contrib.auth *app* somehow behaves like some mixture of django.core._mixins_everyone_should_use_to_make_apps_interoperability and