Ce que vous avez est un python d'erreur -- self n'est pas défini. self est généralement ce qui fait référence à l'instance de la classe elle-même sur les méthodes de la classe.
De toute façon, je suis d'accord, c'est flambant neuf et non documenté. Je pense en regardant la source est absolument essentiel à ce stade.
Pour obtenir à l'aise avec la classe de base de points de vue, j'aimerais commencer par dériver django.views.generic.base.View, ce qui implémente seulement quelques méthodes, à savoir la tentative d'appeler une fonction de la classe basée sur la méthode de la requête (post, get, head, - chercher à la source).
Par exemple, voici la première étape pour remplacer les fonctions d'affichage avec les nouvelles classes de vue:
class MyClassBasedView(View):
def get(self, request):
# behave exactly like old style views
# except this is called only on get request
return http.HttpResponse("Get")
def post(self, request):
return http.HttpResponse("Post")
(r'^foobar/$', MyClassBasedView.as_view())
De retour à votre question:
Tous TemplateView.as_view() n'est rendre le modèle - CreateView est une combinaison de plusieurs autres classes qui gèrent ModelForms et le modèle de rendu (TemplateView).
Ainsi, pour un exemple très simple, regardez la documentation de la classe mixins sont utilisés par CreateView.
Nous voyons qu'il implémente TemplateResponseMixin, ModelFormMixin, et ProcessFormView, chacun contenant une liste des méthodes de ces classes.
Les plus de base CreateView
Au niveau le plus élémentaire, fournissent CreateViews' ModelFormMixin avec le modèle ou la coutume ModelForm classe , comme indiqué ici.
Votre CreateView classe ressemblerait à quelque chose comme ce qui suit
class AuthorCreateView(CreateView):
form_class = AuthorForm
template_name = 'author_new.html'
success_url = 'success'
Avec ces 3 attributs de base défini, appelez dans votre Url.
('^authors/create/$', Author.AuthorCreateView.as_view()),
Le rendu de la page et vous verrez que votre ModelForm passé pour le modèle en tant que form, la manipulation de la validation du formulaire de l'étape (passant en request.POST / re-rendu s'il est invalide), ainsi que l'appel à la form.save() et de la rediriger vers le success_url.
Début surchargeant les méthodes de la classe
Pour personnaliser le comportement, commencer surchargeant les méthodes décrites pour l' mixins.
Rappelez-vous que vous avez simplement besoin de retourner un HttpResponse à partir de l'une de ces méthodes, tout comme toute la vue normale de la fonction.
Exemple primordial form_invalid documentée en ModelFormMixin:
class AuthorCreateView(CreateView):
form_class = AuthorForm
template_name = 'author_new.html'
success_url = 'success'
def form_invalid(self, form):
return http.HttpResponse("form is invalid.. this is just an HttpResponse object")
Cette par-la redéfinition de méthode commence à devenir extrêmement utile que vos formulaires de croître plus avancés et, finalement, permet de construire d'énormes formes avec une poignée de lignes de code, en remplaçant seulement ce qui est nécessaire.
Dites que vous souhaitez transmettre votre formulaire personnalisé des paramètres tels que l' request objet (très commun, si vous avez besoin d'accéder à l'utilisateur dans le formulaire): vous devez simplement remplacer get_form_kwargs.
class MyFormView(FormView):
def get_form_kwargs(self):
# pass "user" keyword argument with the current user to your form
kwargs = super(MyFormView, self).get_form_kwargs()
kwargs['user'] = self.request.user
return kwargs
Classe de vues sont un brillant exemple de smart classe d'utilisation. Il m'a donné un grand intro vers la création de ma propre mixin pour les vues et les classes python en général. Il est de sauver un nombre incalculable d'heures.
Wow ça a été long. À penser qu'il a commencé comme une simple URL de la documentation commentaire :) j'Espère que ça aide!
