I CBV tendono a rendere un sacco di cose più facili una volta capito. Anche se può sembrare che tutto sia estremamente complicato se si sottoclasse TemplateView per tutto, i CBV prendono un sacco di scia inutili quando si ha veramente bisogno di averli.
I CBV aiutano anche a organizzare le cose in piccoli pezzi. Il nome del modello usato per la tua vista sarà praticamente sempre la variabile template_name. Cosa succede quando la mia funzione ottiene una richiesta GET? Chiama get (). INVIARE? Questo è post (). Invece di avere più codepath, ora ci sono due funzioni che si escludono a vicenda e che gestiscono indipendentemente uno scenario diverso. Cosa c'è nel mio contesto? Scopri get_context_data. Hai bisogno di visualizzare informazioni su un oggetto DB? Crea una vista dettagliata, con il PK nell'URL e il modello definito nella vista. Nessuna ricerca DB di codifica manuale (anche se è possibile specializzare il set di query se lo si desidera). Se hai a che fare con un modulo, eseguirà tutta la convalida per te, quindi dovrai solo definire form_valid (eseguito quando il modulo è valido) e probabilmente non dovresti nemmeno preoccuparti di form_invalid, dato che l'impostazione predefinita è solo per richiamare la pagina con gli errori nel modulo.
La chiave per usare efficacemente i CBV è sapere quale CBV usare per lo scenario giusto. Scrivere un FBV per visualizzare un modulo di creazione dell'oggetto, convalidarlo e creare l'oggetto è un problema nel sedere, ma un CBV di CreateView richiede solo la classe del modulo, la classe del modello e il nome del modello. DetailView è ottimo per sputare semplicemente le informazioni da un database. Se stai facendo qualcosa come un blog in cui la ricerca anno / mese / giorno sarebbe utile, ci sono una mezza dozzina di diversi CBV basati su data che ne automatizzeranno la maggior parte.
In particolare, gli FBV non offrono altra scelta se non quella di creare una funzione monolitica, e mentre viste estremamente semplici potrebbero essere più veloci e più facili negli FBV, il fatto che i CBV incapsulino ogni fase del processo di rendering (distribuzione, recupero di modelli, gestione diversi tipi di richieste, passando le variabili di contesto, i moduli di convalida, ecc., rendono tutto molto più semplice da abbattere. Inoltre, in genere non è necessario dichiarare la maggior parte delle funzioni CBV, poiché le impostazioni predefinite sono piuttosto sensate. Se lasci che i CBV facciano la maggior parte del lavoro per te, finirai con un apprezzamento molto migliore per loro.
Un paio di suggerimenti che ho trovato estremamente utili:
-
link - Bretelle è una libreria di mixaggio CBV, che fornisce un sacco di utili mixin per i CBV. Invece di usare un FBV e decorare con @login_required, puoi rendere la tua vista una sottoclasse di LoginRequiredMixin e farà la stessa cosa. Dispone anche di mix per accesso superutente, accesso basato su autorizzazione e persino accesso JSON per API e chiamate AJAX.
-
Se sei assolutamente attaccato ai tuoi decoratori, nota che puoi ancora utilizzare i decoratori FBV per i CBV decorando la funzione di spedizione nel tuo CBV. Di conseguenza, il seguente è equivalente:
@login_required
def FunkyView(request):
return HttpResponse("Funky!")
class ClassyView(View):
@login_required
def dispatch(self, request, *args, **kwargs):
super(ClassyView, self).dispatch(request, *args, **kwargs)
Puoi anche decorare la funzione as_view in URLConf, in questo modo:
url(r'^classy/$', login_required(ClassyView.as_view()), name='decorated_classy')
-
link è la risorsa definitiva per le visualizzazioni basate sulla classe, offrendo un modo semplice per visualizzare il codice CBV, vedere che cosa eredita da cosa, e vedi dove sono disponibili le funzioni.