HN Explorer

15 comments

[ 3.4 ms ] story [ 36.3 ms ] thread
rlander
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

kennethlove
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?

rlander
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?

chrisjones
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.
tkaemming
I've found this view_class_decorator and MultipleFormView particularly helpful with class-based views: https://gist.github.com/1953579
kennethlove
I don't care for the decorator at all, but the MultipleFormView mixin looks very handy. Thanks.
andrewingram
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.

kennethlove
True, that does bring up an interesting point.

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

jarcoal
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.
kennethlove
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.

pydanny
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

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