Traitement courant lors de la demande de vue basée sur les classes

Lors de l'implémentation de la Vue basée sur les classes dans Django, get et post sont traités en commun. Je le voulais, alors je l'ai implémenté.

la mise en oeuvre

S'il y a une demande, qu'elle soit get ou post, [dispatch ()](https://docs.djangoproject.com/en/1.11/ref/class-based-views/base/#django.views.generic.base Appelé via .View.dispatch). J'ai donc emballé dispatch () en utilisant method_decorator.

def some_decorator(dispatch):
    def wrapper(request, *args, **kwargs):
        # ...Quelque chose de traitement commun

        return dispatch(request, *args, **kwargs)

    return wrapper


@method_decorator(some_decorator, name='dispatch')
class MyView(View):

    def get(self, request, *args, **kwargs):
        return HttpResponse('Hello, World!')

N'est-ce pas bon avec le middleware?

Si cela ressemble à un simple journal d'accès, je pense que vous devriez implémenter middleware. Cependant, je voulais garantir que c'était après que tout le middleware ait été exécuté, et je voulais n'enregistrer qu'une vue spécifique.

Ne devrais-je pas étendre la vue et annuler l'envoi?

Si vous voulez vraiment l'implémenter avec seulement une vue (unique) spécifique, vous pouvez la remplacer. Cependant, lors de l'implémentation de View, il s'agit en fait de TemplateView, ListView, DetailView, ModelViewSet de django-rest-framework, donc je voulais implémenter un traitement commun avec eux.

version

Django==1.11

Recommended Posts

Traitement courant lors de la demande de vue basée sur les classes
Vue basée sur les classes Django
Points à garder à l'esprit lors du traitement des chaînes en Python2
Points à garder à l'esprit lors du traitement des chaînes en Python 3
Tenez compte du prétraitement courant lors du traitement du flux DynamoDB avec Lambda (Python)
Ce à quoi j'étais accro lorsque l'utilisateur de traitement est passé à Python