Our custom Django mixins | Hacker News Reader

Our custom Django mixins

brack3t.com

63 pointskennethlove15 comments

Very nice snippets, though they're meant to work only with Django's default class views.

A few months ago I started using a small class-based views library called aino-utkik[1] and haven't looked back.

Instead of this:

    class ArtistLogin(FormView):
        form_class = ArtistLoginForm
        template_name = 'artists/artist_login.html'

        def get(self, request, *args, **kwargs):
            request.session.set_test_cookie()
            return super(ArtistLogin, self).get(request, *args, **kwargs)

        def form_valid(self, form):
            login(self.request, form.artist)
            return HttpResponseRedirect(reverse('artist_mypage'))

        def get_form_kwargs(self):
            kwargs = super(ArtistLogin, self).get_form_kwargs()
            kwargs['request'] = self.request
            return kwargs

I can write this:

    class ArtistLogin(View):
        def setup(self):
            self.c.form = ArtistLoginForm(
                request=self.request, data=self.request.POST or None)

        def get(self):
            self.request.session.set_test_cookie()

        def post(self):
            if self.c.form.is_valid():
                login(self.request, self.c.form.artist)
                return HttpResponseRedirect(reverse('artist_mypage'))

which I find way more elegant.

[1] https://github.com/aino/aino-utkik

That is a really nice syntax. I kind of like the specificity of ``form_valid`` (for example), though.

And, yes, our mixins are Django-only (hence the title!)

Also, why the ``set_test_cookie`` on every GET?

Those snippets were taken from utkik's docs and are probably part of a larger code; but I agree they probably belong somewhere else, maybe in a middleware.

BTW, thanks for the nice post. Is the code available on github or bitbucket?

Yeah, it is actually.

https://github.com/brack3t/django-braces is the Github repo, or you can ``pip install django-braces`` into your project. All the mixins are then imported from the ``braces`` package.

I did not know this existed, I'll have to give it a look. The setup method makes sense, not sure I like having to check is_valid() though.

Here are my extensions to Django's class-based views:

https://github.com/AndrewIngram/django-extra-views

Django's documentation is indeed terrible for class based views, but I encourage any developers that have had trouble reading through it to just take a look at the source. I found it to be much easier to learn that way.

No one should have to read the source to understand such a large and useful area of a framework.

That's similar to expecting people to read the source code to understand ActiveRecord or something.

I agree. Reading the source is so 2000s. Part of why Django has enjoyed it's community growth is because of it's culture of documentation. And for Django to have released something that isn't well documented is untypical.

This isn't a complaint, except at me. I've promised to update those docs for coming up on a whole year. :P

I definitely think the docs should be better, but it's not really that much code to read through. The entire thing is maybe 1000 lines of code.

Here it is, although the code is somewhat mixed with the old, function based, generic views: https://github.com/django/django/tree/master/django/views/ge...

Agreed. The docs should be more comprehensive, and there should be at least one contrib package with useful CBV.s

I've found this view_class_decorator and MultipleFormView particularly helpful with class-based views: https://gist.github.com/1953579

I don't care for the decorator at all, but the MultipleFormView mixin looks very handy. Thanks.

The decorator actually raises an interesting issue. Are permissions and security part of the core application logic, or are they wrappers.

The mixin approach is nice and OO, but it's potentially tying two different layers of functionality together. Whereas the decorator is closer to aspect-oriented programming which attempts to isolate core business logic from such modifiers.

I'm actually quite interested in the challenge of applying design patterns for large systems (inversion-of-control, AOP etc) to Django, which has some stubborn behaviours that get in the way.

True, that does bring up an interesting point.

I'll have to give it another look later, maybe I'll change my mind.

Reply on news.ycombinator.com