[Request] Document customizing the class based views

[morenoh149]

The create view is described at https://github.com/pinax/pinax-messages#create-message---code

I would like to do some extra logic here. How can I customize the create view?

[tarsil]

@morenoh149 you can always inherit from the model and override the functionality to be the one you prefer or optionally you can always use a proxy model. Something like this:

class MyCustomModel(Message):
    class Meta:
        proxy = True

    def new_message(...):
        # overrides here

[reedjones]

This seems to be a problem with the whole app, that you can easily customize the templates, but not the logic in the views.... :/

[tarsil]

@reedjones that is odd, have you tried to also inherit from the views? Is the same as overriding the models but using the super() to actually apply it. It would be easier if you could provide some examples :-)

[reedjones]

@tiagoarasilva yeah that might be my problem that I'm not really familiar with class based views. maybe in the documentation could add an example of how to customize the views? There is a reference on customizing the templates (which is easy) but there is no info on how to customize the logic in the views. For example I need to paginate the messages in the inbox views, I need to check if a user is blocked before sending a message, I need to check the content of a message if it has some banned content (like external links for example) before sending the message, etc.... Does anybody have some concrete examples of how to add custom logic to the views?

[tarsil]

@reedjones I think I can provide you a few examples of how to work with class-based views but bare in mind that I don't work for pinax :-). I'm just a software (python more specifically) engineer that is trying to help a fellow developer 😄

Ok, let's go by phases. Based on what you just said, I assume you work a lot with function-based views, like this:

def home(request):
    if request.method == 'GET':
        # do something
    elif request.methods == 'POST':
        # another something

Is my assumption correct? Let's transform this into a class-based view

from django.views.generic import TemplateView # You also have FormView, CreateView, UpdateView, ListView ....


class HomeView(TemplateView):
    template_name= 'home.html' # location of yout HTML file in the same way as the render_template in the functions

    def get(self, request, *args, **kwargs): # Also a default inherited from every template view of django
        if not request.user.is_authenticated:
                # DO SOMETHING LIKE RETURNING A REDIRECT OR RAISE A 404
        return super().get(request, *args, **kwargs)

    def post(self, request, *args, **kwargs):
        # DO THE POST LOGIC HERE
        return super().post(request, *args, **kwargs)

This is a small example and is only used for explaining how we can achieve both function and class-based views 😄

Lets override using pinax-message specific views (example purposes)

Ok, using the example of the Django templates from pinax-messages (the Django Rest Framework is the same thing, actually, I've implemented DRF on top of pinax-messages, which means that I'm not even using the template system provided by them) and what you want to achieve:

"For example I need to paginate the messages in the inbox views, I need to check if a user is blocked before sending a message, I need to check the content of a message if it has some banned content (like external links for example) before sending the message, etc.... Does anybody have some concrete examples of how to add custom logic to the views?"

Let's try to demystify this and using an example where you can adapt and do for you own needs.

from django.views.generic import ListView # This is where the pagination magic will happen
from pinax.messages.views import InboxView
from django.core.paginator import Paginator
from django.contrib.auth.mixins import LoginRequiredMixin
from pinax.messages.models import Thread


class MyInboxListView(LoginRequiredMixin, InboxView, ListView):
    """
    We inherit from the mixin LoginRequiredMixin that does the same as the decorator login_required.
    Also, we would like to use the InboxView just for the sake of this example and inherit the context_data already there.
    In the end we apply that to a ListView to paginate
    """
    template_name = 'inbox.html' # location of your inbox html page
    paginate_by = 10 # OR WHATEVER NUMBER YOU DESIRE PER PAGE
    pagination_class = Paginator # OR NumberDetailPagination

    def get_queryset(self):
        # Django ListView by default needs you to implement a queryset in order to apply pagination properly
        # We are assuming you are using pinax-messages models, if not, you just need to apply to your models.
        return Thread.inbox(self.request.user)

This, in theory, return all the inbox messages for the logged in user and that inbox is a classmethod already implemented. Your template will have also:

 def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        if self.kwargs.get("deleted", None):
            threads = Thread.ordered(Thread.deleted(self.request.user))
            folder = "deleted"
        else:
            threads = Thread.ordered(Thread.inbox(self.request.user))
            folder = "inbox"

        context.update({
            "folder": folder,
            "threads": threads,
            "threads_unread": Thread.ordered(Thread.unread(self.request.user))
        })
        return context

Automatically and the reason for it is because we are inheriting the context data but we can add more details to our view. How? Inside our MyInboxListView

def get_context_data(self, *args, **kwargs):
    """
    We will be calling context = super().get_context_data(*args, **kwargs) because we want to get the inherited context data from
    inherited views + our own logic
    """
    context = super().get_context_data(*args, **kwargs) # here is where your confusion is.
    context.update({
        'my_new_details_stuff': 'Value added on my MyInboxListView level view, only!'
    })
    return context

Now, we want to send messages and run validations to understand if the user is blocked or not and all of that, so in your views:

from django.views.generic import ListView # This is where the pagination magic will happen
from django.views.generic import TemplateView
from pinax.messages.views import InboxView, MessageCreateView
from django.core.paginator import Paginator
from django.contrib.auth.mixins import LoginRequiredMixin
from pinax.messages.models import Thread
from django.contrib import messages
from django.http import PermissionDenied, HttpResponseRedirect


class MyInboxListView(LoginRequiredMixin, InboxView, ListView):
    ...
    ...


class SendMessageView(LoginRequired, MessageCreateView, TemplateView):
    """
    Since we are inheriting from the MessageCreateView, we don't need to worry about that logic,
    We can just implement ours. We can override everything, GET, POST by applying specific logic on each
    HTTP verb or in general on the dispatch level
    """
    def dispatch(self, request, *args, **kwargs):
        if request.user.is_blocked: # OR WHATEVER LOGIC YOU HAVE IN YOUR USER
            message.add_message(request, messages.ERROR, "You can't send messages")
            raise PermissionDenied()
        return super().dispatch(request, *args, **kwargs)

    def post(self, request, *args, **kwargs):
        # SEND MESSAGE LOGIC HERE
        messages.add_message(request, messages.SUCCESS, "Message Sent")
        return HttpResponseRedirect('your reverse url')

This was very generic and I hope it helps you understand how to override and/or apply your own logic and still use pinax-messages resources. Personally, if I was pinax, I would put this also for django rest framework and it would be easier to work async but that is just me. I built my own.

Also, bare in mind that you can also use CreateView instead of TemplateView from Django, the difference is that with CreateView UpdateView they demand a form_class to be declared (your own or you can just reuse the pinax-messages one)

[reedjones]

@tiagoarasilva Thanks for the detailed reply! :)

So I guess by defining my own views with the same names, the url dispatcher will send to mine first?
That's what wasn't clear to me, and honestly I still don't see how will django know to use my view, instead of the pinax SendMessageView for example... Anyway thanks again, this already helped a lot I guess I just have to get my head around classed based views....

[tarsil]

@reedjones by default it will always go to your view first since the URL that you defined is pointing to your view and not the pinax (not declared in your app by importing them). Then, your view inheriting from the rest, the validations go from bottom-up (like any normal inheritance class, function, or paradigm), so you absolutely got it.

"That's what wasn't clear to me, and honestly I still don't see how will django know to use my view, instead of the pinax"

Simple, you have 2 options.

1. You use pinax URLs (which I don't even declare in my app) and Django will always go there.
2. You use your own URLs with your OWN views and those views are inheriting from the pinax-views as per example. This way, Django only points to your custom URLs (since you don't even declare the URLs of pinax, at least I didn't but I was using DRF) and your custom views inheriting from pinax will have the same result as pinax-views declared + your desired custom logic 😄 .

Makes sense?

[reedjones]

@tiagoarasilva
yes makes sense :) thank you..
I think I will go with your method of not using the pinax urls and just inheriting from the views...
We should make a pull request with your example in the documentation I feel like would help some others as well...
thanks again!

[KatherineMichel]

@reedjones @tiagoarasilva Thank you for the assistance, Tiago. Even some of us who work with Pinax are overwhelmed at how to do things and explain at times. Now that a release is done, docs are a focus. Perhaps this info could be used, if you are ok with that.

[tarsil]

@KatherineMichel please by all means use what you need and want as long I could help. I would do it also for Django rest framework but that is a different example

[tarsil]

@KatherineMichel if you ever consider applying pinax-messages for DRF, please let me know since I have that already implemented as well 😄

[morenoh149]

if welcome, we should add the explanation at #55 (comment) to the documentation in the readme. OR better, add an example django app to the repo OR add a docs page (read the docs or github wiki).

@KatherineMichel what is your preference?

[tarsil]

@morenoh149 I've tried to contribute to pinax here #58. I can start doing it and also provide some DRF integrations if you all wish as well since DRF is widely used or just simply create a new pinax-messages-drf