7 ms·

Our custom Django mixins

63 points by kennethlove 15y ago

andrewingram 15y ago
Here are my extensions to Django's class-based views: https://github.com/AndrewIngram/django-extra-views https://github.com/AndrewIngram/django-extra-views
rlander 15y ago
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 https://github.com/aino/aino-utkik
- kennethlove 15y ago
  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 15y ago
    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?
    - kennethlove 15y ago
      Yeah, it is actually. https://github.com/brack3t/django-braces 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.
- chrisjones 15y ago
  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 15y ago
I've found this view_class_decorator and MultipleFormView particularly helpful with class-based views: https://gist.github.com/1953579 https://gist.github.com/1953579
- kennethlove 15y ago
  I don't care for the decorator at all, but the MultipleFormView mixin looks very handy. Thanks.
  - andrewingram 15y ago
    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 15y ago
      True, that does bring up an interesting point. I'll have to give it another look later, maybe I'll change my mind.
jarcoal 15y ago
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 15y ago
  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 15y ago
    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
  - jarcoal 15y ago
    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/generic https://github.com/django/django/tree/master/django/views/ge...
- Daishiman 15y ago
  Agreed. The docs should be more comprehensive, and there should be at least one contrib package with useful CBV.s

63 points by kennethlove 15y ago

Here are my extensions to Django's class-based views: https://github.com/AndrewIngram/django-extra-views https://github.com/AndrewIngram/django-extra-views

rlander 15y ago

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 https://github.com/aino/aino-utkik

kennethlove 15y ago
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 15y ago
  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?
  - kennethlove 15y ago
    Yeah, it is actually. https://github.com/brack3t/django-braces 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.
chrisjones 15y ago
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 15y ago

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

kennethlove 15y ago
I don't care for the decorator at all, but the MultipleFormView mixin looks very handy. Thanks.
- andrewingram 15y ago
  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 15y ago
    True, that does bring up an interesting point. I'll have to give it another look later, maybe I'll change my mind.

jarcoal 15y ago

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 15y ago
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 15y ago
  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
- jarcoal 15y ago
  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/generic https://github.com/django/django/tree/master/django/views/ge...
Daishiman 15y ago
Agreed. The docs should be more comprehensive, and there should be at least one contrib package with useful CBV.s